We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression).
We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though).
We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port.
In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch.
My audit found that all of the places we set a display port want to clear the minimal display port property except:
-UpdateSub/RootFrame in APZCCallbackHelper
-UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils
UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases:
-a scroll info layer
-a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call)
-a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them.
It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare).
Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports.
Differential Revision: https://phabricator.services.mozilla.com/D103855
The existing `append` option allows to accumulate logs. The `rotate:N`
option added in Bug 1244306 allows to limit the growth of the log, but
it's both incompatible with `append` and not well suited for a single
cumulative historical log across multiple runs, since it's unclear how
to manage the current log file index across invocations. Continuously
limiting the file size for each log message is technically
challenging.
This commit pursues a much simpler approach. When `maxsize:N` is
specified with `append`, before a log file is opened, it "tails" the
file to be at most N // 2 bytes long. It tries to keep lines intact
at low runtime memory cost, but allows very long lines may be cut.
This implementation wants an atomic file rename operation, which is
supported on Win32 and POSIX OSes only at this time. On other OSes, a
compile time error will be raised.
Differential Revision: https://phabricator.services.mozilla.com/D103405
Previously if `Clone()` was called on a closed nsPipeInputStream, it could cause
crashes due to the already-closed nsPipeInputStream being added to mInputList,
violating internal nsPipe invariants. Skipping adding the stream to that list
should avoid this edge-case, as the pipe is already closed.
Differential Revision: https://phabricator.services.mozilla.com/D101807
This patch introduces a new SeekableStreamWrapper class which handles adapting
nsIInputStreams which support being cheaply cloned using nsICloneableInputStream
into seekable input streams by operating on a clone of the original stream, and
re-cloning that stream when seeking backwards.
This wrapper is generally intended to be used with nsPipeInputStream as that
type supports both a fairly cheap clone operation, and keeping a large internal
buffer which is fairly cheap to seek using this method, but should also work
with other types such as RemoteLazyInputStream or nsStringStream.
An alternate strategy was considered where nsPipe was given internal support for
a mSeekable flag to be set on creation. This flag would then have a similar
effect, except with additional optimizations due to being visible within the
implementation of the nsPipe, rather than relying on an unadvanced
nsPipeInputStream to keep the buffer alive.
I ended up choosing this approach instead for a few reasons:
* The seekable adapter can be applied to an already-created nsPipeInputStream,
such as one received from IPC. With the nsPipe approach, making an IPC stream
seekable either requires telling IPCStreamDestination to use a seekable pipe
ahead of time, or performing a NS_AsyncCopy from the IPC-provided pipe into a
different seekable pipe, which is likely wasted effort and would prevent
optimizations such as RemoteLazyInputStream and DelayedStart streams.
* The adapter can support other features of the underlying stream, such as
nsIInputStreamLength, without resorting to adding additional adapter layers
on top of the returned nsPipe.
* The performance is unlikely to be substantially different in the most common
case, which is using Seek(NS_SEEK_SET, 0) to return to the beginning of the
stream.
* Less additional complexity is added to the already-complicated internals of
nsPipe, and instead it is kept in a separate wrapper stream, which is easier
to review.
Using nsStorageStream, as is used by EnsureUploadStreamIsCloneable, was also
considered, but was rejected as it has similar problems to the seekable nsPipe
approach and also doesn't implement nsIAsyncStream, meaning that one must wait
for the NS_AsyncCopy to be completed before reading the stream.
It may actually be possible to replace the existing uses of nsStorageStream with
a wrapped nsPipe in the future, but that is left as follow-up material, and may
have memory overhead implications due to nsPipe not resizing the final segment,
unlike nsStorageStream.
Differential Revision: https://phabricator.services.mozilla.com/D101805
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Loads targeting cross-process BrowsingContexts are by definition cross-origin,
which should preclude any javascript: loads. While those loads are currently
prevented by principal checks in the final target process, sending IPC
messages for the attempts is unnecessary, and potentially opens a door to
privilege escalation exploits by a compromised content process.
This patch prevents any cross-process load requests from being sent by content
processes, and adds checks in the parent process to kill any (potentially
compromised) content process which attempts to send them.
Differential Revision: https://phabricator.services.mozilla.com/D103529
Previously if `Clone()` was called on a closed nsPipeInputStream, it could cause
crashes due to the already-closed nsPipeInputStream being added to mInputList,
violating internal nsPipe invariants. Skipping adding the stream to that list
should avoid this edge-case, as the pipe is already closed.
Differential Revision: https://phabricator.services.mozilla.com/D101807
This patch introduces a new SeekableStreamWrapper class which handles adapting
nsIInputStreams which support being cheaply cloned using nsICloneableInputStream
into seekable input streams by operating on a clone of the original stream, and
re-cloning that stream when seeking backwards.
This wrapper is generally intended to be used with nsPipeInputStream as that
type supports both a fairly cheap clone operation, and keeping a large internal
buffer which is fairly cheap to seek using this method, but should also work
with other types such as RemoteLazyInputStream or nsStringStream.
An alternate strategy was considered where nsPipe was given internal support for
a mSeekable flag to be set on creation. This flag would then have a similar
effect, except with additional optimizations due to being visible within the
implementation of the nsPipe, rather than relying on an unadvanced
nsPipeInputStream to keep the buffer alive.
I ended up choosing this approach instead for a few reasons:
* The seekable adapter can be applied to an already-created nsPipeInputStream,
such as one received from IPC. With the nsPipe approach, making an IPC stream
seekable either requires telling IPCStreamDestination to use a seekable pipe
ahead of time, or performing a NS_AsyncCopy from the IPC-provided pipe into a
different seekable pipe, which is likely wasted effort and would prevent
optimizations such as RemoteLazyInputStream and DelayedStart streams.
* The adapter can support other features of the underlying stream, such as
nsIInputStreamLength, without resorting to adding additional adapter layers
on top of the returned nsPipe.
* The performance is unlikely to be substantially different in the most common
case, which is using Seek(NS_SEEK_SET, 0) to return to the beginning of the
stream.
* Less additional complexity is added to the already-complicated internals of
nsPipe, and instead it is kept in a separate wrapper stream, which is easier
to review.
Using nsStorageStream, as is used by EnsureUploadStreamIsCloneable, was also
considered, but was rejected as it has similar problems to the seekable nsPipe
approach and also doesn't implement nsIAsyncStream, meaning that one must wait
for the NS_AsyncCopy to be completed before reading the stream.
It may actually be possible to replace the existing uses of nsStorageStream with
a wrapped nsPipe in the future, but that is left as follow-up material, and may
have memory overhead implications due to nsPipe not resizing the final segment,
unlike nsStorageStream.
Differential Revision: https://phabricator.services.mozilla.com/D101805
One thing we have to do when tracaing is udpate context information (e.g. edge name) if the tracer is a kind that requires it. It's simpler and more efficient to give all tracers this context and perform an unconditional write to the stack.
Mostly we can get away without saving/restoring context information too. This adds AutoClearTracingContext for the one place we need to do this because of nested use of the same tracer while tracing something else.
Differential Revision: https://phabricator.services.mozilla.com/D103500
Bug 608915 switched nsString::AppendFloat to double-conversion, while
handling trailing zero removal on its own. This can be made more
effectively when doing so in double-conversion itself, support for which
was merged upstream in https://github.com/google/double-conversion/pull/149.
This makes the used_exponential_notation outparam unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D102698
nsBaseHashtable now supports non-default-constructible DataType and
UserDataType, however not all methods can be instantiated. All methods which
can't be instantiated with non-default-constructible DataType or UserDataType
are now described as such in method definitions.
The public API of PLDHashTable and nsBaseHashtable/nsDataHashtable was changed:
- A new method PLDHashTable::WithEntryHandle has been added. It allows to use a
custom function for entry initialization (instead of the global hook).
- A new method nsBaseHashtable::MaybeGet has been added.
- A new overload nsBaseHashtable::Remove has been added.
- The nsDataHashtable::GetAndRemove method has been pulled up to
nsBaseHashtable.
In addition, the following implementation details have changed:
PLDHashTable:
- The code from the Add method has been split into MakeEntryHandle and a helper
object called EntryHandle. The Add method is now implemented on top of that.
nsTHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- The InitEntry hook is no longer used. Instead of using the hook, PutEntry
methods now use nsTHashtable::WithEntryHandle instead of PLDHashTable::Add.
This change allows to do custom initialization in derived classes.
nsBaseHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- Put methods no longer use nsTHashtable::PutEntry, they now use the new method
nsBaseHashtable::WithEntryHandle.
Differential Revision: https://phabricator.services.mozilla.com/D99428
nsBaseHashtable now supports non-default-constructible DataType and
UserDataType, however not all methods can be instantiated. All methods which
can't be instantiated with non-default-constructible DataType or UserDataType
are now described as such in method definitions.
The public API of PLDHashTable and nsBaseHashtable/nsDataHashtable was changed:
- A new method PLDHashTable::WithEntryHandle has been added. It allows to use a
custom function for entry initialization (instead of the global hook).
- A new method nsBaseHashtable::MaybeGet has been added.
- A new overload nsBaseHashtable::Remove has been added.
- The nsDataHashtable::GetAndRemove method has been pulled up to
nsBaseHashtable.
In addition, the following implementation details have changed:
PLDHashTable:
- The code from the Add method has been split into MakeEntryHandle and a helper
object called EntryHandle. The Add method is now implemented on top of that.
nsTHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- The InitEntry hook is no longer used. Instead of using the hook, PutEntry
methods now use nsTHashtable::WithEntryHandle instead of PLDHashTable::Add.
This change allows to do custom initialization in derived classes.
nsBaseHashtable:
- A new (non-public) API for WithEntryHandle has been added.
- Put methods no longer use nsTHashtable::PutEntry, they now use the new method
nsBaseHashtable::WithEntryHandle.
Differential Revision: https://phabricator.services.mozilla.com/D99428
This patch does several things:
- make the counter type int64_t like the work budget parameter (the original purpose of this bug)
- simplify implementation by using a Variant to discriminate between different kinds of budget
- remove the global initialization
- remove makeUnlimited() (and replace uses with assignment from SliceBudget::unlimited())
- add convenience methods to get the original budget parameters
- add basic API tests
The use of Variant had the consequence that we now have to pass SliceBudget by reference now to make the linter happy.
Differential Revision: https://phabricator.services.mozilla.com/D103318
Bug 608915 switched nsString::AppendFloat to double-conversion, while
handling trailing zero removal on its own. This can be made more
effectively when doing so in double-conversion itself, support for which
was merged upstream in https://github.com/google/double-conversion/pull/149.
This makes the used_exponential_notation outparam unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D102698
For simplicity, this implements just on in `NO_TASKS` (the default) or
on in `ALL_TASKS` (opt-in). This disables all category registrations
when in background task mode; we'll selectively re-enable things as
appropriate.
The flag constants were chosen to smoothly extend to a (16-)bit set in
the future, should we want to add a `JUST_TASKS("task", "other-task")`
option in the future.
This also adds ython tests for gen_static_components.py exercising
categories, simply 'cuz it's easiest to see what this adds in such
tests. Functional tests will follow in patches that actually
implement the new background tasks functionality.
Differential Revision: https://phabricator.services.mozilla.com/D96654
This allows to filter chrome manifest registration by the current
background task(s, in the future). Filtration behaves just like
filtering by "application":
* filter with `backgroundtask=` means disable for all background
tasks, since no background task will match ""
* filter with `backgroundtask!=` means enable for all background task,
since every background task will not match ""
Differential Revision: https://phabricator.services.mozilla.com/D96482
Previously if `Clone()` was called on a closed nsPipeInputStream, it could cause
crashes due to the already-closed nsPipeInputStream being added to mInputList,
violating internal nsPipe invariants. Skipping adding the stream to that list
should avoid this edge-case, as the pipe is already closed.
Differential Revision: https://phabricator.services.mozilla.com/D101807
This patch introduces a new SeekableStreamWrapper class which handles adapting
nsIInputStreams which support being cheaply cloned using nsICloneableInputStream
into seekable input streams by operating on a clone of the original stream, and
re-cloning that stream when seeking backwards.
This wrapper is generally intended to be used with nsPipeInputStream as that
type supports both a fairly cheap clone operation, and keeping a large internal
buffer which is fairly cheap to seek using this method, but should also work
with other types such as RemoteLazyInputStream or nsStringStream.
An alternate strategy was considered where nsPipe was given internal support for
a mSeekable flag to be set on creation. This flag would then have a similar
effect, except with additional optimizations due to being visible within the
implementation of the nsPipe, rather than relying on an unadvanced
nsPipeInputStream to keep the buffer alive.
I ended up choosing this approach instead for a few reasons:
* The seekable adapter can be applied to an already-created nsPipeInputStream,
such as one received from IPC. With the nsPipe approach, making an IPC stream
seekable either requires telling IPCStreamDestination to use a seekable pipe
ahead of time, or performing a NS_AsyncCopy from the IPC-provided pipe into a
different seekable pipe, which is likely wasted effort and would prevent
optimizations such as RemoteLazyInputStream and DelayedStart streams.
* The adapter can support other features of the underlying stream, such as
nsIInputStreamLength, without resorting to adding additional adapter layers
on top of the returned nsPipe.
* The performance is unlikely to be substantially different in the most common
case, which is using Seek(NS_SEEK_SET, 0) to return to the beginning of the
stream.
* Less additional complexity is added to the already-complicated internals of
nsPipe, and instead it is kept in a separate wrapper stream, which is easier
to review.
Using nsStorageStream, as is used by EnsureUploadStreamIsCloneable, was also
considered, but was rejected as it has similar problems to the seekable nsPipe
approach and also doesn't implement nsIAsyncStream, meaning that one must wait
for the NS_AsyncCopy to be completed before reading the stream.
It may actually be possible to replace the existing uses of nsStorageStream with
a wrapped nsPipe in the future, but that is left as follow-up material, and may
have memory overhead implications due to nsPipe not resizing the final segment,
unlike nsStorageStream.
Differential Revision: https://phabricator.services.mozilla.com/D101805
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
These lines are parsed by the `htmlparser` and are expected to be on a single
line. The `black` reformat has moved some of these definitions to multiple lines
due to line length. This commit moves all declarations back to a single line and
adds `fmt: {off,on}` statements so they will be ignored in future reformats.
Differential Revision: https://phabricator.services.mozilla.com/D102626
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
This commit makes `gXPCOMThreadsShutdown` atomic. I've deliberated on this one for a while because I was mostly interested in how timer threads may be trying to init during shutdown, but these aren't the only places where we are making accesses into `gXPCOMThreadsShutdown` so it should be made atomic regardless.
Differential Revision: https://phabricator.services.mozilla.com/D102486
Note that there's still a little plugin related code in
widget/ and gfx/ etc after this. That can be removed
once we remove plugin support from dom/ etc.
The removal from layout/ should be pretty complete though.
Differential Revision: https://phabricator.services.mozilla.com/D102140
Otherwise autoplay blocking until-in-foreground breaks with the other
patch in this bug, because it unblocks media playback once a browsing
context is active for the first time.
Differential Revision: https://phabricator.services.mozilla.com/D42329
Currently, printf_stderr doesn't show up when running with ./mach run.
This is because we run with -attach-console and that redirects stderr
to a different file descriptor using freopen in UseParentConsole.
The change from just using stderr directly happened in bug 340443 and was done
to avoid some linking issues. That problem doesn't seem to apply anymore so you'd
expect we'd be able to go back to the straightforward implemention that works even
if stderr has been redirected. Unforunately, Windows takes not buffering
stderr very seriously and fprintf will write out the results character
by character. This can cause log output lines to be intermixed which
breaks log parsing in CI. We keep using fdopen to create a new FILE*
that's buffered but instead of hard coding fd 2, we get the actual fd
that corresponds to stderr using fileno.
The mozglue implementation was cargo culted from xpcom, so we update it
as well.
Differential Revision: https://phabricator.services.mozilla.com/D98550
This eliminates all of the thread leaks we had on record, while also increasing
our coverage on the code that's used for testing firefox.
Differential Revision: https://phabricator.services.mozilla.com/D100264
These are never empty, and storing 4 elements inline seems worth it
given we also heap-allocate the array itself.
Depends on D100592
Differential Revision: https://phabricator.services.mozilla.com/D100593
Old clang shakes its fist when `auto&& item : range` is used with a
range
that returns values instead of references.
Modern `clang` doesn't warn for this scenario, so we disable the
warning.
Also removes pragmas that manually disable this warning.
Differential Revision: https://phabricator.services.mozilla.com/D100155
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
nsTSubstring::Split used to heap-allocate an array to store all tokens.
However, most uses of Split just use it to iterate in a range-based for loop.
The few remaining uses also don't need to iterate multiple times over all
tokens, so it's better to just use nsTokenizedRange, which tokenizes lazily.
Differential Revision: https://phabricator.services.mozilla.com/D99234
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
There are no uses of nsTCharSeparatedTokenizer that require run-time
configuration of the flags, so having them a compile-time template
argument allows for generation of more efficient code.
This might not matter that much now, but a subsequent patch will add another
flag to allow merging the implementation of nsTSubstring::Split with
nsTCharSeparatedTokenizer, through which the compile-time evaluation will
become more relevant.
Differential Revision: https://phabricator.services.mozilla.com/D99368
Currently, the tokenizer specializations are subclasses of the generic base
template nsTCharSeparatedTokenizer. This is unnecessary with C++11 type aliases,
as those subclasses only delegate to the base constructor.
NS_TokenizerIgnoreNothing is introduced to replace several functions with
the same effect across the codebase.
Differential Revision: https://phabricator.services.mozilla.com/D98306
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
This takes account of the fact that zones may be added to the waiting set
during an incremental GC, after the set has been cleared in
CycleCollectedJSRuntime::PrepareWaitingZonesForGC. I considered disallowing
zones to be added to the set during a GC but decided it would be better not to
lose track of poked zones in the usual case where they don't end up getting
destoryed by the current GC.
Differential Revision: https://phabricator.services.mozilla.com/D99072
This adds assertions that zone pointers passed in refer to zones we know about
and adds and API that's called when zones are destroyed. It also adds some
standard assertions for other related APIs.
Differential Revision: https://phabricator.services.mozilla.com/D99071
Kershaw Chang
Simon Giesecke
Timothy Nikkel
Oleg Skoromnik
Bogdan Tara
Nick Alexander
Nika Layzell
Kris Maglione
Brindusan Cristian
Mihai Alexandru Michis
Jon Bauman
Gijs Kruitbosch
Cameron Kaiser
Chris H-C
nirmay
Jon Coppeard
Mike Hommey
Jan Varga
Masayuki Nakano
Caroline Cullen
Csoregi Natalia
Andrew McCreight
Florian Quèze
Doug Thayer
Butkovits Atila
Mozilla Releng Treescript
Tom Schuster
Markus Stange
Masatoshi Kimura
Emilio Cobos Álvarez
Connor Sheehan
Cosmin Sabou
Kris Wright
Mats Palmgren
Dorel Luca
Bas Schouten
Jeff Muizelaar
Mitchell Hentges
Alexis Beingessner
Olli Pettay
Kartik Gautam
longsonr
Andi-Bogdan Postelnicu
Paul Bone
Bob Owen
Anny Gakhokidze
Steve Fink
Sean Feng
Sebastian Hengst