Document::GetBrowsingContext uses a WeakPtr<nsIDocShell> so we can't do
that. But we have all the other media emulation data and so on in the
pres context which we can access off the main thread for style, so move the
override code there.
Differential Revision: https://phabricator.services.mozilla.com/D128673
We have JS listeners that are expected to run once the LookAndFeel
caches have been cleared and such, so split the look-and-feel-changed
notification into an internal and external notification.
Differential Revision: https://phabricator.services.mozilla.com/D128097
Also, make the same change to nsPresContext::GetTextInputHandlingWidget and
TextComposition::GetWidget, which are essentially aliases/wrappers for this
function.
This patch shouldn't change behavior at all, aside from:
* optimizing away some redundant reference counting and widget-lookups
* delaying some nsIWidget::Release() calls, which will now happen after we're
actually done using the object, instead of happening when the getter
completes. (It's unlikely this impacts behavior, because there are other
objects that are keeping the nsIWidget instance alive.)
Motivation / "wins" from this patch:
* nsPresContext::GetRootWidget already works with a refcounted pointer
internally. Before this patch, it drops the reference before returning the
pointer. This is a bit suspect and would cause security issues, in the
unlikely event that this were the last strong reference to the object. It
can just as easily/efficiently transfer the strong reference to the caller,
and let the caller determine when to release it.
* Many of the callers were already storing the return value in nsCOMPtr, which
meant that they were incurring an additional AddRef/Release when
populating/destructing that smart pointer. Now they can just take ownership
of the already_AddRefed return value and avoid redundnat refcount-churn.
* For the callers that weren't storing the return value in nsCOMPtr, some of
them were calling this getter twice in a row (once to test for truthiness and
once to use the known-truthy value). This was wasteful, both from the
repeated lookup-work (since the function isn't a trivial getter), and from
repeated refcount-churn. This patch collapses these repeat-calls to a single
call, avoiding those inefficiencies.
Differential Revision: https://phabricator.services.mozilla.com/D127180
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
Also, make the same change to nsPresContext::GetTextInputHandlingWidget and
TextComposition::GetWidget, which are essentially aliases/wrappers for this
function.
This patch shouldn't change behavior at all, aside from:
* optimizing away some redundant reference counting and widget-lookups
* delaying some nsIWidget::Release() calls, which will now happen after we're
actually done using the object, instead of happening when the getter
completes. (It's unlikely this impacts behavior, because there are other
objects that are keeping the nsIWidget instance alive.)
Motivation / "wins" from this patch:
* nsPresContext::GetRootWidget already works with a refcounted pointer
internally. Before this patch, it drops the reference before returning the
pointer. This is a bit suspect and would cause security issues, in the
unlikely event that this were the last strong reference to the object. It
can just as easily/efficiently transfer the strong reference to the caller,
and let the caller determine when to release it.
* Many of the callers were already storing the return value in nsCOMPtr, which
meant that they were incurring an additional AddRef/Release when
populating/destructing that smart pointer. Now they can just take ownership
of the already_AddRefed return value and avoid redundnat refcount-churn.
* For the callers that weren't storing the return value in nsCOMPtr, some of
them were calling this getter twice in a row (once to test for truthiness and
once to use the known-truthy value). This was wasteful, both from the
repeated lookup-work (since the function isn't a trivial getter), and from
repeated refcount-churn. This patch collapses these repeat-calls to a single
call, avoiding those inefficiencies.
Differential Revision: https://phabricator.services.mozilla.com/D127180
This patch shouldn't change behavior at all.
This patch replaces a manual NS_ADDREF call with typesafe code that manages the
reference count for us. This reduces repeated boilerplate code, in the
implementation as well as the callsites.
Differential Revision: https://phabricator.services.mozilla.com/D127179
There's only one meaningful usage of it, which is to disable native
appearance of the <input type=range> (the windows native theme is no
longer exposed to content).
<input type=range> is inconsistent with every other native widget, which
only disables native appearance if the author specifies backgrounds or
borders. So make it match literally all other widgets and simplify a bit
the code.
We had no tests for this special behavior, let me know if you think it's
worth adding one (but I don't feel very strongly about it).
Differential Revision: https://phabricator.services.mozilla.com/D127082
There's only one meaningful usage of it, which is to disable native
appearance of the <input type=range> (the windows native theme is no
longer exposed to content).
<input type=range> is inconsistent with every other native widget, which
only disables native appearance if the author specifies backgrounds or
borders. So make it match literally all other widgets and simplify a bit
the code.
We had no tests for this special behavior, let me know if you think it's
worth adding one (but I don't feel very strongly about it).
Differential Revision: https://phabricator.services.mozilla.com/D127082
This adds `privacy.resistFingerprinting` to the list of prefs for which `nsPresContext` registers a callback,
because it is included among the prefs that `nsPresContext::PreferenceChanged` explicitly wants to handle.
We also sort the `gExactCallbackPrefs` array, to make it easier to scan its contents at a glance
in the future.
layout.css.prefers-contrast.enabled is dropped from being handled in PreferenceChanged, because that
doesn't actually work; we need to reload the document (re-parse the stylesheet) to notice the change.
Differential Revision: https://phabricator.services.mozilla.com/D125857
Some style system APIs (like StyleNewSubtree) don't deal with nested
restyles really well (it'd be weird if StyleNewSubtree would end up
styling not only that subtree but the whole document).
To prevent breaking style system invariants, make sure to invalidate the
style asynchronously using an early runner. This should ensure at most
one frame of wrong metrics, but usually zero.
Differential Revision: https://phabricator.services.mozilla.com/D126076
SetContainer handling is similar to what DocumentViewer does for the old bfcache implementation.
(The old implementation hides it quite well).
The changes to HTMLMediaElement are needed to ensure page can enter bfcache.
Removed erroneous MOZ_ASSERT in nsPresContext, it is ok to trigger that code path in the new implementation.
And the Run() method of the relevant nsIRunnable already deals with that case.
Differential Revision: https://phabricator.services.mozilla.com/D124684
This does not in itself change user-visible behavior, but is a foundation for bug
1715507 where we will make the behavior per-context instead of global. This is basically
just plumbing, passing a pointer to the presContext that's asking for fonts to be
resolved all the way down to the gfx code that handles the font list and looks up
fonts.
For the immediate goal of making font visibility work per-context, it would be
sufficient to pass the desired visibility level in to the font-selection methods.
However, passing the actual presContext down (and not just its visibility level)
will enable us to report back via the dev console when a font is blocked (see bug
1715537), so the approach here provides the basis for that upcoming enhancement.
Depends on D124194
Differential Revision: https://phabricator.services.mozilla.com/D124195
This does not in itself change user-visible behavior, but is a foundation for bug
1715507 where we will make the behavior per-context instead of global. This is basically
just plumbing, passing a pointer to the presContext that's asking for fonts to be
resolved all the way down to the gfx code that handles the font list and looks up
fonts.
For the immediate goal of making font visibility work per-context, it would be
sufficient to pass the desired visibility level in to the font-selection methods.
However, passing the actual presContext down (and not just its visibility level)
will enable us to report back via the dev console when a font is blocked (see bug
1715537), so the approach here provides the basis for that upcoming enhancement.
Depends on D124194
Differential Revision: https://phabricator.services.mozilla.com/D124195
AFAICT these functions are interested in documents at the root of a tab, not ones that happen to be at the root of a process.
Differential Revision: https://phabricator.services.mozilla.com/D124274
Remove the need to post a runnable to coalesce them (we still coalesce
theme changes because those do non-trivial work).
What can go on is that on cold load we load the font list async, and
that goes through this code via a faked font.internaluseonly.changed
pref change, which stores a reframe change hint in
mChangeHintForPrefChange.
If the page flushes after this code runs, but before the next refresh
driver tick, we will be just wasting work. So instead do the
RebuildAllStyleData call synchronously. It just schedules a flush and
posts a hint, so it doesn't do the work right there, but makes the next
flush do the work as needed, so it should be faster and also more
correct.
Also improve handling of preference sheet prefs and such to avoid more
wasted work when we go through this code, as the assumption their
handling was doing was that it gets called infrequently, but it's not
the case due to the font list updates.
Differential Revision: https://phabricator.services.mozilla.com/D123103
To look up/instantiate platform fonts based on CSS font properties, we create a gfxFontGroup from an nsFont and other attributes; this is currently cached in an nsFontCache attached to the nsDeviceContext.
However, this assumes that the mapping to platform fonts will be the same for all documents using the given device context. In a world where visibility of platform fonts to the page may be restricted, and may depend on the individual document (e.g. if the user disables tracking protection for a particular site), the mapping represented by nsFontCache may vary, and determining how to resolve a given font request will need access to the requesting document in order to know what visibility it is allowed.
To support this, this patch moves the nsFontCache from nsDeviceContext to nsPresContext. In itself, this should cause no visible change in behavior, but it provides a basis for the patches that will follow in bug 1715501.
It's likely that this will have some effects on individual performance tests, depending on the exact content and sequencing of page loads, because of changed caching behavior. E.g. having a per-presContext cache may sometimes mean that we no longer take advantage of a cached gfxFontGroup that a previously-loaded page created; but on the other hand the caches will tend to be smaller and have faster lookups.
My testing so far suggests that we will see some apparent regressions, alongside some improvements, but that overall there should be little change. I'd like to get this change landed separately, before any of the actual font-visibility behavior changes, so that we can more clearly see and isolate any unexpected effects.
Differential Revision: https://phabricator.services.mozilla.com/D122715
The subdocuments _do_ use it. Without fission, we don't have dynamic
visible area changes, but with the incoming patches we will.
Differential Revision: https://phabricator.services.mozilla.com/D116923
