Fennec and Geckoview fire resize events on page-load while Chromium does not
Categories
(Core :: Layout, defect, P1)
Tracking
()
People
(Reporter: twisniewski, Assigned: hiro)
References
()
Details
(Keywords: dev-doc-complete, Whiteboard: [webcompat:p1][wptsync upstream])
Attachments
(1 file)
Based on a trivial test-case:
<!DOCTYPE html>
<html>
<script>
window.addEventListener("resize", function() {
document.body.appendChild(document.createTextNode("resize "));
});
</script>
</html>
It seems as though Firefox fires a resize event during page-load while Chromium does not (though Chromium does fire similar resize events when the device changes orientation).
This extra resize event is throwing off the scripts at eduscol.education.fr, which do not expect it, and causes their page to not load properly.
|
||
Updated•5 years ago
|
|
Reporter | |
Comment 1•5 years ago
|
||
This is also affecting swimmeet.com, making the page never stop (re)loading.
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
Hiro, you've done a bunch of viewport-related stuff, any chance you know what's going on here?
|
Assignee | |
Comment 3•5 years ago
•
|
||
The initial resize event is triggered from ResizeReflowIgnoreOverride call in RefreshVisualViewportSize on the initial paint. Probably we don't need the resize event at that time.
Also, in bug 1149555 unfortunately (accidentally?) we dropped the check whether the size is changed.
|
|
Assignee | |
Comment 4•5 years ago
•
|
||
I thought initially we can avoid the resize event on the case where nsIPresShell::mIsFirstPaint is true, but it breaks existing test cases a lot.
We should probably avoid the event only on the case MobileViewportManager::mIsFirstPaint is true. Here is a try.
|
||
Comment 5•5 years ago
|
||
https://webcompat.com/issues/25660
Probably a candidate for this bug.
|
|
||
Updated•5 years ago
|
|
||
Comment 6•5 years ago
|
||
ni? myself to discuss this at next webcompat triage.
|
||
Updated•5 years ago
|
|
|
||
Comment 7•5 years ago
|
||
@Hiro: Would you mind prioritizing this once all of the scroll snap and current Fission work is complete?
|
|
Assignee | |
Comment 8•5 years ago
|
||
Sure, I can finish this in 68 train.
|
|
Assignee | |
Comment 9•5 years ago
|
||
|
|
Assignee | |
Comment 10•5 years ago
|
||
|
||
Comment 11•5 years ago
|
||
Pushed by hikezoe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0b0a2b12bd05 Suppress resize events until the initial paint has finished on mobile. r=botond
|
||
Comment 12•5 years ago
|
||
| bugherder | ||
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/16487 for changes under testing/web-platform/tests
|
||
Comment 14•5 years ago
|
||
It seems like a largish change to uplift but it was recentely raised to P1, so I am marking it as fix-optional until there is confirmation that we don't need this is 67 or that we want it but it is extra safe to uplift.
Upstream PR merged
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Comment 17•5 years ago
|
||
Documentation updated:
- BCD PR 4358 submitted
- Firefox 68 for developers updated
Description
•