Developer tools ignores multi account containers
Categories
(DevTools :: Debugger, defect, P3)
Tracking
(Not tracked)
People
(Reporter: TheSpooler, Unassigned)
References
(Blocks 2 open bugs)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
When browsing in a multi-account container and opening the developer tools, if there is a resource to be loaded, it will be loaded in the default session, not the containerized one. This breaks loading source maps for authenticated resources (scripts) where only the container has the authenticated session.
Also, since the source map request doesn't show in the network tab, the actual server message is not visible to the user.
Actual results:
A javascript has a sourcemap associated coming from an authenticated site.
When Firefox Developer tools requests the map file, if the webserver requires authentication and shows an error, Firefox interprets that as an invalid json file.
The console then shows this error:
Source map error: SyntaxError: JSON.parse: unexpected character at line 3 column 1 of the JSON data
Resource URL: https://secure-and-authenticated-site.com/file.js
Source Map URL: file.js.map
Expected results:
Firefox should use the appropriate containerized session to load the external resource file.
Also, the request should show in the network tab, so it can at least be troubleshooted.
Updated•5 years ago
|
Comment 1•5 years ago
|
||
The priority flag is not set for this bug.
:Honza, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 2•5 years ago
|
||
Thanks for the report!
Can you please provide detailed steps to reproduce, so I can see the issue on my machine?
For example:
- Load the following page ...
- Open the Network monitor
- Operate the page so ....
etc.
Honza
Reporter | ||
Comment 3•5 years ago
|
||
Made you a sample site: http://spooler-mozdemo.azurewebsites.net/
- Load http://spooler-mozdemo.azurewebsites.net/ twice: once in a containerized tab, once in the default tab.
- In the containerized tab, open the Developer Tools > Debugger
- In the containerized tab, click login
- Reload the page, in the Developer Tools console, you should see an error along the lines of
Source map error: request failed with status 404
Resource URL: https://spooler-mozdemo.azurewebsites.net/auth/scripts/main.js
Source Map URL: main.js.map
- In the default tab, click login
- In the containerized tab, reload and the sourcemap error should be gone.
Now, this is what I had hoped would happen, but as far as I can tell, something else (caching?) is at play. I've only ocasionally been able to get a working sourcemap loaded. It involved exiting the process, restarting going to the site, logging in, then opening the developer tools.
Accessing directly the .map file shows it correctly in the browser, but if going through the Debugger tab, I get this error:
Error loading this URI: Protocol error (unknownError): Could not load the source for https://spooler-mozdemo.azurewebsites.net/auth/scripts/main.js.map.
Error: Failed to fetch https://spooler-mozdemo.azurewebsites.net/auth/scripts/main.js.map. Code 2152924148.
Stack: onResponse@resource://devtools/shared/DevToolsUtils.js:544:16
onStopRequest@resource://gre/modules/NetUtil.jsm:123:17
Line: 544, column: 16
Also to note, if the content type returned is application/json, the debugger shows a lot of react components, but not the actual .map file.
Expected behavior: if the active session (in the current container) is authenticated, the sourcemap should load and appear in the Debugger tab in the sources
Comment 4•5 years ago
|
||
The priority flag is not set for this bug.
:Honza, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 5•5 years ago
|
||
Thanks for detailed STR, I can see the problem on my machine.
Honza
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•2 years ago
|
Description
•