Bug 1123938 (viewport-compat)

[meta] Make viewport handling consistent with other browsers

NEW
Unassigned

Status

()

defect
4 years ago
7 days ago

People

(Reporter: dholbert, Unassigned)

Tracking

(Depends on 18 bugs, 5 keywords)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
webcompat +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [geckoview][webcompat:p1], URL)

User Story

Business driver: Mobile Webcompat (multiple site issues reported )

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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.)
(Reporter)

Comment 1

4 years ago
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]
(Reporter)

Comment 4

4 years ago
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.

Comment 6

4 years ago
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.

Comment 8

4 years ago
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).

Comment 9

4 years ago
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

Comment 11

4 years ago
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
Duplicate of this bug: 1336346
Flags: webcompat? → webcompat+
Blocks: 1388188
Whiteboard: [parity-ie][parity-blink] → [parity-ie][parity-blink] [webcompat]
Blocks: 1296776

Comment 15

2 years ago
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.
(Reporter)

Comment 17

2 years ago
(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

Comment 18

2 years ago
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.

Comment 21

a year ago
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?

Comment 24

a year ago
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

Comment 26

a year ago
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).

Comment 28

a year ago
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 ...".)

Comment 34

a year ago
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

Comment 38

a year ago
> 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

Comment 40

a year ago
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.

Comment 44

a year ago
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

Comment 50

a year ago
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.
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

Comment 53

11 months ago
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

Updated

10 months ago
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

Updated

8 months ago
Depends on: 1489910
Depends on: 1494422

Updated

7 months ago
Depends on: 1495015
Depends on: 1498729
Depends on: 1336342
Depends on: 1508177
Depends on: 1510214
Depends on: 1513703

Updated

4 months ago
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]

Comment 58

3 months ago

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!

Comment 60

3 months ago

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

Updated

11 days ago
Depends on: 1544146
Depends on: 1544649
No longer depends on: 1544146
You need to log in before you can comment on or make changes to this bug.