CSS Warnings are not emitted when CSS filter is on and we navigate to another domain
Categories
(DevTools :: Console, defect, P1)
Tracking
(Fission Milestone:M6, firefox75 verified)
Tracking | Status | |
---|---|---|
firefox75 | --- | verified |
People
(Reporter: nchevobbe, Assigned: nchevobbe)
References
Details
(Whiteboard: dt-fission-m2-mvp)
Attachments
(1 file)
Steps to reproduce
- Open the console on site-a.com
- Enable the CSS filter
- Navigate to site-with-css-warning.com
Expected results
I can see the css warnings
Actual results
The css warnings are not displayed
This is because in the ensureCssReportingEnabled enhancer, we only parse the stylesheet of the target during the initial redux action, or when the CSS filter is toggled (devtools/client/webconsole/enhancers/css-error-reporting.js#29-33 ).
But with target-switching (occuring at step 3
in our example), we won't trigger any of those actions, which means we don't re-parse the stylesheets to get the warnings.
We should change the heuristic to call target.ensureCSSErrorReportingEnabled
to fix this issue.
This case is covered by devtools/client/webconsole/test/browser/browser_webconsole_message_categories.js#57-60, where the CSS filter pref is set at the very start of the test, and we then navigate to different pages.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
If the CSS filter was enabled, when the user would navigate to a page
on a different origin, the CSS Warnings from the new page wouldn't
be displayed in the console.
This is related to how we manage the CSS Warnings. Since emitting those
messages is costly, we only do so when the console is opened, if
the user already set the filter, or when they turned it on.
The issue is that it was only done on the main target, and only
when the console would start, or when the user clicked on the css
filter button.
So with Fission enabled, we could switch to a new target, but we
wouldn't trigger the code that parses the stylesheets of the new
page.
This patch changes how we trigger the CSS warning report mechanism,
by not listening to specific actions, but having a Set of already
handled targets. When it encounters a new target, if the css filters
is enabled, then it will enable the CSS warning messages to be
emitted.
The browser_webconsole_message_categories was asserting this issue,
and is now fixed (after setting the proper target switching target).
Comment 2•5 years ago
|
||
Tracking dt-fission-m2-mvp bugs for Fission Nightly (M6) milestone
Comment 4•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Comment 5•5 years ago
|
||
Verified the fix with Firefox 75.0b4 on Windows 10 x64 and Ubuntu 18.04.
Updating the flag -> Verified.
Description
•