It can fail when canceling the worker (though I couldn't reproduce the
crash locally). Some things were already accounting for it.
Rename some things for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D175126
FontFaceSet and FontFaceSetImpl maintain independent but matching lists
of FontFace and FontFaceImpl objects respectively. When
FontFaceSet::Delete is called, we should remove from the FontFaceSet
first instead of the FontFaceSetImpl because FontFaceSetImpl::Delete
calls back into FontFaceSet to update its status if the removed FontFace
was the last object holding it back from a status change.
Differential Revision: https://phabricator.services.mozilla.com/D159857
This patch splits document specific functionality from FontFaceSetImpl
into a new class FontFaceSetDocumentImpl. This will make it easier to
fork FontFaceSetImpl for workers.
Differential Revision: https://phabricator.services.mozilla.com/D147819
This patch aims to split the implementation details of FontFace(Set)
into FontFace(Set)Impl classes. The Impl variants have threadsafe
refcounting and are intended to be the basis for worker support for
FontFace(Set). We need threadsafe objects to pass around because parts
of the stack can only run on the main thread (network loading of font
data, graphics initialization of a font) even if the FontFace(Set)
itself lives on a DOM worker thread. Given the DOM facing objects are
cycle collected, we need additional indirection to support this use
case.
This patch should be a non-functional change.
Differential Revision: https://phabricator.services.mozilla.com/D147505
This patch splits document specific functionality from FontFaceSetImpl
into a new class FontFaceSetDocumentImpl. This will make it easier to
fork FontFaceSetImpl for workers.
Differential Revision: https://phabricator.services.mozilla.com/D147819
This patch aims to split the implementation details of FontFace(Set)
into FontFace(Set)Impl classes. The Impl variants have threadsafe
refcounting and are intended to be the basis for worker support for
FontFace(Set). We need threadsafe objects to pass around because parts
of the stack can only run on the main thread (network loading of font
data, graphics initialization of a font) even if the FontFace(Set)
itself lives on a DOM worker thread. Given the DOM facing objects are
cycle collected, we need additional indirection to support this use
case.
This patch should be a non-functional change.
Differential Revision: https://phabricator.services.mozilla.com/D147505
This patch splits document specific functionality from FontFaceSetImpl
into a new class FontFaceSetDocumentImpl. This will make it easier to
fork FontFaceSetImpl for workers.
Differential Revision: https://phabricator.services.mozilla.com/D147819
This patch aims to split the implementation details of FontFace(Set)
into FontFace(Set)Impl classes. The Impl variants have threadsafe
refcounting and are intended to be the basis for worker support for
FontFace(Set). We need threadsafe objects to pass around because parts
of the stack can only run on the main thread (network loading of font
data, graphics initialization of a font) even if the FontFace(Set)
itself lives on a DOM worker thread. Given the DOM facing objects are
cycle collected, we need additional indirection to support this use
case.
This patch should be a non-functional change.
Differential Revision: https://phabricator.services.mozilla.com/D147505
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
Callers that use the family's list of fonts need to hold a read lock for as
long as they're accessing the list.
Alternatively, the work can be moved into a gfxFontFamily method that locks
internally.
Differential Revision: https://phabricator.services.mozilla.com/D145924
No functional change, this just makes it more explicit that each possible status
value is being considered, and unifies the handling of the two arrays.
Differential Revision: https://phabricator.services.mozilla.com/D118200
This changes font-family storage to reuse the rust types, removing a
bunch of code while at it. This allows us to, for example, use a single
static font family for -moz-bullet and clone it, rather than creating a
lot of expensive copies.
Differential Revision: https://phabricator.services.mozilla.com/D118011
As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
Per https://github.com/w3c/csswg-drafts/issues/6126 these were
never intended to be included in the first place so this is just
fixing a bug. Note that I'm leaving them in the mRuleFaces array
so that the font loading machinery works the same as before.
I'm just excluding them when queried by document.fonts.
Differential Revision: https://phabricator.services.mozilla.com/D111694
As for document.fonts, I don't think we intentionally meant to apply
CSP to User/UserAgent fonts. The document certainly has no authority
to block those from loading. (We already have a separate principal
for these which is further evidence that this was unintentional
and we can use the same bit (mUseOriginPrincipal) to avoid CSP.)
Differential Revision: https://phabricator.services.mozilla.com/D111695
Per https://github.com/w3c/csswg-drafts/issues/6126 these were
never intended to be included in the first place so this is just
fixing a bug. Note that I'm leaving them in the mRuleFaces array
so that the font loading machinery works the same as before.
I'm just excluding them when queried by document.fonts.
Differential Revision: https://phabricator.services.mozilla.com/D111694
This is a preliminary step that is needed in order for the following patch to be safe. (It's
mostly just plumbing, although the patch looks big because we need to pass the index through
so many functions.)
The issue is that loading a font resource involves a couple of tasks that happen asynchronously -
fetching the data from the network, and decoding/sanitizing the font data. We have an implicit
assumption that once a font load has been initiated, the state of the associated gfxUserFontEntry
will not change; in particular, we depend on mSrcIndex remaining constant, because we may use it
to index into the mSrcList array and access the gfxFontFaceSrc record again in the various
completion tasks that are executed after the async steps finish.
But the following patch breaks this assumption, because it may reset mSrcIndex at arbitrary times
when we discover that we need to re-resolve the @font-face to potentially recognize a src:local()
resource that was earlier in the list, but was previously unavailable. If this happens while
a font-load is doing its off-main-thread work, then when it completes, it will end up accessing
the wrong gfxFontFaceSrc record, which would result at least in incorrect behavior, but can also
result in a crash (e.g. if the record is of the wrong type altogether, such as trying to use the
principal or URI fields from a record of type src:local).
To avoid this problem, we should pass the source index at the time the font load is initiated
through to the OMT tasks and back to their main-thread completion routines, so that we do not
depend on the field in the gfxUserFontEntry remaining frozen. This makes the loading process
safe even if the source index in the entry gets reset while loading tasks are in progress.
Differential Revision: https://phabricator.services.mozilla.com/D110911
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
GetValue is going to be removed in a subsequent patch. It is no longer needed,
because it can be replaced by functions already provided by nsBaseHashtable,
in particular Lookup and Contains.
Also, its name was confusing, since it specifically returns a pointer that
allows and is intended for modifying the entry within the hashtable, rather
than returning by-value. According to the naming rules to be set on
nsBaseHashtable, it would also needed to be renamed to "Lookup*. Removing
its uses saves this effort.
Differential Revision: https://phabricator.services.mozilla.com/D105476
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
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
