Where an adjustment (to reflect a delta between the APZ and layout
scroll offsets) is necessary, the inputs needed to compute the
adjustment are stored with the margins, and the adjustment is
applied at query time.
A couple of notes on this patch:
* Storing DisplayPortMargins::mLayoutOffset is probably unnecessary,
we should be able to just query the scroll frame's layout offset
when applying the margins.
* Some callers of DisplayPortMargins::WithNoAdjustment() may be
incorrect, in that they pass in margins that are relative to the
visual viewport but do not make a corresponding adjustment.
This is a pre-existing issue that this patch just makes clearer.
As this is a regression-prone area, this patch is careful to avoid
making any functional changes, leaving the above issues to be
addressed in future bugs.
Differential Revision: https://phabricator.services.mozilla.com/D92506
Along with a dependent struct DirectDrawInfo.
This allows nsImageRenderer.h and CanvasRenderingContext2D.h to
avoid including nsLayoutUtils.h.
For nsImageRenderer.h in particular, a forward declaration is
not sufficient as nsImageRenderer stores SurfaceFromElementResult
by value.
A couple of method definitions elsewhere are moved out of line
to keep things compiling without including nsLayoutUtils.h in
additional headers.
Differential Revision: https://phabricator.services.mozilla.com/D91684
Autocapitalize isn't applied if type is url, email or password. If these types,
truncate autocapitalize value in InputContext not to pass it to widget.
Differential Revision: https://phabricator.services.mozilla.com/D86676
Mostly mechanical change, with some extra work where non-literal names are provided.
Also, when this is the only profiler call in a file, `#include "GeckoProfiler.h"` can be changed to `#include "mozilla/ProfilerMarkers.h"`.
Differential Revision: https://phabricator.services.mozilla.com/D89415
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