Closed Bug 1576946 Opened 4 months ago Closed Last month

Implement <stack> using CSS Grid and remove nsStackFrame

Categories

(Core :: Layout, task)

task
Not set

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox72 --- fixed

People

(Reporter: bgrins, Assigned: ntim)

References

(Blocks 6 open bugs, Regressed 4 open bugs)

Details

(Keywords: dev-doc-needed)

Attachments

(6 files)

This seems similar to nsDeckFrame (Bug 1559192) except a stack shows all children on top of each other. Stacks could potentially be easier since we wouldn't have to worry about the height of the node changing as the visible child changes (https://phabricator.services.mozilla.com/D35467#1084549), since they are always visible.

Depends on: 1580012
Depends on: 1580302
Depends on: 1582530
See Also: → 1585080
See Also: → 1585089

There's also -moz-stack-sizing which should be removable: https://searchfox.org/mozilla-central/search?q=moz-stack-sizing&path=

Depends on D49485

Summary: Investigate removing nsStackFrame (for example rendering the children as a single-grid-area CSS grid) → Remove nsStackFrame

(In reply to Tim Nguyen :ntim from comment #6)

Talos without last part: https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=try&newRevision=24ef95f3b2f72caea780243a9b0cfea03bce191d&framework=1&showOnlyImportant=1

FYI that is comparing an artifact push (new) with a non-artifact push (mozilla-central over last two days). I haven't gotten reliable results doing that in the past. In general I do: ./mach try fuzzy --preset perf-chrome both with any without changes applied to get a more direct comparison (artifact is fine, as long as they both are).

(In reply to Tim Nguyen :ntim from comment #8)

Artifact: https://treeherder.mozilla.org/#/jobs?repo=try&revision=51bdf4dec43aadb856226a0ccba6ace71a7cf219

The browser_urlbar_keyed_search.js failures are probably worth looking in to?

Blocks: 1589458

(In reply to Mats Palmgren (:mats) from comment #9)

(In reply to Tim Nguyen :ntim from comment #8)

Artifact: https://treeherder.mozilla.org/#/jobs?repo=try&revision=51bdf4dec43aadb856226a0ccba6ace71a7cf219

The browser_urlbar_keyed_search.js failures are probably worth looking in to?

Mats, do you have any idea how to fix the flicker that happens when a tab is opening ? I believe this is caused by the "Implement <stack> using CSS Grid." patch, but I'm not sure how to fix it. Fixing the flicker would fix the browser_urlbar_keyed_search.js and browser_windowopen.js perf tests.

For reference, the tab markup uses <stack> and the CSS for stack is now:

stack {
  display: grid;
  position: relative;
}

stack > *|* {
  grid-area: 1 / 1;
  z-index: 0;
}
Flags: needinfo?(mats)
Attached image Flicker start
Attached image Flicker end

I have no idea what that might come from. Would it possible to make a standalone testcase?

Flags: needinfo?(mats) → needinfo?(ntim.bugs)

(In reply to Mats Palmgren (:mats) from comment #13)

I have no idea what that might come from. Would it possible to make a standalone testcase?

Those flickers were only detected by the tests I mentioned above, it’s very hard/impossible to notice when starting Firefox manually.

The screenshots are generated by the test as well: if it detects a flicker, the test will generate 2 data URIs containing the screenshots.

That unfortunately means it’s quite tricky to create a standalone test case here, since things are very tied to the test.

You can run one of the two tests locally (browser_urlbar_keyed_search.js on Windows/Linux or browser_windowopen.js on MacOS) with the first patch applied.

Flags: needinfo?(ntim.bugs) → needinfo?(mats)
Blocks: 1589588
Keywords: site-compat

Hi Kohei, why was the site-compat keyword added here ? None of the features removed here are web-exposed.

Flags: needinfo?(kohei.yoshino)

Sorry, was misreading the intent post.

Flags: needinfo?(kohei.yoshino)
Keywords: site-compat
Summary: Remove nsStackFrame → Implement <stack> using CSS Grid and remove nsStackFrame

I debugged the browser_urlbar_keyed_search.js failure under rr on Linux and I think I understand why that issue occurs now.
The problem is that GetXULMinSize/GetXULPrefSize etc provides the frame's intrinsic size also in the block-axis, which for non-XUL boxes means that we'll have to reflow it to find out:
https://searchfox.org/mozilla-central/rev/11d9c7b7fa82fdfb8ac2a8f0864e9d8d5fe2b926/layout/generic/nsFrame.cpp#10144-10145
This changes the size of the frame to be its intrinsic size. Normally, there is a XULLayout call after that which resizes it again but it appears that's not guaranteed. In this case, we get these calls:
https://searchfox.org/mozilla-central/rev/11d9c7b7fa82fdfb8ac2a8f0864e9d8d5fe2b926/layout/base/PresShell.cpp#4185
viewManager->UpdateWidgetGeometry()
presShell->SyncWindowProperties()
nsContainerFrame::SyncWindowProperties, which calls GetXULMinSize here:
https://searchfox.org/mozilla-central/rev/11d9c7b7fa82fdfb8ac2a8f0864e9d8d5fe2b926/layout/generic/nsContainerFrame.cpp#617
with no XULLayout after that and then we paint it at that size.

Flags: needinfo?(mats)
Attached patch workaround wipSplinter Review

I'm not sure how to fix the issue mentioned above yet, but one way to workaround it is to set a definite height and make nsFrame::RefreshSizeCache skip the reflow in that case.
Seems to work, except maybe for the browser_toolbox_toolbar_overflow.js failures?
https://treeherder.mozilla.org/#/jobs?repo=try&revision=dd8adcda635cdf142503213892d654a4ad6c4106&selectedJob=273207256

After discussing this a bit more with dholbert, the flicker seems caused by RefreshSizeCache (which is what comment 18 suggests too), which is only called for documents with XUL root elements. I confirmed locally that applying patches from bug 1492582 along with the ones here fixes the flicker.

(In reply to Tim Nguyen :ntim from comment #19)

After discussing this a bit more with dholbert, the flicker seems caused by RefreshSizeCache (which is what comment 18 suggests too), which is only called for documents with XUL root elements. I confirmed locally that applying patches from bug 1492582 along with the ones here fixes the flicker.

Nice! So is this green with the html root node in browser.xhtml?

Blocks: 1559192

Tim, is this green now that Bug 1492582 has stuck?

Flags: needinfo?(ntim.bugs)

(In reply to Tim Nguyen :ntim from comment #22)

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8019c98635058192f94d4adf9dfb8aae9296eafc

I've fixed the toolkit/content/tests/browser/browser_label_textlink.js failures.

However, I still need to fix the reftest failures that happen only on particular platforms. Everything else looks green though.

I fixed the reftest failures locally with mstange's help, let's see what try says:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=93a11c1f4024dcea83bbc94f7c252433536e13cd

Flags: needinfo?(ntim.bugs)
Pushed by ntim.bugs@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/7477b284a8a3
Implement <stack> using CSS Grid. r=bgrins
https://hg.mozilla.org/integration/autoland/rev/68cc349414ca
Rewrite and remove tests relying on `display: -moz-stack;`. r=mats
https://hg.mozilla.org/integration/autoland/rev/1a85c571a464
Remove nsStackFrame platform code. r=mats
Assignee: nobody → ntim.bugs
Depends on: 1492582
Blocks: 1596047
Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
Blocks: 1596184
Regressions: 1596141
Blocks: 1596356
No longer regressions: 1596141
Regressions: 1596396
Regressions: 1596725
Regressions: 1596947
Depends on: 1596966
Regressions: 1598034
Regressions: 1596381
Regressions: 1599783
Regressions: 1601983

Are we still in a position where we can back this out of beta given that there's several open regressions here?

Flags: needinfo?(ntim.bugs)

(In reply to :Gijs (he/him) from comment #27)

Are we still in a position where we can back this out of beta given that there's several open regressions here?

It would require backing out a lot of bugs, but yes:

This bug, bug 1596966, bug 1598034, bug 1597844, bug 1596176 and bug 1596047.

Flags: needinfo?(ntim.bugs)

Alternatively, another possible route is to just back out https://hg.mozilla.org/mozilla-central/rev/1a85c571a464 and use display: -moz-stack on the usages that are currently broken.

Regressions: 1602230
Regressions: 1602924

(In reply to Tim Nguyen :ntim from comment #29)

Alternatively, another possible route is to just back out https://hg.mozilla.org/mozilla-central/rev/1a85c571a464 and use display: -moz-stack on the usages that are currently broken.

Is this something you can pursue, by say next week? (Presumably in a new bug?)

Flags: needinfo?(ntim.bugs)

(In reply to Julien Cristau [:jcristau] from comment #30)

(In reply to Tim Nguyen :ntim from comment #29)

Alternatively, another possible route is to just back out https://hg.mozilla.org/mozilla-central/rev/1a85c571a464 and use display: -moz-stack on the usages that are currently broken.

Is this something you can pursue, by say next week? (Presumably in a new bug?)

I'm already looking into it in bug 1599783.

Flags: needinfo?(ntim.bugs)

Awesome, thank you.

You need to log in before you can comment on or make changes to this bug.