It's a 1:1 mapping for the origin that we cache in the
StyleSheetContents, so use that.
PreloadHashKey only cares about author loads, within a document, so
doesn't really need to deal with user / user-agent ones.
Differential Revision: https://phabricator.services.mozilla.com/D304400
MakeAndAddRef exists partly to serve as syntactic sugar to combine statements
like this. And this lets us reduce our count of manual 'new' statements,
which is a nice plus.
One exception was "new StyleSheet" which has a private constructor and hence
can't use MakeAndAddRef, so in that instance I used do_AddRef(new) to stuff the
newly-allocated object into a smart pointer, in a way that we can consistently
grep for across the codebase when auditing our new/delete invocations.
Differential Revision: https://phabricator.services.mozilla.com/D298473
This was added for bug 1632686, in order to be able to create a promise
for constructable and non-constructable stylesheets. However:
* Constructable stylesheets always have access to their relevant global
via mConstructorDocument.
* Non-constructable stylesheets don't really need to create a promise
directly, they can throw and WebIDL will do the right thing turning
the exception into a promise.
So we can probably just kill this at this point. Note that we have some
relevant tests for the edge cases here
(layout/style/test/test_sheet_privilege.html).
This helps preventing window leaks during shutdown if there's an ongoing
stylesheet parse off the main thread, e.g., if a test opens a page that
closes before the load event is done, and the parse takes a bit, the
harness may think the window has leaked. It's _not_ a real leak, because
eventually the parse will finish and the stylesheet will get dropped,
but it shows up enough to be annoying, and the fix is simple.
Note that this would change behavior (via StyleSheet::GetParentObject)
if we allowed you to get a hand on a stylesheet that is not connected to
any node or constructed. However I don't think that's possible (we
require the sheet to be complete and the ways we expose stylesheets is
either LinkStyle.sheet or constructable stylesheets).
Differential Revision: https://phabricator.services.mozilla.com/D297517
The list of shared sheets is not order-dependent, neither is the
StyleSet set, so in order to avoid pathological performance with lots of
shared sheets, use unordered removal.
Differential Revision: https://phabricator.services.mozilla.com/D274597
We don't need it:
* For built-in sheets (ContentParent etc) the original URI is the same.
* For Document / nsStyleSheetService / LinkStyle, the original URI is
what you want to avoid registering / loading the same URI multiple
times.
Differential Revision: https://phabricator.services.mozilla.com/D269423
Make SetURIs be the source of truth for referrer info and principal too.
This allows us to remove redundant members.
Pull the URI and such out of StyleSheetInfo, since we are sharing
StyleSheetInfo across stylesheets with different base URIs and such now
(for inline stylesheets), and we need to keep track of the "right" base
URI for when we eventually clone them.
There's one part of the change here which is a bit scary, which is the
principal shenanigans. However I don't think it's problematic since we
already are using the URLExtraData for CSS parsing and subresource
loads, which doesn't have that mutation. In particular, we only use
StyleSheet::Principal from Loader::LoadChildSheet. So we can implement
what the spec actually says (an origin-clean flag).
Differential Revision: https://phabricator.services.mozilla.com/D269210
Make SetURIs be the source of truth for referrer info and principal too.
This allows us to remove redundant members.
Pull the URI and such out of StyleSheetInfo, since we are sharing
StyleSheetInfo across stylesheets with different base URIs and such now
(for inline stylesheets), and we need to keep track of the "right" base
URI for when we eventually clone them.
There's one part of the change here which is a bit scary, which is the
principal shenanigans. However I don't think it's problematic since we
already are using the URLExtraData for CSS parsing and subresource
loads, which doesn't have that mutation. In particular, we only use
StyleSheet::Principal from Loader::LoadChildSheet. So we can implement
what the spec actually says (an origin-clean flag).
Differential Revision: https://phabricator.services.mozilla.com/D269210
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
This breaks out the common code path between creating a CSSStyleSheet
instance directly and creating one from a CSS module into a separate
method so it can be used from both places.
Differential Revision: https://phabricator.services.mozilla.com/D263413
This breaks out the common code path between creating a CSSStyleSheet
instance directly and creating one from a CSS module into a separate
method so it can be used from both places.
Differential Revision: https://phabricator.services.mozilla.com/D263413
This breaks out the common code path between creating a CSSStyleSheet
instance directly and creating one from a CSS module into a separate
method so it can be used from both places.
Differential Revision: https://phabricator.services.mozilla.com/D263413
No behavior change, but this is simpler. I want to reuse the use
counters mechanism to fix this bug because it's a very trivial way of
asking questions about the parsed data and we need to plumb it through
the same places.
Differential Revision: https://phabricator.services.mozilla.com/D258290
The raw declaration block might change for a given rule. We need to keep
track of it properly for devtools in order to not lose track of rules.
Could I convince someone from DevTools to write a test for this? :)
Otherwise please point me to the right test to extend / change, and I
can.
Differential Revision: https://phabricator.services.mozilla.com/D230439
When there's trailing garbage after an @import rule we throw, but we
still trigger the load (that's not great but not trivial to change).
Deal with that case before calling ImportRuleLoaded().
Differential Revision: https://phabricator.services.mozilla.com/D219783
ReplaceSync did this, but if you don't call Replace() / ReplaceSync()
after construction we end up with the Servo_StyleSheet_Empty which has a
dummy URL data.
Differential Revision: https://phabricator.services.mozilla.com/D204603
Emilio Cobos Álvarez