Closed Bug 1528052 Opened 1 year ago Closed 1 year ago

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

Categories

(Core :: Layout, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox67 --- wontfix
firefox68 --- fixed

People

(Reporter: twisniewski, Assigned: hiro)

References

(Blocks 1 open bug, )

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.

Flags: webcompat?
Priority: -- → P3

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)

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)

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.

ni? myself to discuss this at next webcompat triage.

Flags: needinfo?(svoisen)
Blocks: 1472941
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)

Sure, I can finish this in 68 train.

Flags: needinfo?(hikezoe)
Priority: P3 → P1
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
Status: ASSIGNED → RESOLVED
Closed: 1 year 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.

Duplicate of this bug: 1235648

Documentation updated:

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