1. 30 May, 2020 1 commit
  2. 21 Nov, 2019 1 commit
    • Hiroyuki Ikezoe's avatar
      Bug 1586986 - Fire visual viewport resize events and flush position:fixed... · 7afdb848
      Hiroyuki Ikezoe authored
      Bug 1586986 - Fire visual viewport resize events and flush position:fixed elements' layout in the same way what Chrome does. r=botond
      
      On Chrome, visual viewport resize event is fired repeatedly during dynamic
      toolbar transitions and visual viewport height obtained by the VisualViewport
      API is also changed, but in terms of layout the height value is never used
      until the dynamic toolbar height reaches to zero or is changed from zero.
      The height used at the time is the height for vh units when the toolbar height
      reaches to zero and the ICB height when the toolbar height is changed from zero.
      To do so, we need to have another visual viewport size in parallel to the
      original one and use them depending on situations.
      
      Differential Revision: https://phabricator.services.mozilla.com/D52338
      
      --HG--
      extra : moz-landing-system : lando
      7afdb848
  3. 25 Sep, 2019 2 commits
    • Emilio Cobos Álvarez's avatar
      Bug 1551659 - Remove MVMContext::ResizeEventFlag and related code. r=botond,hiro · 161cb16c
      Emilio Cobos Álvarez authored
      D46944 / bug 1583534 is what fixes the root cause of bug 1528052 by not
      having the first call to ResizeReflow have a wrong old size of 0x0.
      
      This removes the code that bug introduces to suppress resize events, which
      fixes this bug. I think our behavior now is pretty sane.
      
      In particular, consider the test-case:
      
      <!doctype html>
      <meta name="viewport" content="width=device-width, initial-scale=1.0">
      <a href="" target="_blank">Open me in a separate tab</a>
      <pre id="log"></pre>
      <script>
        // This shouldn't be needed, but otherwise Fenix doesn't show the tooltip on
        // longpress...
        document.querySelector("a").href = location.href;
      
        function logSize() {
          log.innerText += window.innerWidth + "x" + window.innerHeight + "\n";
        }
        logSize();
        onresize = logSize;
      </script>
      
      (Hosted at https://crisal.io/tmp/gecko-mobile-resize.html for convenience)
      
      Right now on trunk, when you click the link from GVE or Fenix, we're only
      getting an initial size of 0x0 (which is not great, btw), and only after first
      paint we get the real device size, but content doesn't get a resize event.
      
      This is obviously wrong, every time the layout viewport changes we should fire
      resize events.
      
      Pages that get opened in new tabs and get refreshed when resized may get an
      extra reload with this approach, but this seems not avoidable unless widget sets
      the viewport size right in advance (which from discussion with snorp and agi
      doesn't seem possible in the general case).
      
      What used to happen is that we were triggering a redundant resize reflow from
      the initial paint which didn't update the layout viewport (because the content
      viewer and co had the right viewport from the previous navigation).
      
      Now that we optimize those away, I think our behavior should be correct.
      
      Differential Revision: https://phabricator.services.mozilla.com/D46956
      
      --HG--
      extra : moz-landing-system : lando
      161cb16c
    • Emilio Cobos Álvarez's avatar
      Bug 1583534 - Further simplify PresShell::ResizeReflow. r=botond · 848d89d6
      Emilio Cobos Álvarez authored
      In particular, not let ResizeReflow take the old and new size. Most of the
      callers pass dummy values anyway.
      
      Instead, use the old size of the layout viewport. This ensures we fire resize
      events only if the layout viewport actually changes.
      
      This is important because the first resize of the mobile viewport manager
      after a navigation has an "old size" of 0x0, even though the layout viewport
      is initialized on presshell initialization to the right size.
      
      Thus, we fire resize events unnecessarily in that case, which is the root cause
      for bug 1528052.
      
      To do this, we need to shuffle a bit of code in nsDocumentViewer that deals with
      delayed resizes, to set the visible area _and_ invalidate layout, rather than
      setting the visible area and _then_ relying on doing a resize reflow.
      
      Further cleanup is possible, though not required for my android resizing fix, so
      will do separately.
      
      Differential Revision: https://phabricator.services.mozilla.com/D46944
      
      --HG--
      extra : moz-landing-system : lando
      848d89d6
  4. 12 Aug, 2019 1 commit
  5. 07 Aug, 2019 1 commit
  6. 09 Jul, 2019 1 commit
  7. 30 Apr, 2019 3 commits
  8. 25 Apr, 2019 3 commits
    • Masayuki Nakano's avatar
      Bug 1545342 - part 3: Move remaining public enum of nsIPresShell to mozilla... · 2933c032
      Masayuki Nakano authored
      Bug 1545342 - part 3: Move remaining public enum of nsIPresShell to mozilla namespace in mozilla/PresShellForwards.h and make them enum class r=smaug
      
      This patch moves remaining public `enum` of `nsIPresShell` to `mozilla`
      namespace in `mozilla/PresShellForwards.h` and make them `enum class`es.
      
      Additionally, some methods which use the moving `enum`s from `nsIPresShell`
      to `PresShell`.
      
      Differential Revision: https://phabricator.services.mozilla.com/D28607
      
      --HG--
      extra : moz-landing-system : lando
      2933c032
    • Masayuki Nakano's avatar
      Bug 1545342 - part 2: Make some public enum of nsIPresShell move to mozilla... · 36225094
      Masayuki Nakano authored
      Bug 1545342 - part 2: Make some public enum of nsIPresShell move to mozilla namespace and defined as enum class in PresShellForwards.h r=smaug
      
      This patch moves some `enum` in `nsIPresShell` which are in public scope into
      `mozilla` namespace and change them as `enum class`es.
      
      Unfortunately, only "where to scroll" enum is just defines constants of
      percentages of scroll destination.  Therefore, this patch makes only them
      as `static const`.
      
      Differential Revision: https://phabricator.services.mozilla.com/D28606
      
      --HG--
      extra : moz-landing-system : lando
      36225094
    • Masayuki Nakano's avatar
      Bug 1545342 - part 1: Create mozilla/PresShellForwards.h and move global... · 5932f01d
      Masayuki Nakano authored
      Bug 1545342 - part 1: Create mozilla/PresShellForwards.h and move global enums/constants in nsIPresShell.h and mozilla/PresShell.h into the new one r=smaug
      
      This patch creates new header, `mozilla/PresShellForwards.h`.  It should have
      all forward declarations of global class/struct in `nsIPresShell.h` and
      `mozilla/PresShell.h`.
      
      Additionally, this moves all `enum`s and `constant`s in them into the new file
      with changing them to `enum class`es.
      
      This will make other headers which require only specific types in the header
      files not include them.
      
      Differential Revision: https://phabricator.services.mozilla.com/D28605
      
      --HG--
      extra : moz-landing-system : lando
      5932f01d
  9. 01 May, 2019 2 commits