Login cannot be successfully made on Sears's page
Categories
(Core :: General, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox71 | --- | unaffected |
firefox72 | --- | fixed |
firefox73 | --- | fixed |
People
(Reporter: csasca, Unassigned)
Details
(Keywords: regression, regressionwindow-wanted)
Affected versions
- Firefox 72.0b7
- Firefox 73.0a1
Affected platforms
- macOS 10.15
- macOS 10.14
Steps to reproduce
- Launch Firefox and access Sears
- Click on Sign In and select account
- Input valid credentials and resolve the captcha
- Click on Sign In
Expected result
- Sign in is successfully and the user is redirected to his account page
Actual result
- The user is not logged in
Regression range
- I will see for a regression, 71.0 not affected
Additional notes
- The issue can be seen in this attachment.
- Errors are not thrown on browser console.
- Firefox 71.0 is not affected.
- Seems that only macOS is affected.
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Bugbug thinks this bug is a regression, but please revert this change in case of error.
Comment 2•4 years ago
|
||
I can reproduce this using 20191218033533, which is 72.0b8 (running 10.15.3). In my case the password field keeps failing.
The only thing I see in the browser console is Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Comment 3•4 years ago
|
||
Here is some more spew I got in the console when trying to log in:
Exception
columnNumber: 0
data: null
filename: "resource://devtools/server/actors/network-monitor/network-observer.js"
lineNumber: 985
location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }
message: "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannelInternal.remoteAddress]"
name: "NS_ERROR_NOT_AVAILABLE"
result: 2147746065
stack: "_onResponseHeader@resource://devtools/server/actors/network-monitor/network-observer.js:985:5\n_dispatchActivity@resource://devtools/server/actors/network-monitor/network-observer.js:526:14\nNetworkObserver.prototype.observeActivity<@resource://devtools/server/actors/network-monitor/network-observer.js:607:12\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:111:22\n"
<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
ThreadSafeDevToolsUtils.js:90:13
Exception { name: "NS_ERROR_NOT_AVAILABLE", message: "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannelInternal.remoteAddress]", result: 2147746065, filename: "resource://devtools/server/actors/network-monitor/network-observer.js", lineNumber: 985, columnNumber: 0, data: null, stack: "_onResponseHeader@resource://devtools/server/actors/network-monitor/network-observer.js:985:5\n_dispatchActivity@resource://devtools/server/actors/network-monitor/network-observer.js:526:14\nNetworkObserver.prototype.observeActivity<@resource://devtools/server/actors/network-monitor/network-observer.js:607:12\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:111:22\n", location: XPCWrappedNative_NoHelper }
ThreadSafeDevToolsUtils.js:90:13
TypeError: "undefined has no properties"
_setupHarTimings resource://devtools/server/actors/network-monitor/network-observer.js:1256
_onTransactionClose resource://devtools/server/actors/network-monitor/network-observer.js:1020
_dispatchActivity resource://devtools/server/actors/network-monitor/network-observer.js:529
observeActivity resource://devtools/server/actors/network-monitor/network-observer.js:607
makeInfallible resource://devtools/shared/ThreadSafeDevToolsUtils.js:111
Comment 4•4 years ago
|
||
The priority flag is not set for this bug.
:gcp, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 5•4 years ago
•
|
||
Catalin, are we able to get a regression range here so we know where the issue could lie?
Reporter | ||
Comment 6•4 years ago
|
||
Hi guys, I've tried searching for a regression, but saw that the issue is no longer reproducible at all, and it may have been a site issue. Verified on 73.0b1 and 74.0a1 and seems that the login process works as intended.
Updated•4 years ago
|
Description
•