nsPresContest::RegisterManagedPostRefreshObserver still lets us add a managed post refresh observer until the mPresShell pointer on the prescontent is nulled out. That means that between the call to CancelManagedPostRefreshObservers and mPresContext->DetachPresShell() (which nulls out the mPresShell pointer on the prescontext) in PresShell::Destroy we can add a managed post refresh observer that will never get removed. Notably, destroying the frame tree happens between these two calls.
So move the CancelManagedPostRefreshObservers call to happen right after we null out the mPresShell pointer on the prescontext.
In bug 1737503 I want to add a managed post refresh observer when we destroy a subdocument frame (it's only interested in the recreate frames case not the destruction case, but not an easy way to tell them apart afaik), so it triggers this bug. The patch and test I have for that bug exercise this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D135340
I guess we need to do this every time we get a new APZC tree manager (because that is where the zoom constraints map/cache is stored). I'm not sure how to detect that or if there are other cases we haven't covered.
Differential Revision: https://phabricator.services.mozilla.com/D113608
It's only meaningfully read in two places:
* WebRender fallback code.
* Some widget DEBUG-only code, which on Linux is ifdef'd and on Windows does
some rather sketchy things like sleeping for 30ms
So I think it should be ok to remove, since WR fallback has its own flashing
pref as well, IIUC.
Differential Revision: https://phabricator.services.mozilla.com/D132313
It might fire before styles are invalidated, so it might cache the wrong
styles.
Instead, fire an event on the window once everything in that window has
been invalidated, not just the global theme.
This is causing failures with the patch in bug 1740089, since after that
patch `browser_ext_browserAction_theme_icons` trigger the theme changes
when switching from dark to default mode or similar.
Differential Revision: https://phabricator.services.mozilla.com/D131396
Similar to the previous patch, there are a lot of QI from `EventTarget` to
window interfaces. This patch adds them, but unfortunately,
`nsPIDOMWindowInner` and `nsPIDOMWindowOuter` do not inherit `EventTarget`
directly, and they are in a public header instead of their concrete classes
(`nsGlobalWindowInner` and `nsGlobalWindowOuter`). So we cannot cast them
in `nsPIDOMWindow.h`, and it causes it's impossible to use the macros added
by the previous patch.
Differential Revision: https://phabricator.services.mozilla.com/D129782
Currently, checking whether an `EventTarget` is `nsINode` (or its concrete
classes) or not requires a QI, but it's expensive and used a lot while we
handle each event. Therefore, it'd be nicer for creating a virtual method,
`EventTarget::IsNode()` and use it for the check.
If trying to convert `EventTarget` to a concrete class, it may require two
virtual method calls. I'm not sure whether it's cheaper than a QI, but at
least, it won't depend on the UUID check order of `QueryInterface()` when
multiple interfaces are implemented.
Differential Revision: https://phabricator.services.mozilla.com/D129781
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
