New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 719309 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Allow dynamic viewport changes in Request Desktop Site mode

Reported by bruno.ra...@gmail.com, May 8 2017

Issue description

Steps to reproduce the problem:
1. Load olivercafe.com (e.g.) with Request Desktop Site 
2. The page normally tries to resize the viewport to a size different that the 980px default with JS (which can be observed to work in iOS or Firefox for Android)
3. Since the viewport can no longer be changed. It is forcing viewport width at 980px

What is the expected behavior?
I expect to be able to change the meta viewport to other than the "unnatural" 980px.

What went wrong?
This is a follow-up on https://codereview.chromium.org/1785953002/ and my comments at https://bugs.chromium.org/p/chromium/issues/detail?id=622204#c3 post https://codereview.chromium.org/1785953002 changes.

I don't mind if you lock the viewport to a 980px default, as opposed to a device-width. It's is a reasonable vendor take on Request Desktop Site mode and not an issue per se. Although note this is a Chrome only behavior. No other browsers do this.

The issue is that I have been detecting 'Request Desktop Site' for quite long time via JS, setting my own viewport width. So I want to still be allowed to make viewport changes, and leave it up to the author's interpretation as to what 'desktop width' they want to apply, if the meta viewport is other than device-width.

Did this work before? Yes 50? (slighlty unsure of version)

Does this work in other browsers? Yes

Chrome version: 53  Channel: n/a
OS Version: 
Flash Version:
 

Comment 1 by e...@chromium.org, May 8 2017

Components: -Blink>Layout Blink>CSS

Comment 2 by shend@chromium.org, May 9 2017

Cc: aelias@chromium.org
Status: Untriaged (was: Unconfirmed)
Thank you for your report. From reading the links you have posted, this seems like an intentional change and not a regression. CCing aelias@ for advice.

Comment 3 by aelias@chromium.org, May 10 2017

Status: WontFix (was: Untriaged)
Right, this is working as intended and we don't plan to provide that capability again.  Window width is not under author control on desktop Chrome, therefore it shouldn't be in desktop emulation mode either.
 My comment in https://bugs.chromium.org/p/chromium/issues/detail?id=622204#c4 gives more details and an alternate way of achieving the result you want.

By the way, if you want to set width to larger than 980, just creating a div of that width should work.  For smaller than 980, you'd have to do the CSS scale I mentioned earlier.  Both should have equivalent effects to the viewport tag thing you did before.
I am well aware it was intentional on your part. However it appears, there hasn't any extended consideration around the idea that flexibility for dynamic viewport changes be left open, along the initial width locked at 980, which should be technically feasible.

It *is* a regression, in a sense that's it's been changed without dialogue with any other vendor or any consultation (to my knowledge) to a viewport spec justifying that *breaking* change. The 'Desktop Mode' features have worked the same in all mobile browsers for the past 10 years. Even opera mini allow for viewport changes. I don't think the change as implemented on Chrome, is entirely the right call.

Your argument that “window width is not under author control on Desktop” is quite irrelevant to a 'mobile viewport' environment. Width restrictions are not appropriate in the context of mobile as far I am concerned. All mobile browsers have been steering towards making dynamic viewport changes possible. This mode should not deprive authors from this capability just because one vendor suddenly feels like it. I am all open for discussion as to what you be expected of this mode with other vendors. But you introduced cross-browser incompatibilities along the way, and that alone is subject to discuss the matter more broadly.

The advice of making the width larger than 980, or using CSS, is suggesting to use ugly hacks instead of doing it properly. Those aren't viable or practical, I am afraid.

What is the harm in making 980px by default (which might very well be the right call) yet still allow a dynamic viewport change for fine tuning the user experience?

I'd like to hear a full rationale for your refusal to consider this modification just aimed at finding a middle ground resolution.

Sign in to add a comment