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 is mostly just changing `new Foo()` to `MakeRefPtr<Foo>()`.
Notablye exceptions:
* In one case where the result gets stuck in a `nsCOMPtr` instead of a `RefPtr`,
I use `MakeAndAddRef` instead, to follow precedent from elsewhere in the
codebase (and avoid the appearance of a pointer-type-mixup).
* In cases where the class has a private constructor, we can't use MakeRefPtr,
so I use `do_AddRef(new Foo())` to make it slightly clearer (in an easily
greppable way) that the 'new' invocation is instantly being stuffed into
a smart pointer.
Differential Revision: https://phabricator.services.mozilla.com/D298475
The network predictor used the HTTP cache as a database to learn browsing
patterns and make speculative DNS prefetches, TCP preconnects, and resource
prefetches. While this provided performance benefits for repeat visits to
frequently-accessed sites, it came with significant costs: I/O on every page
load, CPU overhead for prediction algorithms, memory for caching learned
patterns, and substantial IPC complexity with six message types coordinating
predictions between processes.
A large part of the functionality the predictor was meant to improve is now
available to webdevelopers. HTTP 103 Early Hints allow servers to explicitly
specify resources to preload while generating the response.
And Speculation Rules API will enable content authors to declaratively specify
prefetch/prerender behavior based on their knowledge of site structure and user
intent, providing immediate accuracy without a learning period.
The network.predictor.enable-hover-on-ssl preference is retained as it controls
simpler hover-triggered speculative connections that don't require the
predictor's learning system. This removal simplifies the codebase while
steering users toward more accurate, standards-based optimization mechanisms.
The one feature of the predictor which was never used was learning websites
that are opened soon after startup. There was no action taken based on this
info, and we could already predict this info based on the history database.
Differential Revision: https://phabricator.services.mozilla.com/D276437
The network predictor used the HTTP cache as a database to learn browsing
patterns and make speculative DNS prefetches, TCP preconnects, and resource
prefetches. While this provided performance benefits for repeat visits to
frequently-accessed sites, it came with significant costs: I/O on every page
load, CPU overhead for prediction algorithms, memory for caching learned
patterns, and substantial IPC complexity with six message types coordinating
predictions between processes.
A large part of the functionality the predictor was meant to improve is now
available to webdevelopers. HTTP 103 Early Hints allow servers to explicitly
specify resources to preload while generating the response.
And Speculation Rules API will enable content authors to declaratively specify
prefetch/prerender behavior based on their knowledge of site structure and user
intent, providing immediate accuracy without a learning period.
The network.predictor.enable-hover-on-ssl preference is retained as it controls
simpler hover-triggered speculative connections that don't require the
predictor's learning system. This removal simplifies the codebase while
steering users toward more accurate, standards-based optimization mechanisms.
The one feature of the predictor which was never used was learning websites
that are opened soon after startup. There was no action taken based on this
info, and we could already predict this info based on the history database.
Differential Revision: https://phabricator.services.mozilla.com/D276437
This patch doesn't change behavior; it just does a single preallocation to
avoid wasting time on repeated allocations (and allocation-failure-checks) as
we incrementally append to an array.
Differential Revision: https://phabricator.services.mozilla.com/D250115
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
Daniel Holbert