It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
Instead of getting/setting the size on the view manager on a fullscreen
change, this updates the code to get/set the size on the content viewer, which
internally sets the size on the view manager. Doing this ensures that the
content viewer size is updated prior to the reflow, which is required for
the MobileViewportManager to update its internal notions of size and to update
the visual viewport properly.
Differential Revision: https://phabricator.services.mozilla.com/D87161
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
Right now they start with a FullyHidden() effect info, but with a
"visible" widget, and thus active docshell and so on.
That's no good :)
Differential Revision: https://phabricator.services.mozilla.com/D86364
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
There's no need to put this in nsLayoutUtils since it's so closely bound
to presShell anyway. So we move it from being a static nsLayoutUtils function
that takes a PresShell pointer, to being a method on the PresShell itself.
Two functional changes here:
1. Don't run the MaybeReflowForInflationScreenSizeChange code unless the
visual viewport actually changes
2. Run the MaybeReflowForInflationScreenSizeChange if the visual viewport
is reset.
These functional changes can be logically thought of as "group the font-
inflation reflow stuff together with the other visual-viewport-triggered
reflow stuff".
Depends on D80040
Differential Revision: https://phabricator.services.mozilla.com/D80041
This patch implements a per-process cache of parsed stylesheets for
non-inline sheets. The entries are evicted when the document gets
destroyed and there's no other document with the same principal around.
This works fine in practice even when navigating because CC happens
pretty late, but we could add an extra timer if we deem it worth it.
I had to adapt some tests so that they keep passing. They were already
clearing various image / network caches so it seems fine to also clear
this one.
Note that there's a very subtle change in the load data key: We only
miss the cache if the referrer _policy_ is different, not if the
referrer is different. While that is slightly dubious, that is the only
think that makes this effort somewhat worth it. Otherwise stylesheets
would have to be re-fetched if the referrer is different, which
effectively would mean to re-parse it if the document URI is different,
which is bad.
It seems like the network cache only keys on the referrer policy, so it
seems fine to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D77457
This patch implements a per-process cache of parsed stylesheets for
non-inline sheets. The entries are evicted when the document gets
destroyed and there's no other document with the same principal around.
This works fine in practice even when navigating because CC happens
pretty late, but we could add an extra timer if we deem it worth it.
I had to adapt some tests so that they keep passing. They were already
clearing various image / network caches so it seems fine to also clear
this one.
Note that there's a very subtle change in the load data key: We only
miss the cache if the referrer _policy_ is different, not if the
referrer is different. While that is slightly dubious, that is the only
think that makes this effort somewhat worth it. Otherwise stylesheets
would have to be re-fetched if the referrer is different, which
effectively would mean to re-parse it if the document URI is different,
which is bad.
It seems like the network cache only keys on the referrer policy, so it
seems fine to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D77457
One note about this solution: it includes the apz callback transform for the root scroll frame of the root content document, but no other apz callback transform that might be on an ancestor of the select element.
Differential Revision: https://phabricator.services.mozilla.com/D78026
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This patch adds support for the capture and replaying of multiple frames
during normal operation of Firefox. Ctrl + Shift + 6 starts capturing
and pressing it again stops capturing. It attempts to capture the minimum
amount of data required to replay a sequence for debugging purposes.
There are several known limitations, particularly surrounding replaying
when transitioning between snapshots of the resource cache. It will
reload the entire document set, causing greater delay between frames.
Should you advance too quickly, it may also panic due to a race between
the current frame still being generated, and the new frame resetting the
resource cache state. These should be resolved with time, and the
current implementation should be workable to at least capture/debug most
animated issues with some effort.
It also adds support for loading dynamic properties which is necessary
for accurate replaying of a captured frame (sequence or individual)
which are in the middle of an animation.
Differential Revision: https://phabricator.services.mozilla.com/D59755
This patch adds support for the capture and replaying of multiple frames
during normal operation of Firefox. Ctrl + Shift + 6 starts capturing
and pressing it again stops capturing. It attempts to capture the minimum
amount of data required to replay a sequence for debugging purposes.
There are several known limitations, particularly surrounding replaying
when transitioning between snapshots of the resource cache. It will
reload the entire document set, causing greater delay between frames.
Should you advance too quickly, it may also panic due to a race between
the current frame still being generated, and the new frame resetting the
resource cache state. These should be resolved with time, and the
current implementation should be workable to at least capture/debug most
animated issues with some effort.
It also adds support for loading dynamic properties which is necessary
for accurate replaying of a captured frame (sequence or individual)
which are in the middle of an animation.
Differential Revision: https://phabricator.services.mozilla.com/D59755
We lifted this restriction because with bug 656036 it makes sense to zoom into a
focused input in a fixed subtree. But this causes undesired panning up.
We could conceivably fix it if needed, but for now preserve the previous
behavior of not panning nor zooming.
Differential Revision: https://phabricator.services.mozilla.com/D69946
The tests don't have a reliable mechanism to wait for a potential zoom
animation to end, leading to flakiness due to a zoom animation form a previous
sub-case interfering with the current sub-case.
Differential Revision: https://phabricator.services.mozilla.com/D67522
