Here we add a new UserFontLoadState value, STATUS_LOAD_PENDING, which
represents the state just after a gfxUserFontEntry's url()-valued source
would being loading, except that we can't start the load due to being
on a Servo style worker thread. In that case, we defer the work of
initiating the load until just after the Servo traversal is finished.
URLs that can normally be loaded synchronously, such as data: URLs
and script-implemented protocols marked as synchronous, must be
handled asynchronously when encountered during Servo traversal, since
various main-thread only work (in FontFaceSet::SyncLoadFontData) must
happen. This is a user visible change from stock Gecko, but should
only happen when font metrics for a data: URL font are requested
due to ch/ex unit resolution when layout hasn't previously requested
the font load. Hopefully nobody relies on synchronous resolution of
ch/ex units with data: URLs.
We unfortunately also can't pick gfxUserFontEntry objects out of the
UserFontCache during Servo traversal, since validating the cache
entry involves doing content policy checking, which is not thread-safe
(due in part to taking strong references to nsIPrincipals).
Platform fonts and ArrayBuffer-backed DOM FontFace objects continue
to be handled synchronously.
The PostTraversalTask does not take a strong reference to the
gfxUserFontEntry object, since it is held on to by the DOM FontFace
object, which itself won't go away before the PostTraversalTask
is run.
MozReview-Commit-ID: J9ODLsusrNV
--HG--
extra : rebase_source : d3e3d1dc187cb252750b57bcecd0b1ed77a15a7c
Here we add a new UserFontLoadState value, STATUS_LOAD_PENDING, which
represents the state just after a gfxUserFontEntry's url()-valued source
would being loading, except that we can't start the load due to being
on a Servo style worker thread. In that case, we defer the work of
initiating the load until just after the Servo traversal is finished.
URLs that can normally be loaded synchronously, such as data: URLs
and script-implemented protocols marked as synchronous, must be
handled asynchronously when encountered during Servo traversal, since
various main-thread only work (in FontFaceSet::SyncLoadFontData) must
happen. This is a user visible change from stock Gecko, but should
only happen when font metrics for a data: URL font are requested
due to ch/ex unit resolution when layout hasn't previously requested
the font load. Hopefully nobody relies on synchronous resolution of
ch/ex units with data: URLs.
We unfortunately also can't pick gfxUserFontEntry objects out of the
UserFontCache during Servo traversal, since validating the cache
entry involves doing content policy checking, which is not thread-safe
(due in part to taking strong references to nsIPrincipals).
Platform fonts and ArrayBuffer-backed DOM FontFace objects continue
to be handled synchronously.
The PostTraversalTask does not take a strong reference to the
gfxUserFontEntry object, since it is held on to by the DOM FontFace
object, which itself won't go away before the PostTraversalTask
is run.
MozReview-Commit-ID: J9ODLsusrNV
--HG--
extra : rebase_source : 1651e2917bd31b87fc1c1be94b0eced1273df86a
The cleanup work includes:
part 1: make all methods 'const' for the abstract class of PropertyProvider.
part 2: make nsFontMetrics's StubPropertyProvider final.
part 3: make nsTextFrame's PropertyProvider final.
Make some methods 'const' and some variables 'mutable', so we could let all the
overridden methods stay const.
We also need to make the pass-in parameter of gfxFontGroup's GetHyphenWidth const.
Note that the comment of GetHyphenWidth seem outdated, so I fixed it as well.
part 4: make the member variables in nsTextFrame's PropertyProvider to be 'const'.
Make all the member variables 'const' except mStart, mLength,
mJustificationArrayStart, and mJustificationSpacings.
The static function AdvanceToNextTab is fixed since we only use 2 of the 4 parameters.
part 5: coding style fix for nsTextFrame's PropertyProvider.
MozReview-Commit-ID: 1kbWPwx27aQ
Trim trailing whitespaces for files that are touched in this bug:
gfxTextRun.h
gfxTextRun.cpp
nsTextFrame.cpp
nsCSSProps.cpp
MozReview-Commit-ID: FmiW2QiCoFv
--HG--
extra : rebase_source : cbc9ae8c3c4410d1fe79c027d4ccf11b45c8bd19
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853