The callers no longer need fixed registers, which should improve codegen a little.
In emitStoreDenseElementHole we can simplify the handleAdd case by merging the
"before type update IC" and "after type update IC" code.
In emitArrayPush use AutoOutputRegister, the old code loaded the value in R0 and
then relied on that register matching the IC's output register.
Differential Revision: https://phabricator.services.mozilla.com/D99222
Also change the argument type from ICStub* to ICFallbackStub* so that we don't
need the `toFallbackStub()` cast. This required changing the callers to use auto*
so that they pass the derived type.
Drive-by change: add a MOZ_UNLIKELY for the OOM path as this code is somewhat hot.
Differential Revision: https://phabricator.services.mozilla.com/D99220
With TI the preliminary-object handling made this more difficult.
In the IonIC code we can also remove TryAttachIonStub's IC template parameter.
Differential Revision: https://phabricator.services.mozilla.com/D99219
Warp has let us remove the Baseline Type Monitor stubs that triggered the bug.
The workarounds also didn't stop the crashes.
Differential Revision: https://phabricator.services.mozilla.com/D99218
In the Safe Browsing spec, it says "Do not apply these path canonicalizations to the query parameters.",
we should follow it.
Differential Revision: https://phabricator.services.mozilla.com/D98898
When loading a printer's settings it can take a few seconds for physical printers. If
this happens then changes made while the settings are being fetched could be thrown
away. Disable the form while we're loading settings for a printer to avoid losing
settings changes.
Differential Revision: https://phabricator.services.mozilla.com/D99156
This removes all the change event listeners so that all the elements listen
for just the input event. Listening to both could cause two settings change
events to be dispatched and requires writing code to ignore change events
in many components.
Differential Revision: https://phabricator.services.mozilla.com/D99136
When changing printers one of them could be slower than another. If you change
to a slow printer and back to an already loaded/fast printer then the slow
printer shouldn't overwrite the settings once it finally loads.
Example: Start print on PDF printer, switch to a physical printer and back to PDF. If
the physical printer had to be contacted to pull settings this operation could take
a few seconds, at which point the settings from the physical printer could overwrite
the PDF printer settings.
Differential Revision: https://phabricator.services.mozilla.com/D99135
I don't have a crystal clear story of why these timings are different with the
skeleton UI enabled. However, it's not remarkably surprising that it changes the
order of some events during startup which come from the core Windows event loop.
I don't think it's worth diving incredibly deep to understand this - looking at
the profile we still only see one of each of these events.
Differential Revision: https://phabricator.services.mozilla.com/D99111
Having the window present earlier changes the ordering of these events, such
that it doesn't come through at the time that the browser_startup test needs it
to. I think this event should be correct anyway, given that we already painted
the skeleton UI?
Differential Revision: https://phabricator.services.mozilla.com/D98478
Some env vars have effects similar to command line arguments which present
problems for the skeleton UI, and we want to treat these env vars similarly.
Differential Revision: https://phabricator.services.mozilla.com/D98475
Previously, we implemented arg checking with `marionette` just carrying a free
pass, so we could let the arguments which typically come when running tests.
However, some marionette tests do like to play with arguments which we do not
want to get a free pass, such as -safe-mode. These changes allow just the
-profile argument through, as that is necessary for running tests.
Differential Revision: https://phabricator.services.mozilla.com/D98474
This is bug 1639318 all over again except from Rust rather than C++. It's the same symptom, nsXPTCStub vtables aren't marked as valid targets.
In the earlier bug we disabled CFG for C++ on ARM64. Let's do the same for Rust. According to that bug, "It's not clear why this doesn't happen on x86 builds. Given priorities, I can't really justify investigating this, although I suspect that fixing the underlying issue would be pretty much bug 1483885."
Differential Revision: https://phabricator.services.mozilla.com/D99278
Rework the MediaKeys class to shutdown when its parent inner window is destroyed
rather than the document it's created in. This is done to mitigate the case
where a MediaKeys is created in an about:blank document that has not yet
undergone its async load (i.e. blank document that will stay blank, blank
documents loading to other pages will still clobber their keys on load). This
specifically addresses cases where sites could create an iframe, not wait for
load, create a MediaKeys in the iframe, and then find the keys had become
unusable.
This is achieved by associating MediaKeys instances with their inner window and
having the window notify keys when a window is going to be destroyed. I decided
to use this approach rather than have MediaKeys observe for window destruction
for a few reasons:
- The keys would need to support weak references to use the observer service in
the desired way. Implementing this interface on the MediaKeys adds a
non-trivial level of complexity and means the keys would implement the WeakPtr
interface (already in place prior to this patch) and also the NS weak
reference interface, which I found confusing.
- If the inner window stores pointers to MediaKeys created in it, it can be self
aware of if EME activity is taking place within it. The allows us to better
identify EME activity in documents. Historically one of the ways we'd
determined EME activity by checking if media elements have MediaKeys attached,
but this had lead to issues where if MediaKeys are created but not attached
to a media element we overlook them. With this patch's changes, we can also
have a document check its inner window to see if there are any MediaKeys. This
patch uses this to extend our check to avoid bfcaching pages with EME content.
- There appears to be prior art using a similar approach for audio contexts and
peer connections, which I assume is sensible and I'm not reinventing the wheel
by following.
Differential Revision: https://phabricator.services.mozilla.com/D98641
If MediaKeys::Init is called before an about:blank doc has performed its async
load, then that document will not have a channel and thus will not have a load
info. This means we cannot look up the top level principal on such a document.
Since we need the top level principal to ensure GMPs are appropriately isolated
from one another, this patch checks the document above the current doc for a
channel and load info in the case the current document does not have one. Since
an about:blank document is considered in the same origin as its parent, this
should be suitable. This process is done recursively to handle edge cases.
Differential Revision: https://phabricator.services.mozilla.com/D97322
Provide coverage that ensures we can:
- Call navigator.requestMediaKeySystemAccess() and receive access
- Call createMediaKeys on the access object
in iframes that are same and different origin.
This should work when waiting for an iframe to fire the load event, but I also
provide a case for if we do not wait for load. It's undesirable to not wait for
the load, but we've historically worked in this case (if this was intentional is
not clear to me). So providing such a test allows for coverage of this case as
long as we want to continue supporting it. Said test will be red as of this
patch, but an immediate follow up will restore our compat with this case.
Differential Revision: https://phabricator.services.mozilla.com/D97321
This patch doesn't change behavior. It's just a simplification of the data
that we track for our different pages-per-sheet mode (with some minor
refactoring of the logic involved).
This is a necessary step towards implementing support for 2 and 6
pages-per-sheet (which are referenced in comments included in this patch,
and which will be implemented separately in bug 1669905)
Differential Revision: https://phabricator.services.mozilla.com/D99180
ObjLiteralStencil doesn't have to be writable, and the cost of Vector handling
is problematic when decoding.
Decoupled ObjLiteralWriter from ObjLiteralStencil and now ObjLiteralStencil
has a Span that points memory block inside LifoAlloc.
While compiling, the data is copied from ObjLiteralWriter's Vector to LifoAlloc,
and while decoding, the memory is copied from XDR buffer to LifoAlloc.
Differential Revision: https://phabricator.services.mozilla.com/D99052
Now ParserAtom can be referred by single uint32_t data, and we don't have to
store ParserAtom pointer inside ObjLiteralWriter.
Previously the number of atoms referred from object literal was limited to
24-bit, in order to pack opcode + atom in 32-bit, but the limitation is removed,
and now atom always use 32-bit, separated from opcode.
Differential Revision: https://phabricator.services.mozilla.com/D99051
To suppress ctor/dtor cost of Vectors inside StencilModuleMetadata,
Make CompilationStencil.moduleMetadata Maybe and emplace only when compiling/
decoding module.
Differential Revision: https://phabricator.services.mozilla.com/D99050
This patch removes the hand-rolled shared background thread in favor of
individual background synchronous event targets. Also, the timer configuration
was moved to the main thread. It now dispatches events to the background task
queue, which makes it easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D98977
