Closed Bug 1492582 Opened Last year Closed 7 days ago

browser.xhtml: Migrate root xul:window element to an html:html element

Categories

(Firefox :: General, task, P3)

task

Tracking

()

RESOLVED FIXED
Firefox 72
Tracking Status
firefox72 --- fixed

People

(Reporter: bgrins, Assigned: bdahl)

References

(Depends on 1 open bug, Blocks 5 open bugs, Regressed 5 open bugs)

Details

Attachments

(12 files, 8 obsolete files)

403.65 KB, image/png
Details
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
152.86 KB, image/png
Details
410.86 KB, image/png
Details
497.26 KB, image/png
Details
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
Right now we preprocess the markup from browser.xul into browser.xhtml. This makes it easier to keep up to date and also means that the root element continues to be a xul:window.

This generally works, but it causes some weird issues related to document.head and document.body being null. I think we can change this and make it an actual <html> tag (with <head> and <body> below), but it'll take some care to make sure all the same CSS rules apply to the :root node, and that any code expecting a xul documentElement can handle the change.
We'll also need to handle direct descendant selectors on #main-window as well, since those will now have (at least) a <body> in between, and probably another wrapper (XUL_NS) element: https://searchfox.org/mozilla-central/search?q=%23main-window%5B%5E%5Cs%5D*+%3E&case=false&regexp=true&path=
(In reply to Brian Grinstead [:bgrins] from comment #1)
> We'll also need to handle direct descendant selectors on #main-window as
> well, since those will now have (at least) a <body> in between, and probably
> another wrapper (XUL_NS) element:
> https://searchfox.org/mozilla-central/search?q=%23main-
> window%5B%5E%5Cs%5D*+%3E&case=false&regexp=true&path=

Dão, would you be OK with changing these selectors to no longer be direct descendants from #main-window? That would let us limit the number of changes between browser.xul and browser.xhtml, and since these are selecting IDs below the window I'd expect this to not cause a performance issue.
Flags: needinfo?(dao+bmo)
(In reply to Brian Grinstead [:bgrins] from comment #2)
> (In reply to Brian Grinstead [:bgrins] from comment #1)
> > We'll also need to handle direct descendant selectors on #main-window as
> > well, since those will now have (at least) a <body> in between, and probably
> > another wrapper (XUL_NS) element:
> > https://searchfox.org/mozilla-central/search?q=%23main-
> > window%5B%5E%5Cs%5D*+%3E&case=false&regexp=true&path=
> 
> Dão, would you be OK with changing these selectors to no longer be direct
> descendants from #main-window? That would let us limit the number of changes
> between browser.xul and browser.xhtml, and since these are selecting IDs
> below the window I'd expect this to not cause a performance issue.

This list is incomplete as it doesn't cover :root...

(In reply to Brian Grinstead [:bgrins] from comment #0)
> This generally works, but it causes some weird issues related to
> document.head and document.body being null.

What weird issues? I think the HTML spec doesn't require a body element, does it?
Flags: needinfo?(dao+bmo)
(In reply to Dão Gottwald [::dao] from comment #4)
> (In reply to Brian Grinstead [:bgrins] from comment #2)
> > (In reply to Brian Grinstead [:bgrins] from comment #1)
> > > We'll also need to handle direct descendant selectors on #main-window as
> > > well, since those will now have (at least) a <body> in between, and probably
> > > another wrapper (XUL_NS) element:
> > > https://searchfox.org/mozilla-central/search?q=%23main-
> > > window%5B%5E%5Cs%5D*+%3E&case=false&regexp=true&path=
> > 
> > Dão, would you be OK with changing these selectors to no longer be direct
> > descendants from #main-window? That would let us limit the number of changes
> > between browser.xul and browser.xhtml, and since these are selecting IDs
> > below the window I'd expect this to not cause a performance issue.
> 
> This list is incomplete as it doesn't cover :root...

Oh, good catch. Is there a particular reason we sometimes use :root instead of #main-window in browser.css? https://searchfox.org/mozilla-central/search?q=%3Aroot%5B%5E%5Cs%5D*+%3E&regexp=true&path=.css

Do we use direct 
> (In reply to Brian Grinstead [:bgrins] from comment #0)
> > This generally works, but it causes some weird issues related to
> > document.head and document.body being null.
> 
> What weird issues? I think the HTML spec doesn't require a body element,
> does it?

We have to special case a null body for some focus stuff (bug 1492327), and I think there's various code around assuming document.head / document.body is available (i.e. in Bug 1492247). For [dir] support we'll also need to use at least 1 HTML element, I think, although I haven't tested if we can set that on <html> or if it needs to be on a child node (bug 1498287).

It's looking like there may be enough issues with switching the root element to html that we may want to hold off on this bug for now. But it seems likely we'll want to wrap the content inside an html namespaced node for RTL support, and if so we'll still want to remove these direct descendant selectors for that.
See Also: → 1498287
(In reply to Brian Grinstead [:bgrins] from comment #5)
> Oh, good catch. Is there a particular reason we sometimes use :root instead
> of #main-window in browser.css?

No good reason. We should normally use :root.

> Do we use direct 
> > (In reply to Brian Grinstead [:bgrins] from comment #0)
> > > This generally works, but it causes some weird issues related to
> > > document.head and document.body being null.
> > 
> > What weird issues? I think the HTML spec doesn't require a body element,
> > does it?
> 
> We have to special case a null body for some focus stuff (bug 1492327), and
> I think there's various code around assuming document.head / document.body
> is available (i.e. in Bug 1492247). For [dir] support we'll also need to use
> at least 1 HTML element, I think, although I haven't tested if we can set
> that on <html> or if it needs to be on a child node (bug 1498287).

I see no reason why <html> couldn't be used for that. <html> == document.rootElement == :root, so this neatly matches our current XUL setup.

In most XHTML document we usually use <body dir="&locale.dir;"> but <html dir="&locale.dir;"> should work just as well. In fact this might be preferred for document.dir to do the right thing: https://html.spec.whatwg.org/multipage/dom.html#dom-document-dir
(In reply to Dão Gottwald [::dao] from comment #6)
> > We have to special case a null body for some focus stuff (bug 1492327), and
> > I think there's various code around assuming document.head / document.body
> > is available (i.e. in Bug 1492247). For [dir] support we'll also need to use
> > at least 1 HTML element, I think, although I haven't tested if we can set
> > that on <html> or if it needs to be on a child node (bug 1498287).
> 
> I see no reason why <html> couldn't be used for that. <html> ==
> document.rootElement == :root, so this neatly matches our current XUL setup.
> 
> In most XHTML document we usually use <body dir="&locale.dir;"> but <html
> dir="&locale.dir;"> should work just as well. In fact this might be
> preferred for document.dir to do the right thing:
> https://html.spec.whatwg.org/multipage/dom.html#dom-document-dir

Alright, I can try that. In that case we'd still want a wrapping XUL namespaced element so that the default namespace for elements inside browser.xul flips back to XUL (which means we'll need to fix this direct descendant thing anyway).
(In reply to Brian Grinstead [:bgrins] from comment #7)
> In that case we'd still want a wrapping XUL
> namespaced element so that the default namespace for elements inside
> browser.xul flips back to XUL

We don't actually want that in the long run, do we?
(In reply to Dão Gottwald [::dao] from comment #8)
> (In reply to Brian Grinstead [:bgrins] from comment #7)
> > In that case we'd still want a wrapping XUL
> > namespaced element so that the default namespace for elements inside
> > browser.xul flips back to XUL
> 
> We don't actually want that in the long run, do we?

No, not in the long run. But I'm hoping that we can ship browser.xhtml with the current XUL markup, and then chip away at the XUL markup over time (esp once we start using CSS flexbox for -moz-box).

An alternative would be to explicitly xul namespace any current direct descendants of #main-window (including stuff loaded from .inc files). We could make that easier by wrapping the various sets at the top of the file into a xul box so we have a lot less direct descendants.
(In reply to Brian Grinstead [:bgrins] from comment #9)
> An alternative would be to explicitly xul namespace any current direct
> descendants of #main-window (including stuff loaded from .inc files).

This sounds reasonable and easy enough. #main-window has only about 17 child elements at the moment.
Another benefit to switching to a root html element is that it lets us use the real DevTools highlighters in the Browser Toolbox (instead of the red dotted outline). Feels much better. I tried wiring up the various isXUL checks to check document.contentType instead of the namespace URI in documentElement, but I think the anonymous content container only works properly when the documentElement isn't XUL.
There's something weird here, where using an html tag even with all the same css rules (-moz-box display, etc) the children don't flex properly. But if I wrap everything in a manually sized xul:vbox (100vw, 100vh) it does. I guess XUL flex is somehow behaving differently for html elements vs xul elements. Going to put this on hold for now - pushed up what I have so far.
No longer blocks: top-level-html
Depends on: 1533881
Blocks: 1533881
No longer depends on: 1533881
No longer blocks: 1533881
Depends on: 1533881
Depends on: 1534407
No longer depends on: 1533881
Attachment #9018661 - Attachment description: Bug 1492582 - WIP - Use html root element in browser.xhtml → Bug 1492582 - Use html root element in browser.xhtml

I notice with a rebased version of this patch that context menus in the browser doc aren't working (like right clicking to enter customize mode). I suspect there's some check for <window> tags that might need to be including chrome <html> (https://searchfox.org/mozilla-central/search?q=atoms%3A%3Awindow&case=false&regexp=false&path=).

One of the major differences is also the frame layout. With a root XUL element things are pretty different. Not sure how much all of it matters though.

https://searchfox.org/mozilla-central/rev/94c6b5f06d2464f6780a52f32e917d25ddc30d6b/layout/base/nsCSSFrameConstructor.cpp#2317

One of the benefits to doing this is we could get rid of the red dotted outline in the Browser Toolbox and use the actual Inspector highlighter instead (see screenshot).

You have no idea how happy this is making me right now!

Depends on: 1556539
Attachment #9018661 - Attachment is obsolete: true

Note that not all of them need to accommodate html|html - especially in browser/ some of these are for other windows and not loaded in browser.xhtml.

In preparation for an <html> root node in browser.xhtml, we need to react to lwtheme changes correctly.

Depends on: 1556857

Comment on attachment 9069759 [details]
Bug 1492582 - Return true in AttributeChangeRequiresSubtreeRestyle whenever lwtheme attrs change in any chrome doc, not just those with XUL document elements

Revision D33693 was moved to bug 1556857. Setting attachment 9069759 [details] to obsolete.

Attachment #9069759 - Attachment is obsolete: true

For the issue where the context menu isn't working, here are a few observations:

I'm seeing some test failures that seem focus related. For instance toolkit/components/satchel/test/browser/browser_close_tab.js is failing at https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/toolkit/components/satchel/test/browser/browser_close_tab.js#31, and when I run it locally the input field isn't focused (it should be due to line 26 calling input.focus() in a ContentTask).

I see references to different focus behavior based on the document element at https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/browser/base/content/test/general/browser_tabfocus.js#453-457, and in bugs we've taken for the initial browser.xhtml work (bug 1492327, bug 1502523).

This is a difference between HTML and XUL elements. Just matching the test to expect
the HTML behavior.

Depends on D33561

Previously we were returning the documentElement in order to match the old XUL behavior.
Now that we have a document.body we can just follow the normal HTML convention.

Depends on D34020

This would be better solved with a layout fix

Depends on D34021

Depends on: 1557812

Comment on attachment 9070373 [details]
Bug 1492582 - Fix test that expects getAttribute to return "" instead of null on documentElement without the attribute

Revision D34020 was moved to bug 1557812. Setting attachment 9070373 [details] to obsolete.

Attachment #9070373 - Attachment is obsolete: true

(In reply to Brian Grinstead [:bgrins] from comment #23)

For the issue where the context menu isn't working, here are a few observations:

Emilio, I think I'm hitting some weird layout case here. If I apply the <html> root node for the browser window patch (https://phabricator.services.mozilla.com/D33558), then the top level context menu isn't showing when I right click on a tab, for instance. I have a temporary workaround (https://phabricator.services.mozilla.com/D34023) that fixes it at least on OSX (I believe it still isn't working on Windows) which prevents the main popupset from getting layout until DOMContentLoaded.

My analysis in the quoted comment is as far as I've gotten and I could use some help tracking it down further. There's an alternate workaround which unconditionally uses NS_NewDocElementBoxFrame in browser.xhtml, but I think we should be able to get this working with a normal frame since we have code supporting popupgroups for normal root elements in nsCanvasFrame.

Flags: needinfo?(emilio)

This is the alternate approach mentioned in Comment 30

Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED

Hi Jim, when migrating from <xul:window> to <html:html> for the root element in browser.xhtml (this patch: https://phabricator.services.mozilla.com/D33558), I'm seeing an issue in Windows 7. AFAICT all the same CSS rules are applying, including the correct -moz-appearances on the root node and #titlebar (note that even though it's crossed out in devtools it's still applying - that's just devtools getting confused).

I've looked around at https://searchfox.org/mozilla-central/search?q=mozwinborderlessglass&path= and https://searchfox.org/mozilla-central/search?q=MozWindowTitlebar&path= but I don't really know what I'm looking for - and my win7 full build has somehow broken in the last couple of months, including ./mach bootstrap failures :(. Could you help me debug this or point me to someone who could?

Flags: needinfo?(jmathies)

(In reply to Brian Grinstead [:bgrins] from comment #32)

Hi Jim, when migrating from <xul:window> to <html:html> for the root element in browser.xhtml (this patch: https://phabricator.services.mozilla.com/D33558), I'm seeing an issue in Windows 7.

Also, AFAICT things look correct on Windows 10 with the patch.

One more weird thing I've noticed - when resizing the window as small as possible with the <xul:window> the window won't shrink below the min-width and min-height of the document element, but with <html:html> it does. Looks like about 73x38 for html instead of 335x60 for window.

(In reply to Brian Grinstead [:bgrins] from comment #34)

One more weird thing I've noticed - when resizing the window as small as possible with the <xul:window> the window won't shrink below the min-width and min-height of the document element, but with <html:html> it does. Looks like about 73x38 for html instead of 335x60 for window.

This may be due to an early return in nsContainerFrame::SyncWindowProperties (https://searchfox.org/mozilla-central/rev/0da35261b6789eec65476dbdd4913df6e235af6d/layout/generic/nsContainerFrame.cpp#570-588). I also see some calls related to transparency in there, so maybe this is a factor in some of the windows widget issues from Comment 32.

Depends on: 1558352

(In reply to Brian Grinstead [:bgrins] from comment #30)

(In reply to Brian Grinstead [:bgrins] from comment #23)

For the issue where the context menu isn't working, here are a few observations:

This is exactly right. This is because canvas frame != doc element frame, and canvas anon content kinda works specially.

We are already careful with the order we stash anonymous content in because of this very reason, see:

The tl;dr: is that canvas anonymous content is a pretty special case, while the doc element's anonymous content is less special, and falls through the path linked above. If we want to make popups work properly in HTML-ish stuff, then we need to make it work more like that, which is what bug 1558352 does.

I think that's non-terrible enough that we should land it.

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #36)

(In reply to Brian Grinstead [:bgrins] from comment #30)

(In reply to Brian Grinstead [:bgrins] from comment #23)

For the issue where the context menu isn't working, here are a few observations:

This is exactly right. This is because canvas frame != doc element frame, and canvas anon content kinda works specially.

We are already careful with the order we stash anonymous content in because of this very reason, see:

The tl;dr: is that canvas anonymous content is a pretty special case, while the doc element's anonymous content is less special, and falls through the path linked above. If we want to make popups work properly in HTML-ish stuff, then we need to make it work more like that, which is what bug 1558352 does.

I think that's non-terrible enough that we should land it.

Thank you for taking this! I tested locally on OSX and Windows 10 and can confirm that this fixes the context menu.

Attachment #9070987 - Attachment is obsolete: true
Attachment #9070376 - Attachment is obsolete: true
Flags: needinfo?(jmathies)

The windows 7 aero issue in Comment 32 is distinct from Emilio's fix in Comment 36. I could still use help tracking the aero issue down. My best guess is that the widget stuff is being affected by not using nsDocElementBoxFrame anymore. If you or someone else who knows the windows bits here could help debug this it would be a big help.

Flags: needinfo?(jmathies)

Emilio, the context menus and popups are now working, but when I open the hamburger popup on OSX with the html document element (https://phabricator.services.mozilla.com/D33558) I see:

[Parent 40011, Main Thread] ###!!! ASSERTION: Out-of-flow frame got reflowed before its placeholder: 'Error', file /Users/bgrins/Code/mozilla-central/layout/generic/nsPlaceholderFrame.cpp, line 137

Could you see if anything sticks out from the layout side if you have a chance?

Flags: needinfo?(emilio)

Another windows issue (separate from Comment 38) is that with https://phabricator.services.mozilla.com/D33558 applied some panels (the hamburger menu, identity popup) do not show up when clicking on their corresponding button. If I manually call something like document.getElementById("appMenu-popup").openPopup() in the browser console the panel becomes visible.

(In reply to Brian Grinstead [:bgrins] from comment #39)

Emilio, the context menus and popups are now working, but when I open the hamburger popup on OSX with the html document element (https://phabricator.services.mozilla.com/D33558) I see:

[Parent 40011, Main Thread] ###!!! ASSERTION: Out-of-flow frame got reflowed before its placeholder: 'Error', file /Users/bgrins/Code/mozilla-central/layout/generic/nsPlaceholderFrame.cpp, line 137

Could you see if anything sticks out from the layout side if you have a chance?

So I'm not quite sure how abspos inside a popup is supposed to work, but the assertion is not lying, as in: Right now the abspos is parented to the canvas frame, but its placeholder is in a popup and thus not laid out until it's open.

I'm not sure what the general model is, probably popups should be abspos containing blocks? I'll check what the XUL code is doing...

Just wanted to clarify the outstanding issues I'm seeing here. Mochitests are getting pretty close (minus the windows popup not opening issue): https://treeherder.mozilla.org/#/jobs?repo=try&revision=6462a405ff4a41f297a044de7024a868ada86682.

There are a few layout issues:

  • Comment 35: The window gets resized too small (probably due to an early return in SyncWindowProperties)
  • Comment 39: Assertion when opening hamburger menu
  • Comment 40: Windows popups not opening, at least when they are triggered via the mouse

And then a Windows widget / styling issue:

I haven't dug pretty hard, but in XUL the out-of-flow doesn't seem to end up parented to the canvas. In any case we reflow the out of flow again after opening the popup so it doesn't seem this is causing incorrect behavior...

I think https://searchfox.org/mozilla-central/rev/227f5329f75bd8b16c6b146a7414598a420260cb/layout/base/nsCSSFrameConstructor.cpp#2581 means that by default in XUL the root frame is not an abspos containing block, which means that we end up parenting the abspos to the regular parent here:

https://searchfox.org/mozilla-central/rev/227f5329f75bd8b16c6b146a7414598a420260cb/layout/base/nsCSSFrameConstructor.cpp#1073

Boris, do you know / have a strong opinion how an abspos inside a popup is supposed to work?

If the above is right, the answer right now is "in XUL they just don't, and we parent them to the regular parent", and now with HTML is "we parent them to the canvas", which seems wrong since we don't reflow the popup necessarily.

I guess we should just make popups absolute / fixed-pos containing blocks, or something of that sort. WDYT?

Flags: needinfo?(emilio) → needinfo?(bzbarsky)

we'd still want a wrapping XUL namespaced element so that the default namespace for elements inside browser.xul flips back to XUL

You could do:

  <html:html xmlns:html="stuff" xmlns="xul">

to have the default namespace declared for the element and its descendants be xul but have the element itself in the html namespace, fwiw. Not sure whether at this late date that's useful.

This is a screenshot of the issue from Comment 35. You can see that [width=73] and [height=38] but the Layout panel shows 335x60 (335 is the min-width from CSS, I'm not sure where 60 is coming from).

If I run the same test case on m-c (shrink the window as much as possible) then I see [width="335"] and [height=99] with the layout panel showing 335×121. I notice that the height in the layout panel is 22px larger than the height attribute in both cases. I don't know where any of the height values are coming from in either case).

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #44)

we'd still want a wrapping XUL namespaced element so that the default namespace for elements inside browser.xul flips back to XUL

You could do:

  <html:html xmlns:html="stuff" xmlns="xul">

to have the default namespace declared for the element and its descendants be xul but have the element itself in the html namespace, fwiw. Not sure whether at this late date that's useful.

That's interesting. I'll try that on the body element and see if it helps with perf / simplifying CSS.

(In reply to Brian Grinstead [:bgrins] from comment #46)

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #44)

we'd still want a wrapping XUL namespaced element so that the default namespace for elements inside browser.xul flips back to XUL

You could do:

  <html:html xmlns:html="stuff" xmlns="xul">

to have the default namespace declared for the element and its descendants be xul but have the element itself in the html namespace, fwiw. Not sure whether at this late date that's useful.

That's interesting. I'll try that on the body element and see if it helps with perf / simplifying CSS.

I guess the children underneath that use [flex] may not be happy to have a block parent. Though I guess we could -moz-box the body as well..

Boris, do you know / have a strong opinion how an abspos inside a popup is supposed to work?

Making the popup an abspos containing block would make a lot of sense to me.

As far as current behavior in XUL: the root is not an abspos containing block in xul per the first link in comment 43 and neither is the popup (it's explicitly FCDATA_SKIP_ABSPOS_PUSH, like most XUL frame construction data). GetGeometricParent will return the content parent, sure, per the second link in comment 43. But then when we go to nsFrameConstructorState::AddChild we will presumably get null in outOfFlowFrameList->containingBlock and therefore not actually put the thing out of flow at all. There would be no placeholder, and it would just be treated as if it were not abspos in terms of rendering. This does raise the question of why it has abspos styling at all, assuming my analysis is correct...

Flags: needinfo?(bzbarsky)

Brian, so it looks that the element causing the assertion is https://searchfox.org/mozilla-central/rev/227f5329f75bd8b16c6b146a7414598a420260cb/browser/components/customizableui/PanelMultiView.jsm#378 / https://searchfox.org/mozilla-central/rev/1133b6716d9a8131c09754f3f29288484896b8b6/browser/base/content/browser.css#120. If we're right, that element is not getting out-of-flow right now, so that rule is unnecessary. Removing that rule should avoid the assertion and prevent changing behavior.

We can consider to make popups be sounder as described above too, but that would be a bit more risk / separate bug, I'd think.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #49)

Brian, so it looks that the element causing the assertion is https://searchfox.org/mozilla-central/rev/227f5329f75bd8b16c6b146a7414598a420260cb/browser/components/customizableui/PanelMultiView.jsm#378 / https://searchfox.org/mozilla-central/rev/1133b6716d9a8131c09754f3f29288484896b8b6/browser/base/content/browser.css#120. If we're right, that element is not getting out-of-flow right now, so that rule is unnecessary. Removing that rule should avoid the assertion and prevent changing behavior.

We can consider to make popups be sounder as described above too, but that would be a bit more risk / separate bug, I'd think.

Thank you. I've confirmed locally that the assertion goes away when removing that line. It even seems like it fixes the missing popups on Windows (comment 40)! I'll do a try push to see if that holds.

We should really figure out why that line is there, if we can...

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #51)

We should really figure out why that line is there, if we can...

So I just checked with my patch sub-panel navigation is totally broken in the hamburger menu. I originally thought this was due to the removed position: absolute rule, but even when reverting that change I see the same behavior.

For example: Going from hamburger menu -> Library doesn't animate in anymore, and once I'm there I am stuck and can't go one level deeper (Bookmarks) or one level back. I also notice weird things like the hover state on the buttons aren't rendering. It's almost like the panel stops receiving any events at all after navigating to the subview.

I inspected the panel in the browser toolbox (see screenshot) and it's bounds are both in the wrong place (on the left of the screen instead of the right) and are possibly being constrained to the height of the browser window (although I'm not sure if that's a bug in the tooling).

Surprised this doesn't fail tests, I wonder if it works in our test environment (like when the panel is opened programmatically).

Anyway, it seems like something's gone very awry here and we might need some more fixes on the layout side.

Sorry to keep bugging you on this, but if you have some time to look into the issue in Comment 52 it would be much appreciated. I have updated https://phabricator.services.mozilla.com/D33558 to be up to date with tip and also to comment out the position: absolute rule (though as noted, the core problem seems to happen even without that line removed).

Flags: needinfo?(emilio)

Potential fix for the min / max-width issue:

diff --git a/layout/generic/nsContainerFrame.cpp b/layout/generic/nsContainerFrame.cpp
index c1616f985a93..ae810eb57b88 100644
--- a/layout/generic/nsContainerFrame.cpp
+++ b/layout/generic/nsContainerFrame.cpp
@@ -612,10 +612,21 @@ void nsContainerFrame::SyncWindowProperties(nsPresContext* aPresContext,
     return;
   }
 
-  nsBoxLayoutState aState(aPresContext, aRC);
-  nsSize minSize = rootFrame->GetXULMinSize(aState);
-  nsSize maxSize = rootFrame->GetXULMaxSize(aState);
-
+  auto* pos = rootFrame->StylePosition();
+  nsSize minSize(0, 0);
+  nsSize maxSize(NS_UNCONSTRAINEDSIZE, NS_UNCONSTRAINEDSIZE);
+  if (pos->mMinWidth.ConvertsToLength()) {
+    minSize.width = pos->mMinWidth.ToLength();
+  }
+  if (pos->mMinHeight.ConvertsToLength()) {
+    minSize.height = pos->mMinHeight.ToLength();
+  }
+  if (pos->mMaxWidth.ConvertsToLength()) {
+    maxSize.width = pos->mMaxWidth.ToLength();
+  }
+  if (pos->mMaxHeight.ConvertsToLength()) {
+    maxSize.height = pos->mMaxHeight.ToLength();
+  }
   SetSizeConstraints(aPresContext, windowWidget, minSize, maxSize);
 #endif
 }

Sorry for not getting to the previous comment first.

Sorry for the lag getting to this again. I finally got some time to take a look. I don't think there's any layout bug involved. The issue here is that PanelMultiView gets stuck in the transitioning state. The lack of pointer events is due to this rule.

Now, why doesn't it start transitioning? The reason is that PanelMultiView uses var(--animation-easing-function), which is defined in xul.css.

So the style that PanelMultiView sets is invalid, and thus we never trigger the transition. Applying this patch fixes the issue for me:

diff --git a/browser/base/content/browser.css b/browser/base/content/browser.css
index d6718a590c3c..2255ecd0341d 100644
--- a/browser/base/content/browser.css
+++ b/browser/base/content/browser.css
@@ -5,6 +5,10 @@
 @namespace xul url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");
 @namespace html url("http://www.w3.org/1999/xhtml");
 
+:root {
+  --animation-easing-function: cubic-bezier(.07, .95, 0, 1);
+}
+
 :root,
 body,
 #browser-ui-wrapper {

Though it's probably not the right fix. What the right fix is I don't know, maybe that plus removing the xul.css declaration, if all the users of this variable also use browser.css. Or something.

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #55)

Sorry for the lag getting to this again. I finally got some time to take a look. I don't think there's any layout bug involved. The issue here is that PanelMultiView gets stuck in the transitioning state. The lack of pointer events is due to this rule.

Now, why doesn't it start transitioning? The reason is that PanelMultiView uses var(--animation-easing-function), which is defined in xul.css.

So the style that PanelMultiView sets is invalid, and thus we never trigger the transition. Applying this patch fixes the issue for me:

Ahh, thank you for figuring that out. I should have noticed that, but I thought it was related to all the other layout issues going on so didn't look there. I'll apply it on *|*:root in xul.css for now since it's needed in rules within xul.css and other toolkit callers.

Depends on: 1561326
Depends on: 1561482
Depends on: 1572246

My latest try patch with bug 1561326 applied and a few other fixes.

The last bug I was working on was the MacOS bug test_queryCaretRect.html. With the above patches we start getting an extra offset at the top of the page that the test opens. I tracked down the extra space and it comes from here. If we remove that or change content: none, the test works as expected.

See Also: → 1572651
Depends on: 1583403

(In reply to Brian Grinstead [:bgrins] from comment #32)

Created attachment 9070994 [details]
moz-win-borderless-glass.png

Hi Jim, when migrating from <xul:window> to <html:html> for the root element in browser.xhtml (this patch: https://phabricator.services.mozilla.com/D33558), I'm seeing an issue in Windows 7. AFAICT all the same CSS rules are applying, including the correct -moz-appearances on the root node and #titlebar (note that even though it's crossed out in devtools it's still applying - that's just devtools getting confused).

I've looked around at https://searchfox.org/mozilla-central/search?q=mozwinborderlessglass&path= and https://searchfox.org/mozilla-central/search?q=MozWindowTitlebar&path= but I don't really know what I'm looking for - and my win7 full build has somehow broken in the last couple of months, including ./mach bootstrap failures :(. Could you help me debug this or point me to someone who could?

Aaron, any chance you could help us figure out what is going on here or point us to someone who could? The problem can be seen in https://bugzilla.mozilla.org/attachment.cgi?id=9070994 - the titlebar is white and we can't see window controls (minimize, maximize, close) when we switch from a <xul:window> to <html:html> in browser.xhtml, even though all the css rules seem to be applying correctly.

There's a rollup patch at https://treeherder.mozilla.org/#/jobs?repo=try&revision=b64aa1a4d9a8c5a46500212867bfb0c7ca813193

Flags: needinfo?(jmathies) → needinfo?(aklotz)

Jim is back from PTO today. He should be redirecting this as necessary.

Flags: needinfo?(aklotz) → needinfo?(jmathies)

interesting collection of perf results using the html:html root element instead of xul:window: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=a64da897c474ba03f282a54b8c7f6f443850e033&newProject=try&newRevision=dfa7976a04af9f74f80b4fcf200178363550dc71&framework=1&showOnlyImportant=1.

We are trying to figure out why tart/tresize regresses - it seems like we are hitting an unexpected case in painting code (https://mozilla.logbot.info/gfx/20191009#c16681358). But the ts_paint windows improvements are dramatic (~10%). I hope they stick and aren't related to the issues in Comment 32 (since Comment 32 only affects Win7 but the improvements apply to both Win7 and Win10).

Those are really compelling numbers for ts_paint / startup_about_home_paint!

I believe both tresize and TART work by putting the refresh driver into ASAP mode (paint and composite as soon as possible, rather than waiting for the 16ms vsync), and then measuring the time it takes to paint each frame.

So it sounds to me like perhaps painting the window has gotten slightly more expensive.

I opened up the raw logs of two randomly selected runs on Win 10 x64 shippable. Here is the run data from one cycle for the base and patch case::

Base

[task 2019-10-02T23:22:25.910Z] 23:22:25     INFO -  PID 2336 | simple-open-DPI1.raw.TART: 18.0 2.5 9.1 3.6 1.3 1.8 1.0 1.4 0.9 0.8 1.0 1.0 1.0 0.9 1.1 2.1 1.0 1.1 1.6 1.4 1.1 1.2 1.0 1.6 1.2 1.2 1.1 1.3 4.4 2.1 1.2 0.9 1.1 1.2 1.4 1.4 1.2 1.3 1.3 1.7 1.4 1.1 1.2 1.4 1.2 1.2 1.3 1.5 1.1 1.1 1.3 1.5 1.2 1.2 1.3 1.5 1.2 1.1 1.1 1.0 1.0 1.1 1.1 1.0 1.5 1.1 1.2 1.2 1.3 1.2 1.1 1.2
[task 2019-10-02T23:22:25.911Z] 23:22:25     INFO -  PID 2336 | simple-open-DPI1.half.TART: 1.2
[task 2019-10-02T23:22:25.911Z] 23:22:25     INFO -  PID 2336 | simple-open-DPI1.all.TART: 1.7
[task 2019-10-02T23:22:25.911Z] 23:22:25     INFO -  PID 2336 | simple-open-DPI1.error.TART: 20.3
[task 2019-10-02T23:22:25.911Z] 23:22:25     INFO -  PID 2336 | simple-close-DPI1.raw.TART: 9.1 1.0 8.1 1.1 0.7 0.6 0.4 0.5 0.4 0.4 0.4 0.3 0.4 0.3 0.3 0.3 0.3 0.4 0.3 0.3 0.3 0.3 0.3 0.4 0.3 0.3 0.3 0.3 0.4 0.4 0.3 0.4 0.3 0.5 0.3 0.8 0.3 0.4 0.3 0.3 0.3 0.5 0.7 0.4 0.3 0.5 0.4 0.4 0.3 0.4 0.3 0.5 0.3 0.4 0.3 0.5 0.3 0.4 0.3 0.4 0.3 0.5 0.3 0.4 0.3 0.4 0.5 0.4 0.4 0.6 0.4 0.4 0.3 0.4 0.3 0.4 0.4 0.3 0.3 0.5 0.7 0.4 0.3 0.4 0.3 0.3 0.4 0.3 0.4 0.3 0.4 0.3 0.4 0.3 0.4 0.4 0.4 0.4 0.4 0.2 0.3 0.4 0.3 0.4 0.4 0.4 0.4 0.4 0.3 0.4 0.5 0.7 0.4 0.5 0.4 0.4 0.3 0.5 0.4 0.4 0.6 0.3 0.4 0.5 0.4 0.4 0.3 0.4 0.4 0.3 0.4 0.4 0.4 0.4 0.3 0.4 0.3 0.4 0.4 0.4 0.3 0.4 0.3 0.4 0.3 0.5 0.3 0.4 0.3 0.4 0.4 0.4 0.4 0.4 0.3 0.4 0.3 0.4 0.3 0.8 0.3 0.4 0.4 0.4 0.4 0.5 0.3 0.5 0.3 0.5 0.3 0.4 0.4 0.5 0.3 0.4 0.4 0.5 0.3 0.4 0.3 0.4 0.3 0.4 0.4 0.5 0.3 0.4 0.4 0.4 0.3 0.4 0.3 0.3 0.4 0.4 0.3 0.4 0.7 0.5 0.3 0.5 0.3 0.4 0.3 0.5 0.4 0.4 0.3 0.4 0.3 0.4 0.3 0.4 0.4 0.3 0.3 0.4 0.3 0.4 0.3 0.4 0.3 0.4 0.4 0.4 0.3 0.4 0.4 0.4 0.4 0.4 0.3 0.4 0.4 0.4 0.4 0.4 0.6 0.3 0.3 0.4
[task 2019-10-02T23:22:25.911Z] 23:22:25     INFO -  PID 2336 | simple-close-DPI1.half.TART: 0.4
[task 2019-10-02T23:22:25.911Z] 23:22:25     INFO -  PID 2336 | simple-close-DPI1.all.TART: 0.5
[task 2019-10-02T23:22:25.912Z] 23:22:25     INFO -  PID 2336 | simple-close-DPI1.error.TART: 10.1
[task 2019-10-02T23:22:25.912Z] 23:22:25     INFO -  PID 2336 | icon-open-DPI1.raw.TART: 17.1 3.1 3.5 9.4 2.5 16.0 3.3 3.9 3.8 1.9 1.2 1.5 1.6 1.2 1.3 1.3 1.5 1.5 1.3 1.4 1.5 1.2 1.4 1.1 1.1 1.0 1.1 1.3 1.1 1.0 1.0 1.0 1.0 1.1 1.0 1.0 1.1 1.2 1.2 1.3 1.3 1.9 1.5 1.4 1.2 1.3 1.5 1.3 1.2 1.4 1.3 1.3 1.4 1.2
[task 2019-10-02T23:22:25.912Z] 23:22:25     INFO -  PID 2336 | icon-open-DPI1.half.TART: 1.3
[task 2019-10-02T23:22:25.912Z] 23:22:25     INFO -  PID 2336 | icon-open-DPI1.all.TART: 2.2
[task 2019-10-02T23:22:25.912Z] 23:22:25     INFO -  PID 2336 | icon-open-DPI1.error.TART: 20.6
[task 2019-10-02T23:22:25.912Z] 23:22:25     INFO -  PID 2336 | icon-close-DPI1.raw.TART: 8.6 1.1 9.1 1.0 1.0 0.9 1.2 0.4 0.5 0.4 0.3 0.7 0.4 0.3 0.5 0.3 0.3 0.4 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.2 0.2 0.2 0.2 0.3 0.3 0.2 0.3 0.2 0.2 0.3 0.3 0.2 0.3 0.2 0.2 0.3 0.3 0.4 0.3 0.3 0.4 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.6 0.3 0.5 0.3 0.3 0.4 0.3 0.3 0.3 0.4 0.5 0.4 0.4 0.4 0.3 0.3 0.3 0.3 0.4 0.3 0.4 0.2 0.3 0.3 0.4 0.4 0.4 0.3 0.6 0.4 0.4 0.5 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.2 0.5 0.4 0.3 0.2 0.2 0.2 0.2 0.3 0.3 0.2 0.3 0.2 0.3 0.2 0.3 0.3 0.3 0.2 0.4 0.3 0.3 0.3 0.2 0.2 0.3 0.2 0.3 0.3 0.2 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.4 0.3 0.3 0.3 0.4 0.2 0.4 0.3 0.4 0.4 0.4 0.4 0.4 0.8 0.4 0.5 0.4 0.5 0.3 0.5 0.4 0.4 0.3 0.4 0.3 0.3 0.3 0.3 0.4 0.3 0.3 0.3 0.4 0.3 0.2 0.3 0.3 0.2 0.4 0.3 0.5 0.3 0.4 0.3 0.3 0.4 0.3 0.5 0.3 0.4 0.4 0.3 0.3 0.3 0.3 0.6 0.3 0.4 0.3 0.5 0.4 0.3 0.4 0.3 0.4 0.3 0.3 0.4 0.3 0.3 0.4 0.2 0.4 0.3 0.2 0.3 0.3 0.3 0.3 0.2 0.3 0.3 0.3 0.3 0.2 0.3 0.3 0.4 0.3 0.3 0.3 0.3 0.3 0.3 0.4 0.3 0.3 0.3 0.3 0.3 0.4 0.6 0.4 0.3 0.4 0.4 0.3 0.3 0.4 0.3 0.4 0.3 0.3 0.4 0.3 0.4 0.6 0.4 0.5 0.4 0.5 0.3 0.4 0.2 0.3 0.3 0.3 0.2 0.4
[task 2019-10-02T23:22:25.912Z] 23:22:25     INFO -  PID 2336 | icon-close-DPI1.half.TART: 0.3
[task 2019-10-02T23:22:25.912Z] 23:22:25     INFO -  PID 2336 | icon-close-DPI1.all.TART: 0.4
[task 2019-10-02T23:22:25.913Z] 23:22:25     INFO -  PID 2336 | icon-close-DPI1.error.TART: 10.2
[task 2019-10-02T23:22:25.913Z] 23:22:25     INFO -  PID 2336 | icon-open-DPI2.raw.TART: 16.3 3.6 3.1 7.8 2.3 13.4 5.7 2.7 1.9 1.7 1.4 1.3 1.8 1.2 1.3 1.3 1.4 1.2 1.2 1.4 1.4 1.4 1.2 1.7 1.0 1.3 1.4 1.3 1.3 1.3 1.5 1.2 1.2 1.3 1.3 1.7 1.4 1.3 1.4 1.2 1.2 1.3 1.5 1.7 1.4
[task 2019-10-02T23:22:25.913Z] 23:22:25     INFO -  PID 2336 | icon-open-DPI2.half.TART: 1.4
[task 2019-10-02T23:22:25.913Z] 23:22:25     INFO -  PID 2336 | icon-open-DPI2.all.TART: 2.3
[task 2019-10-02T23:22:25.913Z] 23:22:25     INFO -  PID 2336 | icon-open-DPI2.error.TART: 19.7
[task 2019-10-02T23:22:25.913Z] 23:22:25     INFO -  PID 2336 | icon-close-DPI2.raw.TART: 9.6 9.7 1.0 0.5 0.8 0.4 0.5 0.3 0.4 0.4 0.4 0.3 0.4 0.4 0.5 0.3 0.3 0.5 0.3 0.4 0.4 0.3 0.3 0.4 0.4 0.3 0.4 0.4 0.7 0.3 0.4 0.3 0.3 0.4 0.4 0.4 0.3 0.3 0.3 0.3 0.5 0.3 0.4 0.5 0.5 0.5 0.4 0.4 0.7 0.7 0.3 0.5 0.4 0.4 0.3 0.4 0.4 0.3 0.4 0.4 0.4 0.5 0.4 0.5 0.3 0.7 0.3 0.3 0.4 0.3 0.3 0.4 0.4 0.6 0.5 0.6 0.5 0.3 0.4 0.3 0.4 0.4 0.6 0.5 0.5 0.3 0.4 0.5 0.3 0.4 0.5 0.5 0.3 0.5 0.3 0.4 0.4 0.7 0.5 0.5 0.6 0.4 0.4 0.3 0.5 0.5 0.4 0.7 0.3 0.5 0.4 0.4 0.4 0.3 0.4 0.4 0.5 0.5 0.6 0.4 0.4 0.3 0.4 0.3 0.3 0.3 0.4 0.4 0.3 0.3 0.3 0.3 0.3 0.3 0.4 0.4 0.4 0.4 0.8 0.3 0.5 0.2 0.4 0.3 0.3 0.5 0.5 0.3 0.4 0.3 0.4 0.3 0.4 0.3 0.4 0.3 0.3 0.4 0.4 0.5 0.3 0.4 0.3 0.4 0.4 0.5 0.4 0.5 0.3 0.5 0.4 0.5 0.4 0.4 0.4 0.4 0.4 0.6 0.4 0.3 0.3 0.5 0.5 0.5 0.3 0.5 0.3 0.5 0.4 0.7 0.3 0.5 0.3 0.6 0.3 0.5 0.3 0.5 0.4 0.6 0.6 0.6 0.4 0.5 0.3 0.4 0.3 0.5 0.4 0.5 0.3 0.7 0.4 0.5 0.7 0.4 0.4 0.5 0.3 0.4 0.3 0.3 0.2
[task 2019-10-02T23:22:25.913Z] 23:22:25     INFO -  PID 2336 | icon-close-DPI2.half.TART: 0.4
[task 2019-10-02T23:22:25.914Z] 23:22:25     INFO -  PID 2336 | icon-close-DPI2.all.TART: 0.5
[task 2019-10-02T23:22:25.914Z] 23:22:25     INFO -  PID 2336 | icon-close-DPI2.error.TART: 10.8
[task 2019-10-02T23:22:25.914Z] 23:22:25     INFO -  PID 2336 | iconFade-close-DPI2.raw.TART: 1.8 3.1 0.6 0.7 0.5 0.8 0.7 0.7 0.7 0.6 0.7 0.8 0.7 0.9 0.7 0.8 0.7 0.7 0.9 0.6 0.9 0.5 0.5 0.5 0.5 0.5 0.6 0.5 0.6 0.5 0.5 0.6 0.5 0.5 0.5 0.5 0.6 0.5 0.5 0.6 0.7 0.6 0.6 0.7 0.7 0.6 1.1 0.6 0.6 0.7 0.7 0.7 0.6 0.6 0.7 0.6 0.7 0.8 0.7 0.7 0.7 0.7 0.6 0.6 0.7 0.6 0.6 0.7 0.8 0.9 0.5 0.6 0.7 0.6 0.7 0.6 0.7 0.6 0.6 0.6 0.6 0.5 0.7 0.7 0.5 0.5 0.7 0.7 0.6 0.6 0.6 0.6 0.6 0.8 0.6 0.6 0.6 0.5 0.6 0.6 0.6 0.6 0.6 0.6 0.5 0.6 0.6 0.6 0.6 0.5 0.6 0.7 0.6 0.5 0.5 0.6 0.6 0.5 0.9 0.5 0.6 0.6 0.6 0.6 0.5 0.8 0.6 0.5 0.6 0.7 0.5 0.5 0.5 0.5 0.6 0.6 0.6 0.5 0.6 0.6 0.7 0.5 0.6 0.8 0.7 0.6 0.6 0.6 0.6 0.5 0.6 0.6 0.6 0.6 0.5 0.6 0.5 0.6
[task 2019-10-02T23:22:25.914Z] 23:22:25     INFO -  PID 2336 | iconFade-close-DPI2.half.TART: 0.6
[task 2019-10-02T23:22:25.914Z] 23:22:25     INFO -  PID 2336 | iconFade-close-DPI2.all.TART: 0.6
[task 2019-10-02T23:22:25.914Z] 23:22:25     INFO -  PID 2336 | iconFade-close-DPI2.error.TART: 2.1
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | iconFade-open-DPI2.raw.TART: 2.5 0.8 1.1 0.8 0.7 0.8 0.8 1.0 0.8 0.9 0.5 0.6 0.6 0.6 0.6 0.6 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.7 1.0 0.7 0.6 0.7 0.7 0.7 0.8 0.7 0.7 0.7 0.7 1.0 0.8 0.8 0.8 0.8 0.9 0.8 1.1 0.8 0.9 0.8 0.9 0.7 0.8 0.8 0.8 0.8 0.8 0.9 0.9 0.9 0.8 0.8 0.9 0.9 1.2 0.8 0.8 0.9 0.9 0.9 0.9 1.1 1.0 1.0 1.0 0.9 1.0 1.0 0.8 1.0 1.2 0.8 0.9 0.9 0.9 0.8 0.9 0.8 0.9 1.0 0.8 1.1 0.9 0.9 0.9 0.9 0.8 1.3 0.9 0.9 0.8 0.8 0.9 0.9 0.8
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | iconFade-open-DPI2.half.TART: 0.9
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | iconFade-open-DPI2.all.TART: 0.8
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | iconFade-open-DPI2.error.TART: 1.8
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | newtab-open-preload-no.raw.TART: 18.0 2.0 4.1 2.9 2.9 1.8 1.3 1.4 1.3 7.4 1.7 4.2 1.6 2.8 1.6 1.5 1.6 1.6 1.6 1.4 1.5 1.5 1.2 1.3 1.4 1.4 1.2 1.8 1.4 1.3 1.3 1.4 1.3 1.2 1.4 1.2 1.3 2.1 1.4 1.0 1.4 1.2 1.6 1.6 1.5 1.4 1.2 1.3 1.7 1.2 1.3 1.4 1.4 1.3 1.3 1.2 1.4 1.6 1.3 1.7 1.6
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | newtab-open-preload-no.half.TART: 1.4
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | newtab-open-preload-no.all.TART: 2.0
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | newtab-open-preload-no.error.TART: 20.6
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | newtab-open-preload-yes.raw.TART: 16.1 3.2 4.1 1.1 0.8 0.6 0.7 0.9 1.0 1.2 0.8 0.8 0.7 1.1 0.9 0.9 2.0 0.6 1.3 1.1 1.0 0.9 1.0 2.5 1.2 1.5 1.7 1.6 1.6 1.4 1.4 1.2 1.3 1.3 1.3 1.3 1.3 1.3 1.5 1.4 1.7 1.3 1.8 1.4 1.4 1.4 1.5 1.2 1.5 1.6 1.8 1.3 1.3 1.5 1.4 1.4 1.5 1.3 1.2 1.4 1.5 1.3 1.3 1.4 1.4 1.3 1.4 1.4 1.3 1.4 2.0 2.7 1.2 1.1 1.6
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | newtab-open-preload-yes.half.TART: 1.5
[task 2019-10-02T23:22:25.915Z] 23:22:25     INFO -  PID 2336 | newtab-open-preload-yes.all.TART: 1.6
[task 2019-10-02T23:22:25.916Z] 23:22:25     INFO -  PID 2336 | newtab-open-preload-yes.error.TART: 21.4

Patch

[task 2019-10-10T07:01:31.009Z] 07:01:31     INFO -  PID 5572 | simple-open-DPI1.raw.TART: 17.8 1.9 9.5 3.6 1.1 1.2 1.6 1.1 1.2 1.2 1.4 1.5 1.6 2.2 1.0 1.2 1.3 1.3 1.2 1.2 1.3 1.3 1.4 1.4 1.1 1.2 1.4 1.3 1.8 1.4 1.2 1.3 1.3 1.2 1.1 1.6 1.0 1.3 1.3 1.3 1.4 1.7 1.2 1.4 1.3 1.4 1.4 1.6 1.4 1.4 1.3 1.6 1.3 3.4 2.1 1.6 1.0 1.3 1.3 2.0 1.5 1.6 1.5 1.5 1.3 1.8
[task 2019-10-10T07:01:31.009Z] 07:01:31     INFO -  PID 5572 | simple-open-DPI1.half.TART: 1.5
[task 2019-10-10T07:01:31.010Z] 07:01:31     INFO -  PID 5572 | simple-open-DPI1.all.TART: 1.8
[task 2019-10-10T07:01:31.010Z] 07:01:31     INFO -  PID 5572 | simple-open-DPI1.error.TART: 20.4
[task 2019-10-10T07:01:31.010Z] 07:01:31     INFO -  PID 5572 | simple-close-DPI1.raw.TART: 9.3 1.4 7.4 0.9 0.8 0.4 0.4 0.7 0.4 0.3 0.3 0.3 1.2 0.5 0.3 0.3 0.3 0.3 0.2 0.2 0.3 0.3 0.3 0.3 0.2 0.3 0.3 0.3 0.3 0.3 0.3 0.4 0.3 0.4 0.3 0.3 0.3 0.4 0.3 0.5 0.3 0.4 0.3 0.3 0.3 0.3 0.3 0.4 0.3 0.3 0.3 0.3 0.4 0.3 0.4 0.4 0.3 0.3 0.7 0.5 0.4 0.8 0.3 0.3 0.4 0.4 0.3 0.4 0.2 0.3 0.4 0.3 0.3 0.3 0.3 0.4 0.3 0.4 0.6 0.4 0.4 0.4 0.5 0.3 0.4 0.3 0.4 0.4 0.4 0.4 0.4 0.5 0.4 0.4 0.4 0.7 0.8 0.6 0.5 0.4 0.4 0.4 0.7 0.5 0.4 0.5 0.4 0.5 0.3 0.3 0.5 0.4 0.4 0.3 0.3 0.3 0.3 0.4 0.3 0.5 0.3 0.3 0.4 0.4 0.4 0.3 0.2 0.5 0.3 0.4 0.3 0.3 0.6 0.3 0.4 0.4 0.4 0.3 0.3 0.3 0.3 0.3 0.3 0.3 0.6 0.2 0.4 0.3 0.4 0.4 0.2 0.5 0.3 0.4 0.3 0.4 0.3 0.3 0.5 0.3 0.4 0.4 0.4 0.4 0.3 0.4 0.3 0.3 0.3 0.3 0.3 0.3 0.4 0.6 0.4 0.3 0.3 0.5 0.3 0.4 0.3 0.4 0.3 0.3 0.3 0.3 0.4 0.3 0.3 0.3 0.5 0.4 0.3 0.4 0.4 0.3 0.4 0.5 0.4 0.5 0.3 0.4 0.4 0.3 0.4 0.3 0.5 0.3 0.4 0.5 0.4 0.7 0.3 0.5 0.4 0.4 0.4 0.4 0.4 0.4 0.4 0.5 0.4 0.3 0.4 0.3 0.4 0.4 0.3 0.4 0.4 0.4 0.4 0.3 0.5 0.8 0.4 0.4 0.4 0.6 0.4 0.5
[task 2019-10-10T07:01:31.010Z] 07:01:31     INFO -  PID 5572 | simple-close-DPI1.half.TART: 0.4
[task 2019-10-10T07:01:31.011Z] 07:01:31     INFO -  PID 5572 | simple-close-DPI1.all.TART: 0.5
[task 2019-10-10T07:01:31.011Z] 07:01:31     INFO -  PID 5572 | simple-close-DPI1.error.TART: 10.2
[task 2019-10-10T07:01:31.011Z] 07:01:31     INFO -  PID 5572 | icon-open-DPI1.raw.TART: 17.1 3.9 3.4 8.1 3.0 11.0 6.6 3.0 2.0 1.5 1.3 1.1 1.3 1.5 1.4 1.4 1.3 1.4 1.8 1.7 1.4 1.0 1.5 1.2 1.6 1.6 1.4 1.9 1.4 1.3 1.4 1.5 1.5 2.0 1.7 1.3 1.2 1.2 1.5 1.4 1.3 1.3 1.7 1.4 2.0 1.7 1.6 1.8 1.5 1.3 2.1
[task 2019-10-10T07:01:31.012Z] 07:01:31     INFO -  PID 5572 | icon-open-DPI1.half.TART: 1.5
[task 2019-10-10T07:01:31.012Z] 07:01:31     INFO -  PID 5572 | icon-open-DPI1.all.TART: 2.4
[task 2019-10-10T07:01:31.012Z] 07:01:31     INFO -  PID 5572 | icon-open-DPI1.error.TART: 20.8
[task 2019-10-10T07:01:31.013Z] 07:01:31     INFO -  PID 5572 | icon-close-DPI1.raw.TART: 7.8 1.1 9.0 0.7 0.6 0.8 0.4 0.6 0.4 0.7 0.6 0.4 0.4 0.3 0.5 0.8 0.6 0.4 0.4 0.3 0.5 0.4 0.4 0.4 0.6 0.3 0.3 0.2 0.4 0.4 0.3 0.3 0.2 0.3 0.3 0.3 0.3 0.3 0.3 0.4 0.3 0.3 0.3 0.3 0.4 0.4 0.3 0.3 0.3 0.2 0.3 0.4 0.6 0.4 0.5 0.4 0.4 0.5 0.4 0.5 1.0 0.5 0.7 0.4 0.8 0.5 0.9 0.3 0.4 0.3 0.3 0.4 0.4 0.4 0.3 0.3 0.4 0.4 0.4 0.3 0.3 0.5 0.3 0.4 0.3 0.3 0.5 0.4 0.4 0.3 0.3 0.4 0.3 0.5 0.3 0.4 0.4 0.3 0.4 0.7 0.4 0.3 0.7 0.2 0.4 0.3 0.4 0.4 0.3 0.3 0.4 0.4 0.4 0.2 0.4 0.3 0.4 0.5 0.6 0.5 0.5 0.4 0.5 0.4 0.4 0.4 0.6 0.6 0.7 0.5 0.4 0.4 0.5 0.4 0.5 0.4 0.8 0.4 0.6 0.4 0.4 0.4 0.5 0.3 0.4 0.3 0.3 0.3 0.5 0.4 0.4 0.4 0.4 0.3 0.4 0.5 0.4 0.5 0.3 0.3 0.5 0.3 0.5 0.4 0.5 0.3 0.4 0.4 0.5 0.3 0.5 0.4 0.8 0.3 0.5 0.4 0.4 0.3 0.6 0.5 0.7 0.5 0.6 0.3 0.4 0.3 0.3 0.3 0.5 0.3 0.3 0.5 0.4 0.4 0.5 0.7 0.5 0.5 0.4 0.5 0.3 0.4 0.3 0.5 0.4 0.4 0.4 0.6 0.4 0.4 0.5 0.3 0.5 0.3 0.4 0.4 0.6 0.4 0.5 0.3 0.3 0.3 0.3 0.2
[task 2019-10-10T07:01:31.013Z] 07:01:31     INFO -  PID 5572 | icon-close-DPI1.half.TART: 0.4
[task 2019-10-10T07:01:31.013Z] 07:01:31     INFO -  PID 5572 | icon-close-DPI1.all.TART: 0.5
[task 2019-10-10T07:01:31.013Z] 07:01:31     INFO -  PID 5572 | icon-close-DPI1.error.TART: 10.0
[task 2019-10-10T07:01:31.013Z] 07:01:31     INFO -  PID 5572 | icon-open-DPI2.raw.TART: 16.4 4.7 3.7 8.4 2.8 14.6 5.0 1.0 3.3 2.1 1.4 1.8 1.6 1.6 2.0 1.7 1.7 1.6 1.5 1.7 1.5 1.6 1.7 1.8 1.6 1.5 1.4 1.9 1.6 1.7 1.7 1.8 1.9 1.5 1.6 1.5 1.7
[task 2019-10-10T07:01:31.013Z] 07:01:31     INFO -  PID 5572 | icon-open-DPI2.half.TART: 1.7
[task 2019-10-10T07:01:31.013Z] 07:01:31     INFO -  PID 5572 | icon-open-DPI2.all.TART: 2.9
[task 2019-10-10T07:01:31.013Z] 07:01:31     INFO -  PID 5572 | icon-open-DPI2.error.TART: 20.6
[task 2019-10-10T07:01:31.014Z] 07:01:31     INFO -  PID 5572 | icon-close-DPI2.raw.TART: 10.7 8.7 0.9 0.5 1.0 0.5 0.5 0.9 0.5 0.4 0.5 0.4 0.3 0.4 0.4 0.4 0.3 0.4 0.4 0.4 0.3 0.5 0.4 0.3 0.3 0.4 0.4 0.5 0.8 0.6 0.5 0.7 0.3 0.5 0.4 0.5 0.4 0.5 0.4 0.5 0.4 0.4 0.6 0.5 0.5 0.4 0.5 0.4 0.3 0.5 0.4 0.5 0.3 0.4 0.3 0.5 0.4 0.5 0.4 0.5 0.5 0.5 0.4 0.5 0.6 0.3 0.5 0.5 0.5 0.4 0.4 0.5 0.5 0.4 0.5 0.4 0.4 0.5 0.4 0.3 0.5 1.1 0.4 0.4 0.5 0.6 0.3 0.5 0.4 0.5 0.4 0.4 0.4 0.5 0.5 0.5 0.7 0.5 0.4 0.5 0.4 0.4 0.5 0.5 0.4 0.6 0.5 0.5 0.5 0.5 0.4 0.5 0.5 0.5 0.4 0.6 0.8 0.6 0.4 0.5 0.4 0.5 0.4 0.7 0.7 0.5 0.3 0.5 0.4 0.5 0.4 0.6 0.4 0.6 0.4 0.5 0.4 0.5 0.4 0.6 0.4 0.4 0.5 0.5 0.5 0.6 0.4 0.5 0.8 0.7 0.5 0.6 0.5 1.0 0.4 0.6 0.5 0.7 0.4 0.7 0.6 0.6 0.4 0.4 0.5 0.6 0.4 0.5 0.4 0.4 0.4 0.5 0.3 0.5 0.4 0.5 0.3 0.5 0.4 0.4 0.5 0.4 0.5 0.4 0.4 0.8 0.3 0.4 0.4 0.5 0.4 0.3 0.4 0.4 0.3 0.4
[task 2019-10-10T07:01:31.014Z] 07:01:31     INFO -  PID 5572 | icon-close-DPI2.half.TART: 0.5
[task 2019-10-10T07:01:31.014Z] 07:01:31     INFO -  PID 5572 | icon-close-DPI2.all.TART: 0.6
[task 2019-10-10T07:01:31.014Z] 07:01:31     INFO -  PID 5572 | icon-close-DPI2.error.TART: 11.9
[task 2019-10-10T07:01:31.014Z] 07:01:31     INFO -  PID 5572 | iconFade-close-DPI2.raw.TART: 2.0 3.4 0.7 0.8 0.8 0.8 1.0 0.8 0.9 0.8 0.8 0.8 0.9 0.9 0.8 0.8 0.8 1.2 0.8 0.9 0.8 0.9 0.8 1.0 0.7 0.7 0.8 0.8 1.1 0.8 0.8 0.7 0.7 0.7 0.7 1.0 0.7 0.8 0.7 0.8 0.8 0.8 0.8 0.7 0.6 0.6 0.6 0.6 0.7 0.8 0.6 0.6 0.6 0.6 0.6 0.6 0.9 0.6 0.7 0.6 0.6 0.6 0.6 0.7 0.6 0.6 0.7 0.7 0.7 0.7 0.7 0.8 0.7 0.8 0.7 0.8 0.7 0.7 1.0 0.6 0.7 0.7 0.7 0.7 0.6 0.7 0.6 0.8 0.6 0.7 0.8 0.6 0.7 0.6 0.7 0.8 0.7 0.8 0.7 1.0 0.8 0.6 0.7 0.7 0.7 0.7 0.7 0.7 0.6 0.7 0.6 0.8 0.7 0.7 0.6 0.7 0.7 0.6 0.6 0.7 0.7 1.0 0.7 0.8 0.6 0.7 0.7 0.7 0.8 0.6 0.7 0.6 0.7 0.8
[task 2019-10-10T07:01:31.014Z] 07:01:31     INFO -  PID 5572 | iconFade-close-DPI2.half.TART: 0.7
[task 2019-10-10T07:01:31.014Z] 07:01:31     INFO -  PID 5572 | iconFade-close-DPI2.all.TART: 0.8
[task 2019-10-10T07:01:31.014Z] 07:01:31     INFO -  PID 5572 | iconFade-close-DPI2.error.TART: 2.5
[task 2019-10-10T07:01:31.014Z] 07:01:31     INFO -  PID 5572 | iconFade-open-DPI2.raw.TART: 2.2 1.0 1.0 0.9 1.1 1.2 0.9 1.0 1.0 0.9 0.9 1.1 0.9 0.9 0.7 1.1 0.8 0.7 0.7 3.2 0.8 1.4 1.2 1.0 1.1 1.6 0.9 1.6 1.0 1.4 1.2 1.0 1.0 1.4 1.3 1.0 1.0 0.9 0.9 0.9 0.9 1.3 1.1 1.0 1.0 1.0 1.0 1.0 0.9 1.1 1.0 1.2 1.0 0.9 1.3 1.0 1.0 0.9 1.0 1.0 1.0 1.2 1.0 1.0 1.0 1.1 1.0 1.2 1.0 1.3 1.1 1.0 1.1 1.1 1.0 1.1 1.3 1.0 1.0 1.0
[task 2019-10-10T07:01:31.014Z] 07:01:31     INFO -  PID 5572 | iconFade-open-DPI2.half.TART: 1.1
[task 2019-10-10T07:01:31.015Z] 07:01:31     INFO -  PID 5572 | iconFade-open-DPI2.all.TART: 1.1
[task 2019-10-10T07:01:31.015Z] 07:01:31     INFO -  PID 5572 | iconFade-open-DPI2.error.TART: 2.1
[task 2019-10-10T07:01:31.015Z] 07:01:31     INFO -  PID 5572 | newtab-open-preload-no.raw.TART: 19.0 2.3 4.9 3.3 2.2 1.3 5.3 3.6 1.3 1.5 2.1 3.8 1.5 1.9 1.6 1.8 2.7 1.8 1.9 1.5 1.5 1.8 1.4 1.6 1.6 1.5 1.6 1.2 1.4 1.4 1.5 1.7 1.6 1.5 1.4 1.6 1.5 1.5 1.6 1.4 1.7 1.6 1.8 1.5 1.5 1.4 1.6 1.5 1.4 1.6 1.8 1.3 1.6 1.6 1.7 1.4
[task 2019-10-10T07:01:31.015Z] 07:01:31     INFO -  PID 5572 | newtab-open-preload-no.half.TART: 1.5
[task 2019-10-10T07:01:31.015Z] 07:01:31     INFO -  PID 5572 | newtab-open-preload-no.all.TART: 2.2
[task 2019-10-10T07:01:31.015Z] 07:01:31     INFO -  PID 5572 | newtab-open-preload-no.error.TART: 22.2
[task 2019-10-10T07:01:31.015Z] 07:01:31     INFO -  PID 5572 | newtab-open-preload-yes.raw.TART: 14.9 2.3 3.2 1.4 0.9 0.7 0.9 1.6 1.2 0.9 1.3 0.9 1.0 0.8 0.9 0.9 2.0 0.8 1.9 1.6 1.3 2.3 1.7 1.5 1.9 2.2 1.4 1.5 1.8 1.5 1.5 1.4 1.6 2.0 1.7 1.8 1.4 1.7 1.4 1.6 1.4 1.4 1.4 1.4 1.5 1.6 1.3 1.9 1.3 1.4 2.0 1.6 1.4 1.7 1.4 1.6 1.6 1.5 1.7 1.6 1.5 1.4 1.5 1.5 1.5 2.0 1.9 1.6
[task 2019-10-10T07:01:31.015Z] 07:01:31     INFO -  PID 5572 | newtab-open-preload-yes.half.TART: 1.6
[task 2019-10-10T07:01:31.015Z] 07:01:31     INFO -  PID 5572 | newtab-open-preload-yes.all.TART: 1.7
[task 2019-10-10T07:01:31.015Z] 07:01:31     INFO -  PID 5572 | newtab-open-preload-yes.error.TART: 19.8

To explain the data here, each of the "X.raw" measurements shows the cost of each frame painted during an animation while in ASAP mode. The "X.Y" measurements, where "Y" is something other than "raw", are calculations based on the "raw" measurement - this doc kinda lays it out.

Looking at the "raw" measurements, it looks like there are always more painted frames during the "base" case.

This suggests that painting with the patch has somehow gotten more expensive, or otherwise caused us to paint less frequently when in ASAP mode.

See Also: → 1588142

XX Need to double check if this is still needed after restructure.

Depends on D34021

This is going to be challenging: intl.css is exposed to locales, but it's not available in localization tools. Which means I'll need to figure out how to update it across ~150 repositories, without breaking other changes (RTL locales are doing a lot in that file).

On top of that, we only have one version that ships across all Firefox versions: what happens if I apply the changes in D33558 and ship them in 71, when en-US will ship them in 72? What about other products relying on toolkit?

I wonder if it's time to get rid of this file, and centralize changes as needed. This file predates me, not sure if pike has more background on its history.

So, we should deprecate intl.css. In a way that kills it with fire.

We're going to do an audit on the l10n side to see what that takes, but really, anything in intl.css should be a bug and fixed in product.

Historical detour, May 2000, Tao with review by hyatt, https://github.com/mozilla/gecko-dev/commit/7405162cf6c158a372e2b7d096671402c52a871d.

For this particular rule, it seems that window { font } in intl.css is overwritten by :root {font} in global.css, at least for the top-level browser window. Is there any way that that's not the case? Dao?

If that rule is useless, I'm all for removing it.

Depends on D34021

Attachment #9101003 - Attachment is obsolete: true

I was able to remove the talos TART regressions by using a XUL like frame structure (root box frame and doc element box frame) with browser.xhtml. I think the slowdown with <html> is coming from the HTMLScrollFrame. I've got some more talos runs in progress to see if removing the HTMLScrollFrame for top level chrome documents will help.

See Also: → 1589801

(In reply to Axel Hecht [:Pike] from comment #65)

So, we should deprecate intl.css. In a way that kills it with fire.

We're going to do an audit on the l10n side to see what that takes, but really, anything in intl.css should be a bug and fixed in product.

Historical detour, May 2000, Tao with review by hyatt, https://github.com/mozilla/gecko-dev/commit/7405162cf6c158a372e2b7d096671402c52a871d.

For this particular rule, it seems that window { font } in intl.css is overwritten by :root {font} in global.css, at least for the top-level browser window. Is there any way that that's not the case? Dao?

NI for the last question.

Flags: needinfo?(dao+bmo)

Yeah, I think unexpected things would happen if the font rule from intl.css was actually used. It should always be overridden unless some locale uses !important.

Flags: needinfo?(dao+bmo)

The change to intl.css isn't needed anymore. There were specificity issues before when we had a *|*:root selector.

Blocks: 1590840

Aaron, any chance you could help us figure out what is going on here or point us to someone who could? The problem can be seen in https://bugzilla.mozilla.org/attachment.cgi?id=9070994 - the titlebar is white and we can't see window controls (minimize, maximize, close) when we switch from a <xul:window> to <html:html> in browser.xhtml, even though all the css rules seem to be applying correctly.

Those buttons are painted by the OS in the command bar area. We jump through whoops to avoid painting on top of them. From the screenshot, it looks like you might be painting over that area with white? In which case the buttons would be obscured. Layout is responsible for setting the proper glass areas so Windows can display glass. I'd check into that area of the code.

https://searchfox.org/mozilla-central/source/widget/windows/nsWindow.cpp#2932

Flags: needinfo?(jmathies)

Here's a good starting point: https://searchfox.org/mozilla-central/rev/088e2cf29c59d733d57af43903eb0267dbf72e2a/layout/generic/nsContainerFrame.cpp#599-603
It would also be good to capture a display list dump from the window using layout.display-list.dump-parent. And it would be good to check what PresShell::AddCanvasBackgroundColorItem does in XUL/HTML.

Depends on: 1590044

When using an HTML root these tests failed because the source drag element
is not visible.

Depends on D49469

When browser.xhtml switches to an <html> root element, the frame structure
changed and caused performance regressions on talos for tart and tresize.
browser.xhtml doesn't need scrolling, so we can disable it and keep performance
on par with XUL <window>.

Depends on D50674

When using an HTML root these tests failed because the source drag element
is not visible.

Depends on D49469

When browser.xhtml switches to an <html> root element, the frame structure
changed and caused performance regressions on talos for tart and tresize.
browser.xhtml doesn't need scrolling, so we can disable it and keep performance
on par with XUL <window>.

Depends on D50872

Attachment #9104782 - Attachment is obsolete: true
Attachment #9104783 - Attachment is obsolete: true
Blocks: 1592334
Attachment #9104782 - Attachment is obsolete: false
Attachment #9104783 - Attachment is obsolete: false
Attachment #9104782 - Attachment is obsolete: true
Attachment #9104783 - Attachment is obsolete: true

The devtools highlighter is broken with browser.xhtml when scroll frames
are disabled.

Depends on D50675

Blocks: 1594587
Pushed by bdahl@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e0e56a195659
Use html root element in browser.xhtml and update styling to support html roots r=Gijs
https://hg.mozilla.org/integration/autoland/rev/f05dfbeff17b
Use document.title instead of writing the title attribute on the document element r=dao
https://hg.mozilla.org/integration/autoland/rev/d4be1aa8cdb6
Support the <body> element being the default focus node in browser.xhtml r=Gijs
https://hg.mozilla.org/integration/autoland/rev/5efddfd196b5
Fix test_queryCaretRect.html. r=dao
https://hg.mozilla.org/integration/autoland/rev/836724d3860e
Fix browser drag tests when using HTML root element. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/bbf62ef50e52
Don't create scroll frames for windows that don't need them. r=emilio
https://hg.mozilla.org/integration/autoland/rev/1484255e5f4d
Use XUL inspector highlighter for HTML docs without scroll frames. r=bgrins

The <html> element does not have screenX and screenY like XULElement.
Instead use window location and element offset to calculate it.

Depends on D52104

Pushed by bdahl@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fa9ff3a262bc
Use html root element in browser.xhtml and update styling to support html roots r=Gijs
https://hg.mozilla.org/integration/autoland/rev/47030db7c541
Use document.title instead of writing the title attribute on the document element r=dao
https://hg.mozilla.org/integration/autoland/rev/fb6625e16994
Support the <body> element being the default focus node in browser.xhtml r=Gijs
https://hg.mozilla.org/integration/autoland/rev/cd43140ba528
Fix test_queryCaretRect.html. r=dao
https://hg.mozilla.org/integration/autoland/rev/e4d31ac43ad0
Fix browser drag tests when using HTML root element. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/d9fa29c55c42
Don't create scroll frames for windows that don't need them. r=emilio
https://hg.mozilla.org/integration/autoland/rev/c2b41600ce78
Use XUL inspector highlighter for HTML docs without scroll frames. r=bgrins
https://hg.mozilla.org/integration/autoland/rev/9644ee96a51a
Fix screenshot tests for htmlified browser.xhtml. r=bgrins
Regressions: 1595393
Blocks: 1576946
Assignee: bgrinstead → bdahl
Flags: needinfo?(bgrinstead)
Type: enhancement → task
Depends on: 1596366
Blocks: 1596366
No longer depends on: 1596366
No longer blocks: 1596366
Depends on: 1596366
Regressions: 1596709
Regressions: 1596724
Regressions: 1596990
Regressions: 1597068
You need to log in before you can comment on or make changes to this bug.