Toggling into and out of responsive design mode caches certain media query outcomes
Categories
(DevTools :: Responsive Design Mode, defect, P2)
Tracking
(firefox112 verified, firefox113 verified)
People
(Reporter: alex.nied, Assigned: emilio)
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/109.0
Steps to reproduce:
For the purposes of this bug, the MUI site can be used:
- Navigate to the MUI Buttons Component Docs
- Hover an example button-- notice that its background color changes on hover. Inspect the same button, and note that by toggling the hover state in the dev tools you can see the background being changed.
- Toggle responsive design mode on; hover the same button for good measure
- Toggle response design mode off
- Try hovering the original button
Actual results:
The button no longer has background changes on hover; toggling the hover state in the dev tools show that a media query is being applied that gives the button a transparent background, overriding the previous background style.
Expected results:
The hover behavior for the button should have been the same as it was prior to opening and closing responsive design mode.
It is possible that this issues is related to Bug 1645208 — @media (hover: hover) breaks after going in and out of responsive design mode (Ctrl+Shift+M); however, given that that issue is 3 years old and was never able to be reproduced, I wasn't certain if it would be applicable anymore.
Also, for what it is worth, for me this issue can be resolved by refreshing the page; obviously, though, this is not ideal.
Comment 3•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'DevTools::Responsive Design Mode' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 4•3 years ago
|
||
Could not reproduce initially, but it seems triggered after toggling on and off the Responsive Design Mode several times. For the record I had touch simulation enabled.
Comment 5•3 years ago
|
||
This actually starts breaking when toggling RDM fast enough, probably a race condition.
Comment 6•3 years ago
|
||
Simpler STR:
- Go to
data:text/html,<meta charset=utf8><style>@media (hover:none) { body {background: tomato} }</style>hover none media - Trigger RDM, make sure touch simulation is enabled
- Toggle RDM a few time until you get into a state where RDM is disabled but the background of the page is still red
Note that when you're in this state, resizing the browser will "fix" the rendering
It does only seems to be a rendering issue, as when in the "broken" state, matchMedia("(hover:none)") will say the query doesn't match, even if visually it does.
It looks like we have a few bugs reported about incorrect behavior when closing RDM (Bug 1662387, Bug 1533123, 1645208)
Comment 7•3 years ago
|
||
Emilio suggested that https://phabricator.services.mozilla.com/D168148 could help, but it doesn't seem to fix this issue.
Adding a needinfo as the issue might reveal a bug in gecko and emilio offered to have a look :)
| Assignee | ||
Comment 8•3 years ago
|
||
Refactor the code a little bit to share more code.
Updated•3 years ago
|
| Assignee | ||
Comment 9•3 years ago
|
||
The MVM doesn't change the document viewer bounds nor the view manager
bounds (maybe it used to?). Right now when exiting RDM, depending on the
order of operations (if MVM reset is the last thing to happen) we end up
with a wrong viewport size, because nsDocShell::SetSize is
short-circuited here1.
Instead, force a resize reflow with the current dimensions which is what
the dynamic toolbar code also does, for example.
Depends on D169805
| Assignee | ||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Comment 11•3 years ago
|
||
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
Comment 14•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/0e640095619e
https://hg.mozilla.org/mozilla-central/rev/713dcdc945d1
Comment 15•3 years ago
|
||
| bugherder | ||
Updated•3 years ago
|
Reproducible on a 2023-02-13 Nightly build on macOS 12 using the STR from Comment 6.
Verified as fixed on Firefox 112.0(build ID: 20230403163424) and Nightly 113.0a1(build ID: 20230403215207) on macOS 12, Windows 10, Ubuntu 22.
Description
•