Open Bug 1123938 (viewport-compat) Opened 9 years ago Updated 29 days ago

[meta] Make viewport handling consistent with other browsers

Categories

(Core :: Layout, defect)

defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

(Depends on 24 open bugs, )

Details

(5 keywords, Whiteboard: [geckoview][needs-wpt-?])

User Story

Business driver: Mobile Webcompat (multiple site issues reported )

Attachments

(1 file)

Rick Byers described a new pinch-zooming feature in Blink here:
https://plus.google.com/+RickByers/posts/bpxrWN4G3X5

Slide deck:
https://docs.google.com/presentation/d/1nJvJqL2dw5STi5FFpR6tP371vSpDWWs5Beksbfitpzc/edit

Blink bug:
https://code.google.com/p/chromium/issues/detail?id=148816

Basically, the idea is to make the screen a "visual" viewport, when you zoom in, so that fixed-position stuff doesn't snap to your screen boundaries & cover stuff up & prevent itself from being scrolled across/out of view.  Instead, fixed-position stuff snaps to a "layout viewport", which the "visual viewport" scans across.

Rick's post/slides say that IE basically does the same thing as Chrome, and that they're working to get CSS specs updated to accommodate for this feature. I'm not yet sure where that discussion is happening, but it's something we'd want to follow & participate in, if & when we implement something like this.

I don't entirely know what the scope of this is, but I'm filing this bug as a placeholder for now. (We may want to discuss the exact requirements on www-style and/or dev.tech.layout, and then circle back to this bug when there's a clearly-defined set of things to implement.)
Rick mentions http://www.videojs.com/ as a good example.

If you load that page in Fennec, you'll see the fixed-pos navbar header starts out like this:
> [Video.js    Get Started  Download  Docs  Designer  Blog  Help & Support]
...but if you zoom in, it ends up looking like this:
> [Video.js    Get Sta]
...and there's no way to pan across that fixed-pos header to access the rest of the controls, or pan that fixed-pos header offscreen to allow more of the page to be visible.  So, the high-level idea is to zoom & pan using a separate "visual viewport", separate from the viewport that this fixed-pos element gets snapped to.
Summary: Support a "virtual viewport" for Mobile, to allow pinch-zooming without forcing fixed-pos elements to stay on-screen → Support a "visual viewport" ("virtual viewport"?) for Mobile, to allow pinch-zooming without forcing fixed-pos elements to stay on-screen
Could've sworn mbrubeck filed a bug for this a long time (years) ago, but probably easier to track here now. For reference, the layout code that would need to be altered is here: http://hg.mozilla.org/mozilla-central/file/540077a30866/layout/generic/nsViewportFrame.cpp#l159

I guess the gfx code could infer the visual viewport from the zoom, and the async code that would need updating is here: http://hg.mozilla.org/mozilla-central/file/540077a30866/gfx/layers/composite/AsyncCompositionManager.cpp#l262

Given we have async code for sticky positioning, it shouldn't be too hard to mold that code to work for fixed position in visual viewport.
(In reply to Chris Lord [:cwiiis] from comment #2)
> Could've sworn mbrubeck filed a bug for this a long time (years) ago

This is bug 656036.  It's fine if you want to mark the old bug a duplicate of this newer one, since I don't think the old discussion there is still particularly useful.
Keywords: compat, mobile
Whiteboard: [parity-ie][parity-blink]
For the record, Rick links to https://lists.w3.org/Archives/Public/www-style/2015Jan/0004.html as one place (maybe the main place?) where this feature has been discussed with the CSSWG so far.  (See "Viewports and Zoom" section)
Cc'ing Rick also. One thing that's not clear to me from the discussion so far is if window.scrollX/Y is supposed to reflect the layout viewport or the visual viewport in this model. If the visual viewport is supposed to be truly undetectable by content then it should reflect the layout viewport. Then that raises the question of what window.scrollTo and scrollBy are supposed to modify.
Yeah we struggled with that question.  Our initial design (at my insistence really) was that the visual viewport should be completely invisible to the application.  Late in our shipping process we found this broke a number of websites, and was also inconsistent with IE's behavior.  So we switched scrollX/Y, scrollTo/scrollBy and innerWidth/innerHeight to take the visual viewport into account.  See http://crbug.com/435151 for details.
I think overall that's probably the right call. Have you run into problems where websites will "emulate" position:fixed by repositioning content on scroll events? I'm sure such websites exist, and would basically have the same behaviour and problems as our (Firefox's) current position:fixed behaviour. I don't know if there's good way to fix that though, just wondering how prevalent it is.
Yes I think we did, but I'm not sure of details.  I'll ask bokan@ to chime in here.  I'm sure the lack of consistency between browsers here (and Safari's hard-to-reason-about behviour) made it easier to get away with changes here.  Also many mobile sites just disable pinch zoom, so probably don't depend on the behavior much.  Also I should add that we haven't quite shipped this to stable - I still expect to be surprised by some "creative" websites ;-)

I think we're going to have a harder problem when we attempt to change on-screen keyboard behavior to resize only the visual viewport instead of resizing the layout viewport (IE does this and we already do this on ChromeOS, but I expect web compat issues on mobile).
I've definitely come across a couple, but I haven't kept track of these pages. Our implementation doesn't change any web-facing APIs. I've emulated scrollX/Y, scrollTo, etc. so that they behave as they did under our old pinch-zoom path so I'd expect this kind of site that emulates position: fixed with JS to work as it did prior to us making this change. Also of note, when a page is fully zoomed out, there's no visible behavior change at all.
Ok, good to know, thanks. We also have a bug on file for making on-screen keyboard resizing the visual viewport on Firefox OS (bug 970093) although it's not described in quite the same terms. We had some unresolved questions about how to deal with fixed-position items on that bug, but if we keep them attached to the layout viewport then I think that would be acceptable.
See Also: → overlaid-keyboard
I'm not aware of any, but in theory there may be sites that do something on OSK appearance by listening to resize events (and disambiguating them from a rotation). That or position: fixed "toolbars" for text editing that should show up above the keyboard.

These experiences would likely be broken or buggy today since there's little standard support for these cases so I'm sympathetic to your described fixed-position/OSK change. That said, we'd be taking away power from the platform so I think we'd want some new APIs in this space. IE's position:-ms-device-fixed looks promising as it could fix the aforementioned OSK toolbar to the visible area.
Depends on: 656036
For reference, here's the latest draft proposal for this:

https://rawgit.com/WICG/ViewportAPI/master/index.html
Blocks: 1336544
Flags: webcompat? → webcompat+
Blocks: 1388188
Whiteboard: [parity-ie][parity-blink] → [parity-ie][parity-blink] [webcompat]
Blocks: 1296776
It looks like this is a major source of interop issues, is this still something Firefox is going to do? Is there anything I can do to help make it happen?

I'll be at TPAC in November, is there anyone from Mozilla familiar with these issues attending? Would love to chat about how we can improve the situation here.
(In reply to David Bokan from comment #15)
> is this still something Firefox is going to do?

Yes, I hope to get to this in the coming months.
(In reply to David Bokan from comment #15)
> I'll be at TPAC in November, is there anyone from Mozilla familiar with
> these issues attending?

I'll be attending the CSSWG parts of TPAC (as an observer), and so will David Baron (as a CSSWG participant).

He and I both have some familiarity with this problem-space.  If you'll be there for the CSSWG meetings at TPAC, we'll definitely overlap and could have a good discussion about this.  For my own reference: looks like the latest proposed spec-text on this is https://wicg.github.io/ViewportAPI/spec.html
Great, will see you there!

That's the latest spec text for window.visualViewport which is related but orthogonal to this particular bug. Unfortunately there's no spec for how the "virtual viewport" style model should work - that's something that needs to be put together. I'm currently writing up an explainer for that and all the related issues re: keyboard, zooming, URL bar, etc. to brain dump the current situation and problems to get everyone on the same page in terms of concepts and terminology. I'll share that shortly once I finish it up.

I'll try to start up a more formal spec for the viewport model after that.
> Unfortunately there's no spec for how the "virtual viewport" style model should work - that's something that needs to be put together. I'm currently writing up an explainer for that and all the related issues re: keyboard, zooming, URL bar, etc. to brain dump the current situation and problems to get everyone on the same page in terms of concepts and terminology. I'll share that shortly once I finish it up.

David, this is wonderful news. This would probably help a great deal. It's easier to solve this issue if we have a text explaining what is happening.
I looked through the webcompat issues linked to this bug, and they all seem to concern not being able to scroll to bring parts of the page into view.

I wonder if that's something we can fix more quickly, without blocking on the more involved layout change related to the positioning of fixed content.
For a while Safari and Chrome used to ignore overflow: hidden on the document/body elements and allow scrolling even if the page set overflow: hidden. I suspect that would probably make the worst of these work in the mean time.
Botond, David, yup that was the spirit of Bug 1336346
(In reply to David Bokan from comment #21)
> For a while Safari and Chrome used to ignore overflow: hidden on the
> document/body elements and allow scrolling even if the page set overflow:
> hidden. I suspect that would probably make the worst of these work in the
> mean time.

Wouldn't that be undesirable for web applications that use overflow:hidden for keeping other views/pages of their application rendered but out of view?
It is, but the only way to have compat with existing content, and have a rational interpretation of overflow: hidden is to have two viewports. Ignoring overflow: hidden was the compromise made which leaned towards compat over rationality.
It looks like the pattern used in most of the sites from the linked webcompat issues is:

  - A meta viewport tag with "width=device-width".

  - An html or body element with "overflow-x: hidden"
    and a width that's larger than the device width.

The meta viewport tag causes Firefox to size the root scrollable element's "scroll port" (the "layout viewport" in the terminology of the explainer) to the device width, and the "overflow-x: hidden" prevents scrolling horizontally to bring the remaining content into view.

I'm trying to understand Chromium's behaviour in situations like this. From the explanation on this Chromium bug [1]:

> Chrome does honour the overflow: hidden property on <html>/<body> 
> but the behavior can be tricky to understand in cases like this. 
> What's going on:
>
> -Because the content is wider than the viewport, we expand the 
> layout viewport to encompass the whole content width. We need to 
> do this so that the user can zoom out to see the whole page.
>
> -Because the layout viewport is expanded, it has no scrolling. 
> Layout viewport is the regular kind of scrolling you'd see on a 
> desktop or unzoomed mobile site.
>
> -What you're seeing is visual viewport panning which doesn't 
> respect the overflow property (since it's panning within the 
> layout viewport, not the page content).

The part that confuses me is this: if the layout viewport is expanded to encompass the whole content width, then how is the "overflow: hidden" property - and in particular, "overflow-x: hidden" - being honoured? It seems like the behaviour is the same as if the web author hadn't used "overflow-x: hidden".

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=689630#c6
In the case you describe, you're right, the overflow-x: hidden would be superfluous because the layout viewport contains the entire width of the page. Where it would be effective is if the page added "minimum-scale: 1". In that case, the layout viewport would be the size of the device-width and we would respect overflow-x: hidden and actually prevent horizontal scrolling.

Have you tried the page in iOS Safari? I don't remember if they respect overflow-x yet but Safari has the same logic to size the layout viewport as Firefox. If they do respect overflow-x the page would also be broken in Safari.

As mentioned, I'd like Chrome to use the same logic to size the layout viewport as Safari and Firefox. If we did that, I suspect we'd hit the same issues you're seeing here.
(In reply to David Bokan from comment #26)
> In the case you describe, you're right, the overflow-x: hidden would be
> superfluous because the layout viewport contains the entire width of the
> page. Where it would be effective is if the page added "minimum-scale: 1".
> In that case, the layout viewport would be the size of the device-width and
> we would respect overflow-x: hidden and actually prevent horizontal
> scrolling.

Ok, thanks, that's good to know. My thinking was, in relation to this earlier comment...

(In reply to Botond Ballo [:botond] from comment #23)
> Wouldn't that be undesirable for web applications that use overflow:hidden
> for keeping other views/pages of their application rendered but out of view?

... that perhaps web developers _already_ can't use this technique in the horizontal direction, in which case we could safely ignore overflow:hidden in the horizontal direction only without any negative impact on such sites. But it looks like they can use that technique in the horizontal direction too, with appropriate use of minimum-scale.

For a website that doesn't use minimum-scale, though, like many of the sites from the linked issues - do you have a guess as to what the authors' motivation for using overflow-x:hidden might be? It seems to either have no effect (Chromium), or make things worse (Firefox, possibly Safari).
I don't have a good sense but I suspect a lot of it is just copy and pasted from desktop examples - the lack of interop on how overflow-x is handled makes it unlikely it was actually being used correctly.
There are some sites with a specific hack which also renders broken in Firefox but not in Chrome or Safari and relies on this hack.

 <meta name="viewport" id = "viewport" content = "maximum-scale=0.6667; width=480"/>
found for example in https://webcompat.com/issues/3811

>  Notes: This is use of the width=480, maximum-scale=0.6667 
> in the viewport tag. This is an interesting "Holy Grail" 
> for simple web pages that are friendly for the iPhone. 
> With the introduction of maximum-scale of two-thirds, 
> now the fonts in the portrait and the landscape orientations 
> both look the same size. This combination was discovered 
> by iPhoneWebDev member D. Rich. https://web.archive.org/web/20110821005853/http://www.iphonewebdev.com/examples/viewports/viewport-width-480-maximum-scale-6667.html
(Removing issue which has been fixed on the site's side.)
Following up on this earlier point:

(In reply to Botond Ballo [:botond] from comment #20)
> I looked through the webcompat issues linked to this bug, and they all seem
> to concern not being able to scroll to bring parts of the page into view.
> 
> I wonder if that's something we can fix more quickly, without blocking on
> the more involved layout change related to the positioning of fixed content.

(In reply to David Bokan from comment #24)
> the only way to have compat with existing content, and have a
> rational interpretation of overflow: hidden is to have two viewports.

Firefox does already have a notion of two viewports.

This is demonstrated by the testcase attached in the previous comment. The testcase has overflow:hidden on the html element, and overflowing content (red background in the testcase).

When viewed in Firefox for Android, you can zoom in on that page, and pan around while zoomed, but you cannot scroll to bring the red areas into view (this behaviour matches Chrome). So Firefox does have separate notions of "what is currently in view" (visual viewport) and "what bounds you are allowed to scroll within" (fixed / layout viewport).

Is it true that in Firefox, fixed-position elements are attached to the visual viewport and not the layout viewport. But that seems to be orthogonal to the issue underlying the linked webcompat reports.

The issue underlying the linked webcompat reports seems to simply be that in some cases (namely, where the "minimum scale size" as defined in the explainer is larger than the size specified by the meta viewport tag), Firefox is sizing the layout viewport to the latter while Chrome is sizing it to the former.

It seems, therefore, that we can un-break the websites in the webcompat reports by changing how Firefox calculates the size of the layout viewport, which seems like a relatively easy change. Having fixed-position elements attach to the layout viewport, which is much harder, can be pursued as separate change.

Or am I missing something, and these two changes need to go together for some reason?
(In reply to Botond Ballo [:botond] from comment #32)
> Is it true that in Firefox, fixed-position elements are attached to the
> visual viewport and not the layout viewport.

(Sorry, that should read "It is true ...".)
I have encountered several issues, where when I zoom in, fixed elements attached to the visual viewport cover the entire screen, blocking the page.

Maybe that's not what [the webcompat you're describing] says, but that's a real issue.
(In reply to jimbo1qaz from comment #34)
> I have encountered several issues, where when I zoom in, fixed elements
> attached to the visual viewport cover the entire screen, blocking the page.
> 
> Maybe that's not what [the webcompat you're describing] says, but that's a
> real issue.

Agreed, and we do plan to fix that. I was just trying to understand whether the two issues are independent, or need to be changed together for some reason.
As there are multiple different viewport-related issues to be fixed here, I'm going to make this a meta bug to group the various issues, and file dependent bugs for the individual issues.

Over time I also plan to move the webcompat issues linked to this bug to the specific dependent bugs that are applicable to them.
Summary: Support a "visual viewport" ("virtual viewport"?) for Mobile, to allow pinch-zooming without forcing fixed-pos elements to stay on-screen → [meta] Make viewport handling consistent with other browsers
(In reply to Botond Ballo [:botond] from comment #36)
> As there are multiple different viewport-related issues to be fixed here,
> I'm going to make this a meta bug to group the various issues, and file
> dependent bugs for the individual issues.

One of those issues is attaching position:fixed elements to the layout/fixed viewport, not the visual viewport. Bug 656036 is already on file for that, and is already a dependency of this bug.
No longer blocks: 1296776
> When viewed in Firefox for Android, you can zoom in on that page, and pan around while zoomed, but you cannot scroll to bring the red areas into view (this behaviour matches Chrome)

Ah, cool, I didn't know that.

Taking a closer look at the issues above there's one that stands out. Botond is right that it's related to sizing the layout viewport. Chrome sizes the layout viewport to encompass the entire content width. Firefox sizes it to the width specified in the viewport meta tag. This plays especially badly with overflow-x: hidden since from Chrome's POV, the page isn't scrollable at all (but it can be zoomed in and panned) so it has no practical effect. Firefox sees the content as overflowing the layout viewport so it prevents scrolling.

Interestingly, when I try Safari on handcrafted examples it matches Firefox but all the cases I tried above seem to work so I need to do some more investigation here. I actually wanted to make Chrome match Safari and Firefox so I'd be sad to see this go the other way.

There is also the strange case of: https://webcompat.com/issues/3811 which seems to have a hack where maximum-scale < minimum-scale and we differ in precedance. Chrome locks scale to the minimum while Firefox locks it to the maximum. This seems like it'd be an easy fix and we just have to settle on one or the other.
No longer blocks: 1388188
(In reply to David Bokan from comment #38)
> Interestingly, when I try Safari on handcrafted examples it matches Firefox
> but all the cases I tried above seem to work so I need to do some more
> investigation here. I actually wanted to make Chrome match Safari and
> Firefox so I'd be sad to see this go the other way.

I just wrote up [1], which is relevant to this discussion :)

[1] https://github.com/bokand/bokand.github.io/issues/3
yeah, the overflow: hidden handling is one issue. I'm confused about https://webcompat.com/issues/1677 though, why does Safari load it zoomed out when the <meta> width is smaller than the content width? I haven't been able to use devtools on it yet but my understanding is it should have loaded the same as Firefox.
No longer blocks: 1336544
Depends on: 1423013
(In reply to Botond Ballo [:botond] from comment #25)
> It looks like the pattern used in most of the sites from the linked
> webcompat issues is:
> 
>   - A meta viewport tag with "width=device-width".
> 
>   - An html or body element with "overflow-x: hidden"
>     and a width that's larger than the device width.
> 
> The meta viewport tag causes Firefox to size the root scrollable element's
> "scroll port" (the "layout viewport" in the terminology of the explainer) to
> the device width, and the "overflow-x: hidden" prevents scrolling
> horizontally to bring the remaining content into view.

Filed bug 1423013 to track this issue.
No longer blocks: 1334676
(In reply to David Bokan from comment #40)
> yeah, the overflow: hidden handling is one issue. I'm confused about
> https://webcompat.com/issues/1677 though, why does Safari load it zoomed out
> when the <meta> width is smaller than the content width? I haven't been able
> to use devtools on it yet but my understanding is it should have loaded the
> same as Firefox.

Tested Safari on iOS on ipod Touch for the tnm site. 

for <meta name="viewport" content="width=1">
to  <meta name="viewport" content="width=640">

it adjusts to take the full screen, but above starting with 641. It starts to make the layout smaller aka white space around.

The body has a specific width in 
http://www.tnm.jp/themes/iphone/css/ex_sp.css

body {
…
	width: 640px;
…
}


I wonder if the meta viewport width is ignored when the body has a different setting.
Do you mean that the page sets the width in the <meta> dynamically based on the device width?

Re: specific body width, Loading http://bokand.github.io/viewport-wider-than-meta.html in Safari shows that it behaves like Firefox, except that it ignores overflow-x: hidden. Given that and the above, I'd still expect the site to load the same way between Firefox and Safari for the same size screen. Perhaps Safari has some magic heuristics?
No longer blocks: 1292305
Alias: viewport-compat
Depends on: 1423709
As mentioned in comment 42, I moved https://webcompat.com/issues/4190 over to the more specific bug 1423013.
(Removing #4190 per previous comment.)
Moving #9834 over to bug 1331692.
Whiteboard: [parity-ie][parity-blink] [webcompat] → [parity-ie][parity-blink] [webcompat:p1]
Depends on: 1440003
Will anyone write a patch for this, or is it not ready?
(In reply to jimbo1qaz from comment #50)
> Will anyone write a patch for this, or is it not ready?

The viewport handling inconsistencies between Firefox and other browsers are caused by multiple issues. The bugs listed in the "Depends on" field of this bug, such as bug 656036 and bug 1423013, track the individual issues. Patches will be written for those individual issues.

I plan to work on fixing some of those issues; others may as well. I can't promise a time frame, as this is one of several areas of work I'm focusing on.
Blocks: 1178110
User Story: (updated)
Whiteboard: [parity-ie][parity-blink] [webcompat:p1] → [parity-ie][parity-blink] [webcompat:p2]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-ie][parity-blink] [webcompat:p2] → [webcompat:p2]
Depends on: 1313264
Depends on: 1431601
I can reproduce the bug on this page https://arstechnica.com.
Devices LG G4 (Android 5.1), Samsung Galaxy Note 8 (Android 8.0.0) on all branches(Nightly 62.0a1; Beta 61.0b9; Release 60.0.1;)
Depends on: 1340064
Depends on: 1469481
Keywords: meta
Whiteboard: [webcompat:p2] → [webcompat:p2] [geckoview]
Depends on: 1469747
Depends on: 1471708
adding this one here before to re-classify it.
https://webcompat.com/issues/17509

Somehow the site is not being zoomed out, Firefox decides to show it zoomed in.
Depends on: 1064982
Whiteboard: [webcompat:p2] [geckoview] → [webcompat:p1] [geckoview]
(In reply to Daniel Holbert [:dholbert] from comment #17)
> (In reply to David Bokan from comment #15)
> have a good discussion about this.  For my own reference: looks like the
> latest proposed spec-text on this is
> https://wicg.github.io/ViewportAPI/spec.html

The previous link is a 404
This is now at https://wicg.github.io/visual-viewport/
David Bokan is still the editor.
Depends on: 1395365
(removing [webcompat:p1] from the meta bug, we'll prioritize individual bugs instead)
Whiteboard: [webcompat:p1] [geckoview] → [geckoview]
Depends on: 1488969
Depends on: 1489910
Depends on: 1494422
Depends on: 1495015
Depends on: 1498729
Depends on: 1336342
Depends on: 1508177
Depends on: 1510214
Depends on: 1513703
Depends on: 1515980
Depends on: 1516048
Depends on: 1516056
Depends on: 1516364
Depends on: 1516377
Depends on: 1516722
Depends on: 1509575
Depends on: 1519013
Depends on: 1519214
Depends on: 1491213
Whiteboard: [geckoview] → [geckoview][webcompat:p1]

The lack of zoom out makes some websites unusable on mobile, like this one https://github.com/webcompat/web-bugs/issues/24350#issue-399885738

(which was closed but nevertheless is an ongoing issue, and definitely affects compatibility compared to a desktop browser where zooming out in a tiny window works just fine and the site remains usable)

Especially smaller websites aren't going to always test on mobile. This is why this is so important. I hope this won't get buried under "but it's broken in other mobile browsers as well" or "well the site owner can fix it" - in a realistic economy there are always going to be sites that don't do this, sadly, so this is never going to fully work for everyone unless mobile allows the same zooming behavior

jonas, it would be nice to open a new bug for your issue. This bug is a tracker bug to make our mobile browser's behavior match to other mobile browsers.
Thank you!

Oh, sorry about that! filed it here: https://bugzilla.mozilla.org/show_bug.cgi?id=1523503

Depends on: 1523541
Depends on: 1523844
Depends on: 1526940
Depends on: 1527187
Depends on: 1527511
Depends on: 1531106
No longer depends on: 1527511
Depends on: 1534454
Depends on: 1542930
Depends on: 1542933
Depends on: 1544146
Depends on: 1544649
No longer depends on: 1544146

See bug 1547409. Migrating webcompat priority whiteboard tags to project flags.

Webcompat Priority: --- → P1
Depends on: 1543485
Depends on: 1553689
Depends on: 1564021
Depends on: 1564025
Depends on: 1564253

For testing reference, note that there are web platform tests for the visual viewport API, as shown here. However, these do not appear to cover whether browsers select the same initial viewport. Also, I see no WPTs for meta viewport (aside from this one which does not really test the layout, just whether the meta viewport tag works at all in a given situation).

Blink and WebKit have viewport tests which appear to cover meta viewport as well as some initial viewport measurement tests. Gecko has some meta viewport tests at dom/base/test/test_meta_viewport and also couple of trivial initial initial viewport tests, for HTML and XML.

IIRC, there is no web platform test support for mobile devices. In Chrome at least, we only parse/process the viewport meta tag and perform the "initial viewport" selection on mobile. Hence the reason for lack of WPT tests. We'd need to update the harness to support this.

Whiteboard: [geckoview][webcompat:p1] → [geckoview][webcompat:p1][needs-wpt-?]
Depends on: 1556275
Depends on: 1563649
Depends on: 1570793
Depends on: 1573648
Depends on: 1594451
Depends on: 1598487
Depends on: 1602706
Depends on: 1606114
Depends on: 1610731
Depends on: 1610959
Depends on: 1659894
Depends on: 1663634
Depends on: 1673517
Depends on: 1007286
Depends on: 1517172
Depends on: 1682664
Depends on: 1687551
Depends on: 1690302
Whiteboard: [geckoview][webcompat:p1][needs-wpt-?] → [geckoview][needs-wpt-?]
Depends on: 1733572
Depends on: 1641166
Depends on: 1598978
Depends on: 1595455
Depends on: 1723485
Depends on: 1754487

The severity field for this bug is set to normal. However, this bug has a P1 WebCompat priority.
:dholbert, could you consider increasing the severity of this web compatibility bug?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #64)

The severity field for this bug is set to normal. However, this bug has a P1 WebCompat priority.

Let's just reset the WebCompat priority flag, since this is a metabug (i.e. a category) rather than a specific issue/change-to-be-made. It doesn't make sense for the whole category/metabug to have a WebCompat priority associated with it.

If there are individual dependent issues that are high-priority, we can assign P1 WebCompat priority on those (and I suspect we already have done so).

(Note that we've also fixed some dependent bugs since the webcompat priority flag was set here [initially as a whiteboard status] 3 years ago, so it's possible that the p1 evaluation might've changed due to those bugfixes.)

Webcompat Priority: P1 → ---
Flags: needinfo?(dholbert)

(actually it looks like miketaylr made this same decision to remove the priority from the metabug back in comment 56, but then added it back later on, possibly by accident [?]. Anyway, removing it is the right call, particularly given that we migrated all of the see-also webcompat.com bug reports off of this bug and onto other more-specific bugs.)

Depends on: 1791342
Severity: normal → S3
Depends on: 1871448
No longer depends on: 1871448
Depends on: 1875566
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: