We are seeing crashes on aarch64 Fenix devices that appear to be related
to zero-sized messages. But we're seeing the crashes when we're trying
to send the messages on the IO thread, and not where we're dispatching
them from. Add some asserts so we get errors closer to the source, and
add some asserts for other things that we believe to be true and would
be useful to know aren't actually true.
Differential Revision: https://phabricator.services.mozilla.com/D76496
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
This method always copies, and is redundant with the other getter methods on
IPDL unions. As there is only one caller, it can be removed to simplify the
code, and remove a source of complexity.
Differential Revision: https://phabricator.services.mozilla.com/D75349
Currently, the worker's COEP is saved in WorkerPrivate and not be respected when loading resources in workers.
This patch adds an attribute loadingEmbedderPolicy in nsILoadInfo, which indicates the COEP header the loading must be respected.
The default value of loadingEmbedderPolicy is nsILoadInfo::EMBEDDER_POLICY_NULL.
loadingEmbedderPolicy is initialized with the COEP of the BrowsingContext used for creating LoadInfo.
And it could be set to other value when fetch in workers.
Differential Revision: https://phabricator.services.mozilla.com/D73690
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75371
We add a 'IsThirdPartyContextToTopWindow' flag in the LoadInfo. This
flag shows if the channel is considered as a third party related to the
top-level window.
This flag would be set when opening the channel in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D73199
Fix intermittent issues due to races.
We now run the MozPromise generated by the IPDL bindings to run their callbacks via a direct task dispatch.
This avoids a full trip to the back of the event queue for each additional asynchronous step when using MozPromise.
A consequence to this change is that each IPDL actor's thread must have an AbstractThread allocated if IPDL MozPromises are used.
It prevents unexpected racy behaviours when combining MozPromise with the other Resolve/Reject IPDL async declaration which was have lead to processing the events out of order.
Differential Revision: https://phabricator.services.mozilla.com/D71593
The hashes of certain strings is used indirectly in generating IDL C++ files. Before, we were using the `hash()` function to generate these hashes, which in Python 3 is non-deterministic over subsequent `python3` processes, causing bugs like bug 1635755. Instead, use a specific, deterministic hash to avoid spurious diff failures.
The `md5` hash function isn't completely cryptographically secure but the security of the hashes isn't important for us in this case since we're just using them as a per-string identifier. We could use a more robust hash function but there may be performance implications from doing so.
Differential Revision: https://phabricator.services.mozilla.com/D74446
`ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).)
In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](1fac9fed64/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway.
Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository:
```
PLY no longer writes cached table files. Honestly, the use of
the cached files made more sense when I was developing PLY on
my 200Mhz PC in 2001. It's not as much as an issue now. For small
to medium sized grammars, PLY should be almost instantaneous.
```
In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes.
That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility.
Differential Revision: https://phabricator.services.mozilla.com/D73484
Currently, there is an outstanding issue where enabling the GPU sandbox breaks
scrolling using the the mouse wheel on laptops with Intel GPUs.
This will enable the GPU sandbox on Nightly for non-Intel GPUs to prevent any
sandbox regressions while we try and figure out what the scrolling issue is.
See Bug 1630860 for more info
Differential Revision: https://phabricator.services.mozilla.com/D73923
Sylvestre Ledru
Gijs Kruitbosch
Nathan Froyd
Bob Owen
Chris H-C
Emilio Cobos Álvarez
Peter Van der Beken
Nika Layzell
Eden Chuang
nicolaspacheco
Aaron Klotz
Razvan Maries
Sebastian Streich
Gian-Carlo Pascutto
Bogdan Tara
Jean-Yves Avenard
Narcis Beleuzu
Csoregi Natalia
Tim Huang
ssengupta
Andrew McCreight
Ricky Stewart
Chris Fronk
Kershaw Chang
Dorel Luca
Simon Giesecke
Chris Martin