Needed to compare with `nsTextFragment::Get1b()` which returns latin1-encoded
characters. Used in a subsequent review.
Differential Revision: https://phabricator.services.mozilla.com/D52343
--HG--
extra : moz-landing-system : lando
The formatting change presumably happens because clang-format treats
include guards differently.
Differential Revision: https://phabricator.services.mozilla.com/D52698
--HG--
extra : moz-landing-system : lando
The include guard needs to happen before any non-trivial tokens.
I guess this change made clang-format decide the other ifdefs aren't
actually nested, so it dropped the indents.
Differential Revision: https://phabricator.services.mozilla.com/D52691
--HG--
extra : moz-landing-system : lando
- Introduce `dom.webcomponents.elementInternals.enabled` for custom element's elementInternals.
- Implement disabledFeatures static field and disableInternals.
- Refactor get observedAttributes sequence.
Differential Revision: https://phabricator.services.mozilla.com/D52156
--HG--
extra : moz-landing-system : lando
- Introduce `dom.webcomponents.elementInternals.enabled` for custom element's elementInternals.
- Implement disabledFeatures static field and disableInternals.
- Refactor get observedAttributes sequence.
Differential Revision: https://phabricator.services.mozilla.com/D52156
--HG--
extra : moz-landing-system : lando
This patch changes the xpidl parser to generate the rust trait code for
methods that take or return a cenum value.
Previously this would return an error, which means that adding a method
that uses cenums to an existing interface could cause rust code that
implements that interface to fail to build.
The generated methods take or return u8/u16/u32 depending on the width of the
enum. While this is not optimal (the parameter could contain values that are
not actually part of the enum), this is similar to what we do for nsLoadFlags.
In the future it would be nice to generate code that actually checks the
values are present in the enum, and to use a typedef instead of a plain
unsigned int.
Differential Revision: https://phabricator.services.mozilla.com/D51838
--HG--
extra : moz-landing-system : lando
Threadpools run an event that then runs other events, so we need to tweak
things for GetRunningEventDelay()
Differential Revision: https://phabricator.services.mozilla.com/D44058
--HG--
extra : moz-landing-system : lando
This lets us determine the time that an event has been running, and the time
that the event spent queued - which can be used to figure out 'jank' at the
time the event was queued. For PrioritizedEventQueues, only if such queuing
would delay an input event then the queuing delay is reported.
Differential Revision: https://phabricator.services.mozilla.com/D41279
--HG--
extra : moz-landing-system : lando
This patch changes the xpidl parser to generate the rust trait code for
methods that take or return a cenum value.
Previously this would return an error, which means that adding a method
that uses cenums to an existing interface could cause rust code that
implements that interface to fail to build.
The generated methods take or return u8/u16/u32 depending on the width of the
enum. While this is not optimal (the parameter could contain values that are
not actually part of the enum), this is similar to what we do for nsLoadFlags.
In the future it would be nice to generate code that actually checks the
values are present in the enum, and to use a typedef instead of a plain
unsigned int.
Differential Revision: https://phabricator.services.mozilla.com/D51838
--HG--
extra : moz-landing-system : lando
The static analysis caught this for me in Bug 1593812, I was just to
dumb to actually apply this change prior to commit.
Differential Revision: https://phabricator.services.mozilla.com/D52170
--HG--
extra : moz-landing-system : lando
Threadpools run an event that then runs other events, so we need to tweak
things for GetRunningEventDelay()
Differential Revision: https://phabricator.services.mozilla.com/D44058
--HG--
extra : moz-landing-system : lando
This lets us determine the time that an event has been running, and the time
that the event spent queued - which can be used to figure out 'jank' at the
time the event was queued. For PrioritizedEventQueues, only if such queuing
would delay an input event then the queuing delay is reported.
Differential Revision: https://phabricator.services.mozilla.com/D41279
--HG--
extra : moz-landing-system : lando
We need some way of differentiating "tasks that just consume CPU"
vs. "tasks that block on some external resource" like reading from a
socket or a file. If we didn't have this, we'd either a) have a thread
pool sized for the number of CPUs where having all the threads blocked
on I/O--and therefore no new tasks are able to run--or b) have a thread
pool that tries to increase the number of working threads based on the
number of submitted tasks and winds up having too many tasks running
with not enough CPUs to run them on.
This flag enables us to theoretically get the best of both worlds: we
can set aside `~#CPUs` threads for CPU-intensive work, and
`$SOME_NUMBER` threads for I/O work. The latter number can be adjusted
up if the I/O load on the system is particularly heavy.
The implementation strategy of this patch is to use two separate thread
pools for the two different kinds of work. It's entirely possible that
we'll want to use a single thread pool to coordinate thread create
between the two kinds of work, or even migrate threads from one kind of
work to the other, but such improvements can be future work. The focus
right now is providing the rest of Gecko with a common funnel to put
tasks into, and we can adjust what's at the end of the funnel at a later
point.
Differential Revision: https://phabricator.services.mozilla.com/D51708
--HG--
extra : moz-landing-system : lando
But don't hook it into style yet, that'll be a follow-up patch.
I had this patch in my local queue for a bit and there was no point in not
landing it I guess.
The value of this attribute could be stored only in the shadow root (as this
only applies to shadow hosts), but that would make invalidation harder, I think,
so do the obvious thing for now.
Differential Revision: https://phabricator.services.mozilla.com/D51963
--HG--
extra : moz-landing-system : lando
nsCOMArray currently casts a function that takes two `void` pointers into a
function that takes two `nsISupports` pointers. UBSAN doesn't like this.
This commit introduces an extra level of casting machinery. As a result, each
comparison done while sorting goes through an extra level, to get from `(T*,
T*)` comparisons to `(nsISupports*, nsISupports*)` comparisons to `(void*,
void*)` comparisons, as required by `NS_QuickSort()`. It's a bit annoying but I
can't see how else to solve this within the constraint imposed by the existing
`nsCOMArray_base`/`nsCOMArray` split.
Differential Revision: https://phabricator.services.mozilla.com/D51223
--HG--
extra : moz-landing-system : lando
`TaskQueue` wraps an `nsIEventTarget` to provide "one runnable at a
time" execution policies regardless of the underlying implementation of
the wrapped `nsIEventTarget` (e.g. a thread pool). `TaskQueue` also
provides a `nsISerialEventTarget` wrapper, `EventTargetWrapper`, around
itself (!) for consumers who want to continue to provide a more
XPCOM-ish API.
One would think that dispatching tasks to `EventTargetWrapper` with a
given set of flags would pass that set of flags through, unchanged, to
the underlying event target of the wrapped `TaskQueue`.
This pass-through is not the case. `TaskQueue` supports a "tail
dispatch" mode of operation that is somewhat underdocumented. Roughly,
tail dispatch to a `TaskQueue` says (with several other conditions) that
dispatched tasks are held separately and not passed through to the
underlying event target. If a given `TaskQueue` supports tail dispatch
and the dispatcher also supports tail dispatch, any tasks dispatched to
said `TaskQueue` are silently converted to tail dispatched tasks. Since
tail dispatched tasks can't meaningfully have flags associated with
them, the current implementation simply drops any passed flags on the floor.
These flags, however, might be meaningful, and we should attempt to
honor them in the cases we're not doing tail dispatch. (And when we are
doing tail dispatch, we can verify that the requested flags are not
asking for peculiar things.)
Differential Revision: https://phabricator.services.mozilla.com/D51702
--HG--
extra : moz-landing-system : lando
The current API name is bad: we want it to be read "some background
thread", but it could just as easily be read "a singular background
thread", which would lead people to assume that for:
```
NS_DispatchToBackgroundThread(...);
NS_DispatchToBackgroundThread(...);
```
the dispatched tasks will necessarily run in the order they are
dispatched, which is not the case.
Let's try to head off that interpretation by renaming this function.
Differential Revision: https://phabricator.services.mozilla.com/D51703
--HG--
extra : moz-landing-system : lando
nsIDOMWindow is now an empty interface. There are two references to
nsIDOMWindow::openDialog in comments which needed to be updated. There
were also a few forward declarations of nsIDOMWindow that were unused.
Differential Revision: https://phabricator.services.mozilla.com/D51738
--HG--
extra : moz-landing-system : lando
promise rejection event was enabled by default on 69 (bug 1525554).
We could get rid of this preference.
Differential Revision: https://phabricator.services.mozilla.com/D51491
--HG--
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
Zibi is working on replacing some string based APIs with some things that return
substrings, so we could use this.
Alternatively he'd have to do something like:
Compare(myCSubstring, nsDependentCSubstring(aTag, strlen(aTag)))
or something of that sort, which looks a bit uglier.
Differential Revision: https://phabricator.services.mozilla.com/D50523
--HG--
extra : moz-landing-system : lando
Zibi is working on replacing some string based APIs with some things that return
substrings, so we could use this.
Alternatively he'd have to do something like:
Compare(myCSubstring, nsDependentCSubstring(aTag, strlen(aTag)))
or something of that sort, which looks a bit uglier.
Differential Revision: https://phabricator.services.mozilla.com/D50523
--HG--
extra : moz-landing-system : lando
In this change we:
- stop treating the nsPluginDirServiceProvider as a directory provider, as its
GetFile implementation was a no-op anyway - registering it didn't make any
difference.
- stop treating it as a class entirely, because the PLID getters were already
static, so instantiating it also didn't do anything.
- move IO from the plugin directory list provider and the Windows-only PLID
getters into nsPluginHost. This enables us to move it off of the main thread
later - the directory getting has to happen on the main thread, but we can
postpone further checks on the nsIFile instances.
- in the process, stop doing exists() calls on files because we can fail more
lazily. This allows us to remove more allowlist entries from
browser_startup_mainthreadio, though the `isDirectory` calls will actually
still cause IO - they don't seem to create IO markers in the profiler.
We will move this IO away from the main thread in subsequent commits.
Depends on D48328
Differential Revision: https://phabricator.services.mozilla.com/D48329
--HG--
extra : moz-landing-system : lando
In this change we:
- stop treating the nsPluginDirServiceProvider as a directory provider, as its
GetFile implementation was a no-op anyway - registering it didn't make any
difference.
- stop treating it as a class entirely, because the PLID getters were already
static, so instantiating it also didn't do anything.
- move IO from the plugin directory list provider and the Windows-only PLID
getters into nsPluginHost. This enables us to move it off of the main thread
later - the directory getting has to happen on the main thread, but we can
postpone further checks on the nsIFile instances.
- in the process, stop doing exists() calls on files because we can fail more
lazily. This allows us to remove more allowlist entries from
browser_startup_mainthreadio, though the `isDirectory` calls will actually
still cause IO - they don't seem to create IO markers in the profiler.
We will move this IO away from the main thread in subsequent commits.
Depends on D48328
Differential Revision: https://phabricator.services.mozilla.com/D48329
--HG--
extra : moz-landing-system : lando
This patch uses the low memory resource notification facility to detect
scenarios where physical memory is running low without polling. This is a
significant change compared to the previous behavior which measured both
available virtual memory (only on 32-bit builds) and available commit space.
Since we're not trying to avoid OOMs anymore we don't save memory reports
anymore when hitting a low-memory condition.
Differential Revision: https://phabricator.services.mozilla.com/D50471
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Simon Giesecke
Mirko Brodesser
Noemi Erli
Andrew McCreight
John Dai
Sylvestre Ledru
Dorel Luca
Ehsan Akhgari
Bogdan Tara
Valentin Gosu
Randell Jesup
Nathan Froyd
Matt Woodrow
Razvan Maries
Coroiu Cristina
Sebastian Hengst
Nicholas Nethercote
Bob Owen
Edgar Chen
Jan de Mooij
Gijs Kruitbosch
Ciure Andrei
Gabriele Svelto