The problematic scenario is when the page is exactly the height of the screen
(with dynamic toolbar not visible). In this case, the scrollable() function in
Axis.java returns false on the vertical axis, and so the JavaPanZoomController
never does any scrolling. This in turns means that the scrollBy code in
LayerMarginsAnimator never gets to run, so you can never drag the toolbar back
into being visible. The patch ensures that scrollable() returns true when some
or all of the margins are not visible, ensuring that in these scenarios the
user can still scroll the toolbar back onto the screen. This patch also adds
some comments/asserts to verify the new code is threadsafe.
This adds a notification callback to PanZoomTarget that the PanZoomController
can call to notify GeckoLayerClient that a subdocument is being scrolled. This
allows GeckoLayerClient to call LayerMarginsAnimator and alter the margins
accordingly, stopping a page from trapping the toolbar on/off the screen with
a screen-covering subframe.
Prior to this change, isBrowserContentDocumentDisplayed returned false
from the time that the isFirstPaint flag was set in layout to the time
that layout handed off the rendered document to the compositor. However
the way the function is used meant that it needs to return false until
the compositor actually composites the "first-paint" rendering,
otherwise other events can sneak in and run before the compositor. This
patch moves the tracking for the flag into GeckoLayerClient so that it
can be queried and modified synchronously from both the Gecko thread in
browser.js and the compositor thread in setFirstPaintViewport.
This stops margins from being exposed unless the drag was started in an area
of the viewport that's near said margin. The margins will always be exposed
when reaching the edge of the page.
Refactor the dynamic toolbar code so that the ownership of various properties
is clearer, and the page is offset by the toolbar instead of being overlapped.
This fixes problems with the scroll origin of the page not corresponding to
the visible origin on the screen.
Refactor the dynamic toolbar code so that the ownership of various properties
is clearer, and the page is offset by the toolbar instead of being overlapped.
This fixes problems with the scroll origin of the page not corresponding to
the visible origin on the screen.
The viewport wasn't being recalculated when the viewport margins changed, and
was also subject to some rounding errors. Round off the values before
comparing them (as they're screen pixels), and make sure to update the viewport
when the margins change. Margins were also not correctly being altered when
in overscroll, which could cause bottom-aligned fixed position content to be
incorrectly offset.
This patch matches previous behaviour, but adds the following scenarios:
- When rendering is aborted due to the viewport falling out of the displayport,
enable low precision rendering.
- When the viewport falls out of the displayport during low precision rendering,
low precision rendering will be enabled on the next frame.
Make sure to offset the viewport *after* setting the Gecko viewport on
setFirstPaintViewport callbacks, so that we don't store an incorrect viewport
origin and end up offsetting events incorrectly.
Similarly, on page size updates, the Java-side viewport metrics are used to
update the Gecko metrics, so make sure they're clamped so that they aren't
incorrect during overscroll.
If overscroll eats into a fixed margin, we need to apply the opposite
offset to the opposite side of the axis this occurred on. This has the effect
of fixed-position elements aligned to the bottom of the screen remaining
visible when at the top of the page.
This fixes the conflicting animations when the dynamic toolbar is hiding/showing
and overscroll is snapping back simultaneously. This is by not clamping the
entire viewport on margin-setting, and by making sure that only calling
setFixedLayerMargins changes the fixed layer margins.
This uses the aforementioned method on nsIDOMWindowUtils to make sure layout's
idea of the fixed position margins matches those used in the compositor.
This makes it possible to scroll to the top of the page with the toolbar visible
in Firefox for Android. It also causes JavaScript scrolling to position 0 to
expose the toolbar.
Offset fixed layers in the compositor so that the toolbar in Firefox for Android
doesn't obscure them. This does not affect layout, so input on the elements in
said layers will appear broken.
This uses the aforementioned method on nsIDOMWindowUtils to make sure layout's
idea of the fixed position margins matches those used in the compositor.
This makes it possible to scroll to the top of the page with the toolbar visible
in Firefox for Android. It also causes JavaScript scrolling to position 0 to
expose the toolbar.
Offset fixed layers in the compositor so that the toolbar in Firefox for Android
doesn't obscure them. This does not affect layout, so input on the elements in
said layers will appear broken.
This uses the aforementioned method on nsIDOMWindowUtils to make sure layout's
idea of the fixed position margins matches those used in the compositor.
This makes it possible to scroll to the top of the page with the toolbar visible
in Firefox for Android. It also causes JavaScript scrolling to position 0 to
expose the toolbar.
Offset fixed layers in the compositor so that the toolbar in Firefox for Android
doesn't obscure them. This does not affect layout, so input on the elements in
said layers will appear broken.
This patch has a bunch of semi-independent changes that unfortunately
couldn't be split apart without introducing hacks to make stuff build
on the intermediate patches. The main changes are:
- Moving TouchEventHandler from LayerView to JavaPanZoomController
- Registering the touch interceptor on the LayerView rather than the
TouchEventHandler
- Moving the Tab:HasTouchListener handler from GeckoApp to JPZC
The net effect of all of this is that the TouchEventHandler is hidden
behind the PanZoomController interface and not accessible to GeckoApp
or GeckoAppShell.
Additionally, some of the JPZC methods were renamed from onXXX to
handleXXX to maintain the convention that onXXX methods are "interface"
methods (i.e. exposed to arbitrary other code) whereas handleXXX
methods are private/package and should only be called in very specific
ways.
