This change makes it possible to access the remote agent service
from C++ and Rust.
Differential Revision: https://phabricator.services.mozilla.com/D50288
--HG--
extra : moz-landing-system : lando
This will prevent the leak checker from reporting a missing log for
that process, which results in incorrect starring on TreeHerder. Both
of these failures should be detected as a failure.
Differential Revision: https://phabricator.services.mozilla.com/D53095
--HG--
extra : moz-landing-system : lando
The launcher process turns on the `PreferSystem32Images` mitigation policy for
the browser process. Since the mitigation policy is inherited, a process launched
by the browser process also has `PreferSystem32Images`. If an application which
does not support `PreferSystem32Images`, such as Skype for Business, is launched
via a hyperlink, a custom uri, or a downloaded file, it would fail to launch.
Bug 1567614 fixed this issue by introducing `mozilla::ShellExecuteByExplorer` to
`nsMIMEInfoWin::LoadUriInternal`. This patch introduces
`mozilla::ShellExecuteByExplorer` to two more places.
1. xul!nsLocalFile::Launch
This is invoked when a user opens a file from the Download Library, or a user
opens a downloaded file with the default application without saving it.
2. xul!nsMIMEInfoWin::LaunchWithFile
This is invoked when a user opens a downloaded file with a custom application
(configured in about:preference) without saving it.
*Why does this patch change worker.js?*
The mochitest dom/tests/browser/browser_test_new_window_from_content.js failed
if it was executed after dom/serviceworkers/test/browser_download.js in the
same batch. This was because browser_download.js launched Notepad to open
fake_download.bin.txt, preventing a new window from being opened in the
foreground in browser_test_new_window_from_content.js.
The test browser_download.js can verify downloaded data without opening an
associated application. So this patch adds the content-type to the response
header in order not to open Notepad on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D52567
--HG--
extra : moz-landing-system : lando
Some kinds of leaks prevent NSS to not shut down properly, and right
now if that happens we crash. This interferes with our existing leak
checking code, so in this patch I make it not crash if we are already
leak checking. The failure is reported as a fake leak, so the test
should still fail when testing.
Differential Revision: https://phabricator.services.mozilla.com/D52914
--HG--
extra : moz-landing-system : lando
This adds two AUTO_PROFILER_LABEL_DYNAMIC_... macros and updates select
usages of the old macros to use the new ones. These new macros cause
the dynamic string of the label to be included in BHR stacks.
We don't want to do this all of the time, as in many cases we may not
be interested enough in the dynamic string or it may be sensitive
information, but it is rather important information for certain cases.
This uses the same buffer that we use for the strings for JS frames,
and if we fail to fit into that buffer we just append the raw label.
If the string is too long for our static buffer (128 bytes), we just
leave it truncated, as it should be stable and we may be able to infer
from the truncated form what the full form would be.
Differential Revision: https://phabricator.services.mozilla.com/D51665
--HG--
extra : moz-landing-system : lando
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
Daniel Varga
Andreas Tolfsen
Boris Zbarsky
Andrew McCreight
Sylvestre Ledru
Paul Bone
Toshihito Kikuchi
Doug Thayer
Emilio Cobos Álvarez
Simon Giesecke
Mirko Brodesser
Noemi Erli
John Dai
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