[Gecko Bug 1935189] Don't make frame initial viewport size depend on whether it's been laid out. #49955
+57
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…id out. This is rather tricky / unfortunate, but this is the low-risk fix for now. The issue is as follows: When we construct a subdocument frame, we try to show its viewer by using a script runner which will call ShowViewer(). If ShowViewer() gets called before the subdoc frame gets laid out (has the NS_FRAME_FIRST_REFLOW bit set), we pick an (arbitrary) 10x10 device pixel size, and initialize the page with that viewport. Then, eventually, the frame gets laid out to the correct size and fires a resize event. If we have container queries around, we need to lay out the page while styling, which causes the layout to happen before the script blocker checkpoint, and thus the viewport to get initialized with the right size to begin with. This generally shouldn't be bad, but google chat at least seems to rely on this resize event (and the divergence being caused by container queries is rather unfortunate). For now, do the low risk fix of always using the "initial" subdoc frame size to show the viewer. We should ideally sort this out better. Even our "good" behavior is quite bizarre (e.g, I'd expect going from display: block to none to trigger a resize event and the viewport to go back to 0... As you noted, chrome's inner layout sizes do change when the frame is display: none). But it seems worth to land this at least in the interim. Differential Revision: https://phabricator.services.mozilla.com/D233399 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1935189 gecko-commit: 0c612ed5d669c157a34c24d0c7df4b7f8ccd5fe4 gecko-reviewers: dholbert
wpt-pr-bot
approved these changes
Jan 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is rather tricky / unfortunate, but this is the low-risk fix for
now. The issue is as follows:
When we construct a subdocument frame, we try to show its viewer by
using a script runner which will call ShowViewer().
If ShowViewer() gets called before the subdoc frame gets laid out
(has the NS_FRAME_FIRST_REFLOW bit set), we pick an (arbitrary) 10x10
device pixel size, and initialize the page with that viewport.
Then, eventually, the frame gets laid out to the correct size and fires
a resize event.
If we have container queries around, we need to lay out the page while
styling, which causes the layout to happen before the script blocker
checkpoint, and thus the viewport to get initialized with the right size
to begin with.
This generally shouldn't be bad, but google chat at least seems to rely
on this resize event (and the divergence being caused by container
queries is rather unfortunate).
For now, do the low risk fix of always using the "initial" subdoc frame
size to show the viewer.
We should ideally sort this out better. Even our "good" behavior is
quite bizarre (e.g, I'd expect going from display: block to none to
trigger a resize event and the viewport to go back to 0... As you noted,
chrome's inner layout sizes do change when the frame is display: none).
But it seems worth to land this at least in the interim.
Differential Revision: https://phabricator.services.mozilla.com/D233399
bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1935189
gecko-commit: 0c612ed5d669c157a34c24d0c7df4b7f8ccd5fe4
gecko-reviewers: dholbert