browser.xhtml: Migrate root xul:window element to an html:html element
Categories
(Firefox :: General, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: bgrins, Assigned: bdahl)
References
(Blocks 2 open bugs, Regressed 1 open bug)
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 |
browser-toolbox-highlighter.png
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.
|
||
Updated•6 years ago
|
|
Reporter | |
Comment 1•6 years ago
|
||
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®exp=true&path=
|
|
Reporter | |
Comment 2•6 years ago
|
||
(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®exp=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.
|
|
Reporter | |
Comment 3•6 years ago
|
||
We also have some code that checks for a root XUL element for lwtheme attr changes: - https://searchfox.org/mozilla-central/rev/c56977420df7a1b692ce0f7e499ddb364d9fd7b2/layout/base/RestyleManager.cpp#3351 - https://searchfox.org/mozilla-central/rev/c56977420df7a1b692ce0f7e499ddb364d9fd7b2/dom/xul/nsXULElement.cpp#923 - https://searchfox.org/mozilla-central/rev/c56977420df7a1b692ce0f7e499ddb364d9fd7b2/dom/xul/nsXULElement.cpp#948 Actually, most of the stuff in nsXULElement::AfterSetAttr looks like it'd need to be ported to support a root HTML element.
|
||
Comment 4•6 years ago
|
||
(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®exp=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?
|
|
Reporter | |
Comment 5•6 years ago
|
||
(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®exp=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®exp=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.
|
|
||
Comment 6•6 years ago
|
||
(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
|
|
Reporter | |
Comment 7•6 years ago
|
||
(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).
|
|
||
Comment 8•6 years ago
|
||
(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?
|
|
Reporter | |
Comment 9•6 years ago
|
||
(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.
|
|
||
Comment 10•6 years ago
|
||
(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.
|
|
Reporter | |
Comment 11•6 years ago
|
||
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.
|
|
Reporter | |
Comment 12•6 years ago
|
||
|
|
Reporter | |
Comment 13•6 years ago
|
||
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.
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Updated•5 years ago
|
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 14•5 years ago
|
||
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®exp=false&path=).
|
|
Assignee | |
Comment 15•5 years ago
|
||
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.
|
|
Reporter | |
Comment 16•5 years ago
|
||
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).
|
||
Comment 17•5 years ago
|
||
You have no idea how happy this is making me right now!
|
|
Reporter | |
Comment 18•5 years ago
|
||
Depends on D33550
|
|
Reporter | |
Comment 19•5 years ago
|
||
Depends on D33558
|
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 20•5 years ago
|
||
- Selectors starting with
windowor:rootin browser: https://searchfox.org/mozilla-central/search?q=^(window|\%3Aroot)®exp=true&path=browser%2F**%2F*.css - Selectors starting with
windowor:rootin toolkit: https://searchfox.org/mozilla-central/search?q=%5E%28window%7C%5C%3Aroot%29®exp=true&path=toolkit%2F**%2F*.css
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.
|
|
Reporter | |
Comment 21•5 years ago
|
||
In preparation for an <html> root node in browser.xhtml, we need to react to lwtheme changes correctly.
|
|
||
Comment 22•5 years ago
|
||
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.
|
|
Reporter | |
Comment 23•5 years ago
|
||
For the issue where the context menu isn't working, here are a few observations:
- It starts working if (a) I force a reflow on the body element or (b) I make mainPopupSet hidden until DOMContentLoaded.
- It looks like we are hitting this early return https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/layout/base/nsCSSFrameConstructor.cpp#5431, but then after the reflow we re-run that and don't hit it.
- This makes me think that the popup elements are getting layout before the anonymous popupgroup node (created here: https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/layout/generic/nsCanvasFrame.cpp#155).
|
|
Reporter | |
Comment 24•5 years ago
|
||
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).
|
|
Reporter | |
Comment 25•5 years ago
|
||
|
|
Reporter | |
Comment 26•5 years ago
|
||
This is a difference between HTML and XUL elements. Just matching the test to expect
the HTML behavior.
Depends on D33561
|
|
Reporter | |
Comment 27•5 years ago
|
||
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
|
|
Reporter | |
Comment 28•5 years ago
|
||
This would be better solved with a layout fix
Depends on D34021
|
|
||
Comment 29•5 years ago
|
||
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.
|
|
Reporter | |
Comment 30•5 years ago
|
||
(In reply to Brian Grinstead [:bgrins] from comment #23)
For the issue where the context menu isn't working, here are a few observations:
- It starts working if (a) I force a reflow on the body element or (b) I make mainPopupSet hidden until DOMContentLoaded.
- It looks like we are hitting this early return https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/layout/base/nsCSSFrameConstructor.cpp#5431, but then after the reflow we re-run that and don't hit it.
- This makes me think that the popup elements are getting layout before the anonymous popupgroup node (created here: https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/layout/generic/nsCanvasFrame.cpp#155).
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.
|
|
Reporter | |
Comment 31•5 years ago
|
||
This is the alternate approach mentioned in Comment 30
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 32•5 years ago
|
||
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?
|
|
Reporter | |
Comment 33•5 years ago
|
||
(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.
|
|
Reporter | |
Comment 34•5 years ago
|
||
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.
|
|
Reporter | |
Comment 35•5 years ago
|
||
(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.
|
||
Comment 36•5 years ago
|
||
(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:
- It starts working if (a) I force a reflow on the body element or (b) I make mainPopupSet hidden until DOMContentLoaded.
- It looks like we are hitting this early return https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/layout/base/nsCSSFrameConstructor.cpp#5431, but then after the reflow we re-run that and don't hit it.
- This makes me think that the popup elements are getting layout before the anonymous popupgroup node (created here: https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/layout/generic/nsCanvasFrame.cpp#155).
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.
|
|
Reporter | |
Comment 37•5 years ago
|
||
(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:
- It starts working if (a) I force a reflow on the body element or (b) I make mainPopupSet hidden until DOMContentLoaded.
- It looks like we are hitting this early return https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/layout/base/nsCSSFrameConstructor.cpp#5431, but then after the reflow we re-run that and don't hit it.
- This makes me think that the popup elements are getting layout before the anonymous popupgroup node (created here: https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/layout/generic/nsCanvasFrame.cpp#155).
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.
|
|
Reporter | |
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
|
Reporter | |
Comment 38•5 years ago
|
||
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.
|
|
Reporter | |
Comment 39•5 years ago
|
||
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?
|
|
Reporter | |
Comment 40•5 years ago
|
||
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.
|
|
||
Comment 41•5 years ago
|
||
(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 137Could 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...
|
|
Reporter | |
Comment 42•5 years ago
•
|
||
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:
- Comment 32: Aero background and close buttons not showing up on Windows 7 (https://bugzilla.mozilla.org/attachment.cgi?id=9070994).
|
|
||
Comment 43•5 years ago
|
||
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:
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?
|
|
||
Comment 44•5 years ago
|
||
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.
|
|
Reporter | |
Comment 45•5 years ago
|
||
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).
|
|
Reporter | |
Comment 46•5 years ago
|
||
(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.
|
|
Reporter | |
Comment 47•5 years ago
|
||
(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..
|
|
||
Comment 48•5 years ago
|
||
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...
|
|
||
Updated•5 years ago
|
|
|
||
Comment 49•5 years ago
|
||
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.
|
|
Reporter | |
Comment 50•5 years ago
|
||
(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.
|
|
||
Comment 51•5 years ago
|
||
We should really figure out why that line is there, if we can...
|
|
Reporter | |
Comment 52•5 years ago
|
||
(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.
|
|
Reporter | |
Comment 53•5 years ago
|
||
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).
|
|
||
Comment 54•5 years ago
|
||
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.
|
|
||
Comment 55•5 years ago
|
||
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.
|
|
Reporter | |
Comment 56•5 years ago
|
||
(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
transitioningstate. 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 inxul.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.
|
|
Reporter | |
Comment 57•5 years ago
|
||
Rebased patches on phab, and have the latest try push at https://treeherder.mozilla.org/#/jobs?repo=try&revision=4a0d50402eca77fa832ace6810a0b7f78fa4c708.
|
|
Assignee | |
Comment 58•5 years ago
|
||
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.
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 59•5 years ago
|
||
(In reply to Brian Grinstead [:bgrins] from comment #32)
Created attachment 9070994 [details]
moz-win-borderless-glass.pngHi 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 bootstrapfailures :(. 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
|
||
Comment 60•5 years ago
|
||
Jim is back from PTO today. He should be redirecting this as necessary.
|
|
Reporter | |
Comment 61•5 years ago
|
||
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).
|
||
Comment 62•5 years ago
•
|
||
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.
|
|
Assignee | |
Comment 63•5 years ago
|
||
XX Need to double check if this is still needed after restructure.
Depends on D34021
|
||
Comment 64•5 years ago
|
||
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.
|
||
Comment 65•5 years ago
|
||
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.
|
|
Assignee | |
Comment 66•5 years ago
|
||
Depends on D34021
|
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 67•5 years ago
|
||
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.
|
|
||
Comment 68•5 years ago
|
||
(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 }inintl.cssis 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.
|
|
||
Comment 69•5 years ago
|
||
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.
|
|
Assignee | |
Comment 70•5 years ago
•
|
||
The change to intl.css isn't needed anymore. There were specificity issues before when we had a *|*:root selector.
|
|
||
Comment 71•5 years ago
|
||
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
|
||
Comment 72•5 years ago
|
||
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.
|
|
Assignee | |
Comment 73•5 years ago
|
||
When using an HTML root these tests failed because the source drag element
is not visible.
Depends on D49469
|
|
Assignee | |
Comment 74•5 years ago
|
||
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
|
|
Assignee | |
Comment 75•5 years ago
|
||
When using an HTML root these tests failed because the source drag element
is not visible.
Depends on D49469
|
|
Assignee | |
Comment 76•5 years ago
|
||
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
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 77•5 years ago
|
||
The devtools highlighter is broken with browser.xhtml when scroll frames
are disabled.
Depends on D50675
|
||
Comment 78•5 years ago
|
||
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
|
||
Comment 79•5 years ago
|
||
Backed out 7 changesets (Bug 1492582) for causing ss mochitest failures CLOSED TREE
Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=275152845&resultStatus=testfailed%2Cbusted%2Cexception&revision=1484255e5f4df32ea381c58669ed22545a70d4a7
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=275152845&repo=autoland&lineNumber=4653
Backout: https://hg.mozilla.org/integration/autoland/rev/1f8651278127b1431c8dbec4cac0eba4e2a0f046
|
|
Assignee | |
Comment 80•5 years ago
|
||
The <html> element does not have screenX and screenY like XULElement.
Instead use window location and element offset to calculate it.
Depends on D52104
|
|
||
Comment 81•5 years ago
|
||
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
|
||
Comment 82•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/fa9ff3a262bc
https://hg.mozilla.org/mozilla-central/rev/47030db7c541
https://hg.mozilla.org/mozilla-central/rev/fb6625e16994
https://hg.mozilla.org/mozilla-central/rev/cd43140ba528
https://hg.mozilla.org/mozilla-central/rev/e4d31ac43ad0
https://hg.mozilla.org/mozilla-central/rev/d9fa29c55c42
https://hg.mozilla.org/mozilla-central/rev/c2b41600ce78
https://hg.mozilla.org/mozilla-central/rev/9644ee96a51a
|
||
Updated•5 years ago
|
|
|
Reporter | |
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
Description
•