`osfile` is deprecated and `./mach lint -l eslint` shows warning message for
it. So I would like to replace it with `PathUtils`.
Differential Revision: https://phabricator.services.mozilla.com/D159343
Also assure that unregistering an accessible removes the right one and
doesn't confuse the attached document with the detached one.
Add stderr output to Accessible::DebugPrint in Android as well.
Differential Revision: https://phabricator.services.mozilla.com/D157528
Calls in original asm.js source code that result in function calls at the wasm level
require preservation of the original JS line number. This metadata is through a
callSiteLineNums vector which needs to be iterated through exactly in sync between
the compiler and bytecode generator. We have this logic in ion, but for some reason
it also exists in baseline, even though baseline is never used (and won't be) for
asm.js code.
This commit removes logic related to line numbers from baseline, simplifying the
logic. Previously, we needed to consume the potential line number at the beginning
of the instruction, then propagate it to wherever the function call would be. Now
we can just read the bytecode offset of the current instruction whenever we need
it.
Differential Revision: https://phabricator.services.mozilla.com/D159201
This commit fixes actionable clang-tidy warnings in js/src/wasm.
There are some slight functional changes here, but nothing major.
Most of the issues are:
* Mismatched decl/def arg names
* Redundant if (cond) return true; else return false;
* Unsigned to signed is implementation defined
* Unnused definitions
* Typedef instead of using
* Uninitialized definitions
There are still a bunch of clang-tidy warnings, but they're
cases where our style is not matched with clang-tidy.
Differential Revision: https://phabricator.services.mozilla.com/D159194
An exception handling tag `(tag $name)` will nearly always have at
least one param for communicating the pointer to the thrown exception.
We should increase the inline storage in this vector so that we
don't have to allocate in this case. We do this already with the
ValTypeVector used in this class.
Differential Revision: https://phabricator.services.mozilla.com/D159191
This replaces deprecated classes, except in the one case where we're
purposely using the deprecated class until it's actively removed.
Differential Revision: https://phabricator.services.mozilla.com/D159368
The use of `-Xclang -Wall` somehow makes `-Wno-unknown-pragmas`
ineffective. `-Xclang -Wno-unknown-pragmas` does however work.
But we don't need to set `-Xclang -Wall` from the moz.builds in the first
place, as that's already done properly via warnings.configure (setting
-Wall on non-clang-cl and -W3 on clang-cl, which is the equivalent).
Differential Revision: https://phabricator.services.mozilla.com/D159366
Also change the default value for --jobs to 0 instead of 1, because
`make -j1` doesn't initialize a jobserver, so cargo uses all cores,
which is a fine default, but now that we may also invoke the rest of
the build system, and because `make -j1` for that is slow, we instead
use 0 as the default (which means auto-detect).
Differential Revision: https://phabricator.services.mozilla.com/D159336
This patch hasn't been touched in ten years and the code it affects does not
appear in the file, so I think it is old an unused.
Differential Revision: https://phabricator.services.mozilla.com/D159514
Depends on D156968
Cleanup of the ChannelMap class
- use private fields
- move static method to module-local method
- add comments
- rename methods to match behavior
Differential Revision: https://phabricator.services.mozilla.com/D156989
This is a very basic migration from commonjs modules to ESM for all modules related to network observation.
A few classes have been introduced instead of prototype-based classes, but otherwise the code remains mostly untouched.
We can followup to introduce private fields and methods if there's interest?
Differential Revision: https://phabricator.services.mozilla.com/D156968
In bug 1787520 we discovered a driver bug affecting Mali-G78 devices,
and added a workaround for it - avoiding invalidating no-longer-needed
render targets at the end of each render pass. It now transpires this
bug also affects Mali-G710 GPUs, so this patch applies the same
workaround for those devices too.
Differential Revision: https://phabricator.services.mozilla.com/D159515
If the video looping is not seamless, when playback reaches to the end,
MDSM would trigger a seek in order to get the new frame from the start
position. That would notify the media element that the status of the next
frame is not available now due to seeking (NEXT_FRAME_UNAVAILABLE_SEEKING)
and causes the media element dispatching `waiting` event.
Above situaion shouldn't happen when we're in the seamless looping. The
added test covers that situation.
That ready state change also causes the google meet issue [1], because
the spec only allows capturing an image from a media element if it's
ready state is at least in `HAVE_CURRENT_DATA`.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1789881#c3
Differential Revision: https://phabricator.services.mozilla.com/D159218
The media format reader's seek doesn't support seeking in parallel, so
that is why the format reader would seek video first, then audio.
Therefore, in looping state, we need to perform seeking sequentially by
delaying the new seek if the format reader is already in seeking.
Otherwise, a seeking comes later will overwrite the seek target that the
current seek is using, which causes an error.
Differential Revision: https://phabricator.services.mozilla.com/D159217
Audio and video demuxer are independent, so seeking the audio demuxer
won't affect requesting a data from the video demuxer.
Differential Revision: https://phabricator.services.mozilla.com/D159127
