Commit 1bce68a0 authored by Timothy Nikkel's avatar Timothy Nikkel
Browse files

Bug 1749661. Always fire visual viewport resize event even if first reflow. r=botond 

I added this check in bug 1725569 because I said it matched other browsers. I'm not sure what testing I did there, or I made a mistake or what but the behaviour is not consistent between browsers.

For top level documents on initial load Safari sends a resize event, Chrome does not. Firefox sends a resize event.

For iframes Chrome and Safari send a resize event. Firefox usually sends a resize event.

Given the inconsistent behaviour here it seems better to err on the side of sending resize events because sites depend on it and might not work without it.

In the testcase from the bug I am able to reproduce about 20% of the time, and the problem is the first reflow check. So I'm removing that and I think it will fix the problem the user is seeing (which sounds to be more consistent).

Differential Revision: https://phabricator.services.mozilla.com/D135698
parent e54f4ec3

layout/generic/nsGfxScrollFrame.cpp

+1 −2
Original line number Diff line number Diff line
@@ -1464,8 +1464,7 @@ void nsHTMLScrollFrame::Reflow(nsPresContext* aPresContext, 
      // visual viewport is updated to account for that before we read the

      // visual viewport size.

      manager->UpdateVisualViewportSizeForPotentialScrollbarChange();

    } else if ((oldScrollPort.Size() != newScrollPort.Size()) &&

               !HasAnyStateBits(NS_FRAME_FIRST_REFLOW)) {

    } else if (oldScrollPort.Size() != newScrollPort.Size()) {

      // We want to make sure to send a visual viewport resize event if the

      // scrollport changed sizes for root scroll frames. The

      // MobileViewportManager will do that, but if we don't have one (ie we