Make promise resolution async, and a lot of the FontFaceSetImpl stuff
doesn't make sense anymore because FontFaceSetImpl _is_ thread-safe.
Differential Revision: https://phabricator.services.mozilla.com/D289918
They share some of that code already various lookup stuff in nsCSSProps and so
on. This reuses a very similar approach for these two.
Differential Revision: https://phabricator.services.mozilla.com/D286731
Fix a quoting issue that is exposed by japanese-tag.html
The quoting issue got introduced by bug 1986533 which converted this
code to work on UTF-8 strings rather than utf-16.
Differential Revision: https://phabricator.services.mozilla.com/D271850
In local testing, this reduces time spent under FontFaceImpl::GetUnicodeRangeAsCharacterMap
by around 20-25% for the testcase here, by reducing array reallocations while the bitset
is being populated.
(The following patch makes this redundant for the common case when unicode-range is absent,
but this will still benefit cases with a large but not-universal unicode-range descriptor.)
Differential Revision: https://phabricator.services.mozilla.com/D272044
With this patch, something like:
let ff = new FontFace("content:Segoe", "https://foo.com");
ff.load();
Generates an exception like:
> Uncaught (in promise) DOMException: Invalid font descriptor font-family: content:Segoe
Rather than the error in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D265127
When deep-cloning a stylesheet (like we do for devtools), we end up with
new (identical) LockedFontFaceRule object, but we'd fail to re-use it,
triggering new font loads. Since we don't cache failed loads, this
caused flashing and a temporary state where the used fonts were not what
this DevTools test expects.
Rejigger the code a little bit to push down the decision of whether to
reuse the FontFaceImpl object further down. That allows us to reuse the
FontFace object for the stylesheet caching / deep cloning use-case.
Differential Revision: https://phabricator.services.mozilla.com/D247704
We check that we can cc and kill the global object on shutdown.
At this point it doesn't really matter that the FontFace is still
loading, the promise will never resolve.
To fix this, implement the "keep alive" by using a target shutdown task.
Differential Revision: https://phabricator.services.mozilla.com/D214741
Otherwise we might never resolve the loaded promise.
This was the simplest / most obvious place to put the code, but let me
know if you can think of something better...
Ideally the nsFontFaceLoader would keep alive the RefPtr<FontFace>
objects as needed, but that's not really easy, because we can have the
same UserFontSet entry for fonts in different threads, AIUI, and
FontFace itself isn't movable across threads, so... This should be a
safe place to do this.
Differential Revision: https://phabricator.services.mozilla.com/D211625
Otherwise we might never resolve the loaded promise.
This was the simplest / most obvious place to put the code, but let me
know if you can think of something better...
Ideally the nsFontFaceLoader would keep alive the RefPtr<FontFace>
objects as needed, but that's not really easy, because we can have the
same UserFontSet entry for fonts in different threads, AIUI, and
FontFace itself isn't movable across threads, so... This should be a
safe place to do this.
Differential Revision: https://phabricator.services.mozilla.com/D211625
This should fix the intermittently-reported race here, by ensuring that access into
the FontFaceImpl from GetUserFontSets(), called by the main thread, cannot race with
changes being made by the AddFontSet()/RemoveFontSet() methods.
(If the FontFaceImpl doesn't have an mUserFontEntry yet, then these methods don't
need to lock, as only the owning thread will be touching it.)
Differential Revision: https://phabricator.services.mozilla.com/D207296
No functional change here, just cleanup in preparation for the following patch.
We don't need FontFaceImpl to create a mutex, as there's already a lock (RWLock)
in its base class gfxFontEntry, and we can use that to guard the fields here.
Differential Revision: https://phabricator.services.mozilla.com/D207295
FontFaceSetWorkerImpl::GetURLExtraData should generally not return a
null pointer, but if it failed to initialize because the worker was
shutdown during FontFaceSetWorkerImpl initialization, then it may never
be created. This patch ensures we check for this race and handle it
appropriately.
Differential Revision: https://phabricator.services.mozilla.com/D161476
This patch merges FontFaceSetImpl and gfxUserFontSet into the same
class. This reduces the level of indirection and in theory makes it
easier to manage future threading issues.
Differential Revision: https://phabricator.services.mozilla.com/D147817
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 merges FontFaceSetImpl and gfxUserFontSet into the same
class. This reduces the level of indirection and in theory makes it
easier to manage future threading issues.
Differential Revision: https://phabricator.services.mozilla.com/D147817
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
Emilio Cobos Álvarez