Fennec and Geckoview fire resize events on page-load while Chromium does not

RESOLVED FIXED in Firefox 68

Status

()

defect
P1
normal
RESOLVED FIXED
3 months ago
18 days ago

People

(Reporter: twisniewski, Assigned: hiro)

Tracking

(Blocks 1 bug, {dev-doc-needed})

Trunk
mozilla68
Points:
---
Dependency tree / graph
Bug Flags:
webcompat +

Firefox Tracking Flags

(firefox67 wontfix, firefox68 fixed)

Details

(Whiteboard: [webcompat:p1][wptsync upstream], )

Attachments

(1 attachment)

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.

Flags: webcompat?
Priority: -- → P3
Reporter

Comment 1

3 months ago

This is also affecting swimmeet.com, making the page never stop (re)loading.

Component: DOM: Events → Layout

Hiro, you've done a bunch of viewport-related stuff, any chance you know what's going on here?

Flags: needinfo?(hikezoe)
Assignee

Comment 3

3 months 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: nobody → hikezoe
Status: NEW → ASSIGNED
Flags: needinfo?(hikezoe)
Assignee

Comment 4

3 months 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.

https://webcompat.com/issues/25660
Probably a candidate for this bug.

ni? myself to discuss this at next webcompat triage.

Flags: needinfo?(svoisen)
Flags: webcompat? → webcompat+
Whiteboard: [webcompat] → [webcompat:p1]

@Hiro: Would you mind prioritizing this once all of the scroll snap and current Fission work is complete?

Flags: needinfo?(svoisen) → needinfo?(hikezoe)
Assignee

Comment 8

a month ago

Sure, I can finish this in 68 train.

Flags: needinfo?(hikezoe)
Priority: P3 → P1

Comment 11

a month 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

a month ago
bugherder
Status: ASSIGNED → RESOLVED
Last Resolved: a month ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/16487 for changes under testing/web-platform/tests
Whiteboard: [webcompat:p1] → [webcompat:p1][wptsync upstream]

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
Duplicate of this bug: 1235648
You need to log in before you can comment on or make changes to this bug.