This moves the style-specific bits of the shared style sheet cache into
a super-class, and leaves the generic "sub-resource management" bits
inside a base class. In order to implement it you need to provide some
types, mainly:
* Loader, which implements LoaderPrincipal() and allows you to key per
principal. The idea is that this would be the
{CSS,Script,Image}Loader object.
* Key (self explanatory). We might want to introduce a common key to
share the cache partitioning logic.
* Value, which represents the final cached value. This is expected to
be a StyleSheet / Stencil / imgRequestProxy.
* LoadingValue, which must inherit from
SharedSubResourceCacheLoadingValueBase (which contains the linked
list and the state that the cache manages). It also must provide a
ValueForCache() and ExpirationTime() members. For style, this is the
SheetLoadData. For script this will probably be the
ScriptLoadRequest. For images it might be enough with the
imgRequestProxy, but we might need something else, haven't looked
into it too deeply yet.
We move the use counters into the stylesheet since that's both more
similar to how we treat StyleSheetContents and easier (that way we don't
need to add some sort of "extra data" thing to the cache).
Differential Revision: https://phabricator.services.mozilla.com/D124820
Unsuppressing is done only if the page can use stylesheet cache. That should mean the
load isn't a cold load and also some other resources may be cached and thus
painting could happen sooner.
There is currently a regression around dom.ipc.processCount.webIsolated handling, but the
testing has been done with dom.ipc.processCount.webIsolated==1, and the patch for bug 1731792
should give back similar behavior as what process count 1 has.
Differential Revision: https://phabricator.services.mozilla.com/D125878
With a very simple tweak to SheetLoadDataHashKey::KeyEquals we should
get the same kind of caching but in a much simpler way.
Depends on D125450
Differential Revision: https://phabricator.services.mozilla.com/D124807
This fixes a leak that my previous patch uncovers. See comment 9 for the
diagnostic, I had missed mRequestingNode in comment 10.
The observer change is not technically necessary but since observers can
theoretically keep alive random stuff as well, clean them up as well.
In particular, clear mOwningNode after we've fired load / error events
(which is what we need it for), and mRequestingNode once we call
LoadComplete, where it is no longer useful.
Differential Revision: https://phabricator.services.mozilla.com/D125450
With a very simple tweak to SheetLoadDataHashKey::KeyEquals we should
get the same kind of caching but in a much simpler way.
Differential Revision: https://phabricator.services.mozilla.com/D124807
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
Instead, fix up the various content data structures when the stylesheet
is mutated. This makes reading a stylesheet not disable style sharing.
Differential Revision: https://phabricator.services.mozilla.com/D115203
Previously, the DocGroup type was not cycle-collected, as it needed to have
references from other threads for Quantum DOM. Nowadays the only off-main-thread
use of DocGroup is for dispatching runnables to the main thread which should be
tracked using a performance counter for about:performance. This means we can
remove the DocGroup references from these dispatching callsites, only storing
the Performance Counter we're interested in, and simplify make DocGroup be
cycle-collected itself.
This fixes a leak caused by adding the WindowGlobalChild getter to
WindowContext, by allowing cycles between the document and its BrowsingContext
to be broken by the cycle-collector.
Differential Revision: https://phabricator.services.mozilla.com/D108865
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
This is an issue I found while going through this code and
writing/debugging a test for the bug at hand. Without this, the test in
the actual fix for this bug will fail to actually reuse the preloaded
stylesheet.
It seems reasonable to assume that the intersection of quirks mode
documents using link preload headers is small (and in that case we'd
parse the sheet twice, but oh well).
Differential Revision: https://phabricator.services.mozilla.com/D103567
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
This matches other browsers, and common sense to some extent.
The code is a bit awkward because I want this behind a pref for now, as
it's not precisely a zero-risk change.
Differential Revision: https://phabricator.services.mozilla.com/D95065
This matches other browsers, and common sense to some extent.
The code is a bit awkward because I want this behind a pref for now, as
it's not precisely a zero-risk change.
Differential Revision: https://phabricator.services.mozilla.com/D95065
This matches other browsers, and common sense to some extent.
The code is a bit awkward because I want this behind a pref for now, as
it's not precisely a zero-risk change.
Differential Revision: https://phabricator.services.mozilla.com/D95065
And fix the only WPT for this while at it which was using the wrong URL
(and thus would always pass).
This actually makes me a bit uncomfortable given the amount of times
I've seen the pattern:
<link href="important.css" rel="preload" as="style" onload="this.rel = 'stylesheet'">
As that means that important.css won't block the load event. But let's
try.
Differential Revision: https://phabricator.services.mozilla.com/D86049
Consider the case where we have an expired entry in the cache, and we
load a new document.
We get an speculative load from the HTML parser. That's great, and we
see the entry is expired and actually fired the load.
But then, we actually get to the load that the <link> element performs,
and we see that we've already performed this load, so instead of peeking
the in-progress load, we go ahead and peek the expired "complete" cache
entry, which is not what we want.
By marking a load as performed only once it has finished, we avoid the
complete sheet cache, and glom onto the existing load instead, which is
the correct thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D81318
Consider the case where we have an expired entry in the cache, and we
load a new document.
We get an speculative load from the HTML parser. That's great, and we
see the entry is expired and actually fired the load.
But then, we actually get to the load that the <link> element performs,
and we see that we've already performed this load, so instead of peeking
the in-progress load, we go ahead and peek the expired "complete" cache
entry, which is not what we want.
By marking a load as performed only once it has finished, we avoid the
complete sheet cache, and glom onto the existing load instead, which is
the correct thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D81318
When we call into LoadSheet when starting pending loads for a given
loader, it may be the case that the original loader may still not care
about the load. However some other loader will, so we can't defer this.
This was also causing our state to get out of sync, because if this
happened, then we'd fail to account for it in other loaders.
Differential Revision: https://phabricator.services.mozilla.com/D81119
If two loading documents hit the sheet cache and we coalesce the
resource load, there's nothing that prevents the load event on the
second document from firing right now, and there should be.
While at it, also fix the handling of the pending load count, though
it has no correctness impact on the particular test we're fixing here...
We were never decrementing it, which is of course wrong. However it
kinda ended up working because it just causes us to not defer more
loads.
The new assertions and responsibility of the counter should ensure it
stays correct.
Differential Revision: https://phabricator.services.mozilla.com/D80583
So as to make sense in a world where we can coalesce loads across
documents. The per-load object is the SheetLoadData, so this way we
guarantee that we fire the right events in presence of the load
coalescing that the SharedStyleSheetCache does.
Differential Revision: https://phabricator.services.mozilla.com/D80380
This shouldn't have any behavior change, but it makes the code make a
bit more sense. Rather than counting inline stylesheets like a pending
load, we won't (but note that any @import inside it will).
The SheetLoadData::mURL it's supposed to be the url of the stylesheet,
so for StyleSheet::Replace it should be null.
Differential Revision: https://phabricator.services.mozilla.com/D80379
This makes it easy to see why your test is not failing without your
patch, for example ;)
Note that we log only when the URIs are the same, which
I think is a reasonable compromise in verbosity.
Differential Revision: https://phabricator.services.mozilla.com/D80288
