1920357 - Responsive view became useless for non-mobile websites

Status: NEW

(DevTools :: Responsive Design Mode, defect, P2)

Description

[Maciej Jaros]

Attachment: useless_view in v131 (ff dev)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0

Steps to reproduce:

1. Open a non-mobile page, e.g., https://meta.wikimedia.org/.
2. Press CTRL+SHIFT+M to activate the responsive view.
3. Resize the responsive frame to make it thinner.

Actual results:

Scale is changed.

Expected results:

Should act as if the window were thinner.

When the viewport is narrower, the pages don't normally scale. The width is reduced, and responsiveness(!) should kick in. In the case of Meta Wiki, the sidebars should disappear.

Note that the responsive view used to work as expected but was broken at some point (it was fine in v125.0.3, so it was broken sometime between May 2024 and September 2024).

Comment 1

[Maciej Jaros]

Attachment: responsive_view_v125.png

Comment 2

[Maciej Jaros]

Attachment: thin_view_no_sidebars in v131 (normal window).png

Compare with a normal window (not in responsive view).

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

[Nicolas Chevobbe [:nchevobbe]]

Looks like this was regressed by Bug 1888242.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

:emilio, since you are the author of the regressor, bug 1888242, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

I mean, this is kind of expected because that patch did (Always handle meta viewport in RDM). That is how the page would look on a phone of that size, because of the lack of <meta viewport>.

If you want to test the desktop behavior you can always just resize the window... We could make a switch for the meta viewport width=device-width behavior if needed I guess.

Comment 7

[Maciej Jaros]

But I am not emulating phone. I don't even emulate touch screen. I'm on the desktop using RESPONSIVE view. Which is not responsive... Not something that is expected to me.

If you want to test the desktop behavior you can always just resize the window... We could make a switch for the meta viewport width=device-width behavior if needed I guess.

I don't want to resize all my tabs. I just want to resize the specific website I'm working on and possibly set the size based on the breakpoints I know. If I wanted to resize the entire window and work in a single tab, I would switch to Chrome.

Comment 8

[Julian Descottes [:jdescottes]]

Thanks for filing, I think RDM should trigger responsive mode regardless of <meta viewport>.

Emilio, do you think we could set an additional flag on the browsing context to explicitly say if we are emulating a device (eg when a user selected a phone preset). And when users are just resizing the viewport we would go back to the behavior prior to Bug 1888242? I imagine we'll need another way to fix the issue initially fixed by bug 1888242 however?

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1888242

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1920357 - Ignore viewport meta tag when we're in RDM and we also force desktop viewport. r=#devtools-reviewers!

Currently DevTools doesn't do it, but it feels like the right API and is
already there. This allows fixing this on the devtools side however you
want :)

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Emilio, do you think we could set an additional flag on the browsing context to explicitly say if we are emulating a device ...

I think we have that API already, it's called .forceDesktopViewport. Comment 10 implements the behavior you want I think. You'd just need to set .forceDesktopViewport = true whenever you want the old behavior.

Comment 12

[Julian Descottes [:jdescottes]]

Quickly testing, this seems to work well, thanks a lot! Just need to wire it to RDM correctly now, will give it a go tomorrow.

Comment 13

[Julian Descottes [:jdescottes]]

A few interesting things while trying this out.

First, Chrome behaves in the same way as the current Firefox, meaning the website is rendered as if it was on a mobile with that viewport size.

Second: it works fine to set forceDesktopViewport to true, the displayed page is automatically updated to be displayed in desktop mode, the opposite doesn't work for now. When I select back a device and set forceDesktopViewport to false, the page is still rendered as if it was in desktop mode.

Finally, it's a bit odd that when you resize a device preset, you jump from one mode to the other. I feel like chrome's approach where responsive is a fully different setting that you need to select explicitly would make this easir to understand.

Comment 14

[Julian Descottes [:jdescottes]]

Second: it works fine to set forceDesktopViewport to true, the displayed page is automatically updated to be displayed in desktop mode, the opposite doesn't work for now. When I select back a device and set forceDesktopViewport to false, the page is still rendered as if it was in desktop mode.

It seems that the behavior is a bit inconsistent when setting forceDesktopViewport back to false. Sometimes the page is still displayed as if forceDesktopViewport was true. I managed to workaround this by ensuring I resize the viewport AFTER I set forceDesktopViewport=false, but maybe there's an API I can call on the browsing context to force an update?

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Updated the patch with a fix. I guess that's not an issue usually because on android force desktop viewport also reloads the page.

Comment 16

[Julian Descottes [:jdescottes]]

Thanks a lot! I confirm the updated patch fixes the issue!

Comment 17

[Julian Descottes [:jdescottes]]

Attachment: Bug 1920357 - [devtools] Set forceDesktopViewport when RDM is not set to a device

Depends on D223627

Comment 18

[Julian Descottes [:jdescottes]]

Attachment: Bug 1920357 - [devtools] Show the viewport mode in the RDM toolbar

Depends on D223987

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1888242

Comment 20

[Julian Descottes [:jdescottes]]

Hi Emilio, is it fine if I land your patch already so that we can have it in central? We are still discussing and fine tuning the UI changes to expose the new behavior in RDM, but having your patch landed will make it easier for us to quickly iterate.

Thanks!

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Yeah, sorry, I've been meaning to look at your question in the other patch, but I unfortunately haven't had the time to dig.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/14c9560833a6
Ignore viewport meta tag when we're in RDM and we also force desktop viewport. r=devtools-reviewers,jdescottes

Comment 23

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/14c9560833a6

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Should we uplift comment 23 to Beta? It's not entirely clear to me what the status of this bug is for the remainder of this cycle.

Comment 26

[Julian Descottes [:jdescottes]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #25)

Should we uplift comment 23 to Beta? It's not entirely clear to me what the status of this bug is for the remainder of this cycle.

No that's not going to change anything for end users, we need the whole stack of patches to land. And I wouldn't uplift, there's some UI change so I would prefer this to bake in Nightly anyway.

Comment 27

[Julian Descottes [:jdescottes]]

I was investigating a bit test the test failures with my current stack, and there are plenty.

The main issue is about zoom values or dimensions which don't hit the expected value, because we now force desktop site mode as soon as we don't use a device preset. And in most tests we just resize to custom dimensions.

We could rewrite all the tests to accommodate that, but I'm worried that this fix will address the issue for users who want test desktop mode responsive design, while regressing the situation for users who prefer testing the mobile version and might still want to use custom dimensions without only relying on presets.

If we look back at the situation before this regressed in Bug 1888242, using a "mobile" viewport was actually tied to enabling touch simulation. So basically you could test desktop responsive mode by simply disabling touch simulation.

Now this was not great and we even had a bug on file because this was confusing for users to see the layout/viewport change when enabling/disabling touch simulation. But I think that in order to properly fix this we should directly implement Bug 1924766 and allow users to manually decide if they want desktop mode or not.

And I would also avoid automatically switching between desktop and mobile mode when resizing, because I think it will be confusing. I would only suggest to automatically disable desktop mode when users select a mobile device.

Comment 28

[Donal Meehan [:dmeehan]]

Setting Fx133 to wontfix based on Comment 26.
Fx134 has just started the nightly cycle, hopefully these will land before Fx134 hits beta.

Comment 29

[BugBot [:suhaib / :marco/ :calixte]]

The leave-open keyword is there and there is no activity for 6 months.
:emilio, maybe it's time to close this bug?
For more information, please visit BugBot documentation.

Comment 30

[Julian Descottes [:jdescottes]]

Let's reset the assignee, this is still worth addressing but needs to be handled by DevTools team for the rest of the work.