These changes make nsDisplayCompositorHitTestInfo inherit directly from nsDisplayItem, which should shrink it slightly. This also simplifies the logic: hit testing information is now available at nsDisplayItem level as opposed to nsPaintedDisplayItem.
Differential Revision: https://phabricator.services.mozilla.com/D103773
This patch adds a diagnostic assert to check if the namespace of the
blob image key matches the current namespace of the process's
WebRenderBridgeChild. Other long lived users of image keys (i.e. shared
surfaces produced by imagelib) have to check to ensure their cached
image keys haven't gone out of scope due to a namespace update (e.g. tab
moved to a new window, GPU process crash). The caching for blob images
however is very different and should be cleared in these cases. This
assert will confirm this.
Differential Revision: https://phabricator.services.mozilla.com/D104066
This patch adds a diagnostic assert to check if the namespace of the
blob image key matches the current namespace of the process's
WebRenderBridgeChild. Other long lived users of image keys (i.e. shared
surfaces produced by imagelib) have to check to ensure their cached
image keys haven't gone out of scope due to a namespace update (e.g. tab
moved to a new window, GPU process crash). The caching for blob images
however is very different and should be cleared in these cases. This
assert will confirm this.
Differential Revision: https://phabricator.services.mozilla.com/D104066
In the case that we have a painted minimal display port apzc knows about the scroll frame already, it just has the minimal amount of painted content. So we can tell apz right away. Note that the async transform for minimal dp's are still the identity so we'll still jank minimap dp's before the painted regular dp reaches the apzc.
Differential Revision: https://phabricator.services.mozilla.com/D103858
This patch is the result of auditing all places that look at the presence or absence of a display port to handle minimal display ports (HasDisplayPort, GetDisplayPort, etc).
Broadly speaking the places were in two categories:
1) things related to painting, that want to consider minimal display ports as display ports for purposes of things like sending over metadata and separating out layers.
2) things that care about async scrolling, and so actually want to have a properly sized display port.
Type 1) were not changed by this patch. Type 2) were changed to consider minimal display ports as not display ports.
Again, we are aiming to leave behaviour unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D103856
We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression).
We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though).
We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port.
In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch.
My audit found that all of the places we set a display port want to clear the minimal display port property except:
-UpdateSub/RootFrame in APZCCallbackHelper
-UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils
UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases:
-a scroll info layer
-a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call)
-a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them.
It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare).
Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports.
Differential Revision: https://phabricator.services.mozilla.com/D103855
We currently don't ever set non-rectilinear transforms on our CALayers, so there
is no need for anti-aliasing. Explicitly disabling edge anti-aliasing means that
there are no seams between tiles when the window server draws our window with a
transform, such as during Mission Control.
Differential Revision: https://phabricator.services.mozilla.com/D103740
This assert fails on the new reftest from this bug, on Android.
I haven't dug into it too deeply, given that it's code that'll be going away at
some point soon (hopefully), but I think what happens is that we have a fixed
layer which is not annotated as fixed. That's normal for background-attachment:
fixed root backgrounds. We handle explicitly-annotated-as-fixed layers a bit
further up in this function.
Returning false here seems like a very safe thing to do.
Depends on D54855
Differential Revision: https://phabricator.services.mozilla.com/D103736
https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/gfx/layers/apz/src/AsyncPanZoomController.cpp#4866
scrollOffsetUpdated gets set to true if we get basically any scroll update, including a NewScrollFrame update that we create for every new scroll frame that just informs apzc the scroll offset is (0,0).
scrollOffsetUpdated being true means RequestContentRepaint gets called a little later. RequestContentRepaint causes a full display port to be set on the content. That is undesirable because we set zero margin display ports (via SetZeroMarginDisplayPortOnAsyncScrollableAncestors) and we don't want to expand them to full display ports.
This bug is to fix the regression caused by bug 1662013. Two other bugs also regressed this (bug 1627012 and bug 1667475), and we need to fix all of them to fix the problem. Bug 1687886 is filed for the regression from bug 1667475. Bug 1687926 is filed for the regression from bug 1627012.
Before https://hg.mozilla.org/integration/autoland/rev/b78646d59e32 we only set scrollOffsetUpdated to true if GetScrollOffsetUpdated() was set to true on the metrics, and it didn't get set to true for new scroll frames.
Differential Revision: https://phabricator.services.mozilla.com/D102587
https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/gfx/layers/apz/src/AsyncPanZoomController.cpp#5034
That RequestContentRepaint call gets executed every time isDefault is true (and ignoreVisualUpdate is false), ie whenever the azpc gets metrics for the first time. RequestContentRepaint causes a full display port to be set on the content. That is undesirable because we set zero margin display ports (via SetZeroMarginDisplayPortOnAsyncScrollableAncestors) and we don't want to expand them to full display ports
This bug is to fix the regression caused by bug 1627012. Two other bugs also regressed this (bug 1662013 and bug 1667475), and we need to fix all of them to fix the problem. Bug 1687886 is filed for the regression from bug 1667475. Bug 1687927 is filed for the regression from bug 1662013.
https://hg.mozilla.org/integration/autoland/rev/47328d6c1b40 made us request a repaint any time we have default metrics because we might get a new visual scroll offset, but if our visual scroll offset doesn't change we shouldn't need to do anything.
Differential Revision: https://phabricator.services.mozilla.com/D102586
https://searchfox.org/mozilla-central/rev/2c06b16a0c15ae340a0532e319cbf89ef9d21b68/gfx/layers/apz/src/AsyncPanZoomController.cpp#4866
scrollOffsetUpdated gets set to true if we get basically any scroll update, including a NewScrollFrame update that we create for every new scroll frame that just informs apzc the scroll offset is (0,0).
scrollOffsetUpdated being true means RequestContentRepaint gets called a little later. RequestContentRepaint causes a full display port to be set on the content. That is undesirable because we set zero margin display ports (via SetZeroMarginDisplayPortOnAsyncScrollableAncestors) and we don't want to expand them to full display ports.
This bug is to fix the regression caused by bug 1662013. Two other bugs also regressed this (bug 1627012 and bug 1667475), and we need to fix all of them to fix the problem. Bug 1687886 is filed for the regression from bug 1667475. Bug 1687926 is filed for the regression from bug 1627012.
Before https://hg.mozilla.org/integration/autoland/rev/b78646d59e32 we only set scrollOffsetUpdated to true if GetScrollOffsetUpdated() was set to true on the metrics, and it didn't get set to true for new scroll frames.
Differential Revision: https://phabricator.services.mozilla.com/D102587
This test has some tricky timing requirements so I mostly left the
callback-style alone in the main part of the test. The setTimeout/
rAF callbacks run at a specific time, whereas converting them to
promises would change that to "run no sooner than ..." which in this
is undesirable.
Differential Revision: https://phabricator.services.mozilla.com/D103118
Combobox select has the block-axis padding in the comboboxcontrol frame.
Moving it fixes bug 1560824 and should be better, so will do that there.
1px block axis padding on buttons matches Chrome too, so shouldn't be a
problem compat-wise.
Differential Revision: https://phabricator.services.mozilla.com/D103244
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
