While we're at it: remove one layer of unnecessary error handling in
NS_NewSyncStreamListener, since it's clearer now that we'll be getting
infallible allocation.
Differential Revision: https://phabricator.services.mozilla.com/D161949
This patch doesn't change behavior; these APIs were already effectively
infallible, in the sense that it was impossible for them to return anything
other than NS_OK.
The actual API changes here are in xpcom/io/nsIPipe.idl and
xpcom/io/nsPipe3.cpp, and the rest of this patch is just updates to callsites,
removing code that handled failure-flavored return values from these functions.
(All of this removed code was already dead code, effectively.)
Differential Revision: https://phabricator.services.mozilla.com/D161947
On Android, we access RemoteAccessibles from the UI thread.
It's not safe to access LocalAccessibles on the UI thread.
The a11y code avoids touching LocalAccessibles on the UI thread directly.
However, Accessible::GetLevel was previously walking ancestry, which might hit a LocalAccessible and result in a crash.
To avoid this, don't ascend past a DocAccessible.
Level calculation shouldn't be crossing document boundaries anyway.
Note that we don't have to do this when we simply retrieve the parent (but nothing further) because we only do that for certain roles and the parent of these roles could never be an OuterDoc.
Differential Revision: https://phabricator.services.mozilla.com/D161873
APZ cannot currently scroll in directions which are overflow:hidden
(it does not know the full scroll range bounds in those directions).
Therefore, main-thread scrolling in these directions should not be
handed off to APZ.
Differential Revision: https://phabricator.services.mozilla.com/D161351
This XPCOM interface was being initialized and used, and was unnecessary.
This patch removes it completely to simplify things, initializing
viaduct during xpcom startup instead. This is done rather than keeping
it lazy and tied to FOG startup, as the implementation just sets a
static atomic to a function pointer.
This makes no changes to anything which actually uses viaduct, which is
done through the previously mentioned static atomic.
Differential Revision: https://phabricator.services.mozilla.com/D162010
The python multiprocessing module normally uses sys.executable to launch a new process. For some of our Windows test tasks, this does not work -- the launch fails with a FileNotFoundError. Calling multiprocessing.set_executable() with the configured python executable resolves this issue. I've limited this change to Windows and to the mozharness scripts known to have this problem: raptor, talos, and desktop_unittest.
While I'm here, I've also improved the exception handling in mozsystemmonitor, hoping to get better diagnostics and more sensible behavior if similar exceptions occur in future.
Differential Revision: https://phabricator.services.mozilla.com/D162022
With doing SnapCoord we mis-consider non-scrollable frames as scrollable in APZ,
thus it causes unexpected overscroll gutters.
Depends on D161417
Differential Revision: https://phabricator.services.mozilla.com/D161419
With onload event handler this reftest isn't in a good state, in other words
it's not stable on all platforms. Specifically on Windows 10 this testing html
is rendered at 1px upper than the reference html without pixel snapping on the
main-thread. Interestingly this reftest doesn't fail at least on my Windows 11
laptop without the pixel snapping. So there's something that metrics are timing
specific (e.g. font loading) to make this test flaky.
Differential Revision: https://phabricator.services.mozilla.com/D161417
Rather than having each richlistbox consumer having to reinvent focus patterns for
buttons and menulists in its 'rich' items, let's just teach richlistbox and
richlistitem to not suck at keyboard navigation. That way we won't keep forgetting
to deal with this whenever we add new lists anywhere.
This allows us to remove the custom handling in sitePermissions.js, and the same
handling should be covered by the existing test, ie
browser/components/preferences/tests/browser_permissions_dialog.js
To summarize the desired keyboard behaviour:
- tab/shift-tab move focus to controls inside selected items only (not other rows)
- arrow keys move the list selection up/down
- when arrowing to move the list selection, focus moves with the selection if it
was previously on a control in the previously selected item.
Differential Revision: https://phabricator.services.mozilla.com/D161528
This patch solves the intermittent failure on the try server for
`test_playback_rate_playpause.html`.
The media engine has an internal issue which would dispatch events in
incorrect status. Eg. `ended` event should only happen during playback.
The root cause is that the media engine dispatches two `ended` events,
and the first one is incorrectly dispatched even if the playback hasn't
started yet. That incorrect event is racing with the media decoder's
status change.
When `ExternalEngineStateMachine` notifies first incorrect `ended`,
the media decoder hasn't reached a correct state (still in loading), so
the decoder ignores the ended notification from the state machine [1].
However, when the external state machine receives the second correct
`ended` event, it won't notify media decoder again [2].
Above results along with another addition factor causes the issue, which
is that the media engine doesn't update its current time precisely,
so the test couldn't enter the next step because the current time is
still zero.
If the `ended` event gets dispatched correctly, current time would be
adjusted to `1` based on the duration [3].
[1] https://bit.ly/3WOR16n
[2] https://bit.ly/3ThmAms
[3] https://bit.ly/3WNvH1a
Depends on D161623
Differential Revision: https://phabricator.services.mozilla.com/D161730
This issue is discovered when playing `red-46x48.mp4` in
`test_playback_rate_playpause.html`.
That video only contains one frame, and after it reaches EOS, the
format reader will drain the decoder. However, the media engine won't
return a decoded frame before we tell it the track is already ended.
That causes a deadlock, notifying EOS (from reader) waiting for the
drain promise, and the drain promise waiting for first decoded frame, and the
first decoded frame waiting for EOS.
Therefore, we would consider having pending drain promise as a sign of EOS as well,
in order to get the decoded frame and revolve the drain promise.
Differential Revision: https://phabricator.services.mozilla.com/D161623
As now the video stream would only return an image when the dcomp image
is ready, we should also delay sending first frame ready event and
notify next frame status correctly based on whether we've received the
decoded data.
Otherwise, it would cause the ready state in the media element in
incorrect status.
Differential Revision: https://phabricator.services.mozilla.com/D161551
Daniel Holbert
Emilio Cobos Álvarez
James Teh
Iulian Moraru
Paul Zuehlcke
Botond Ballo
Nika Layzell
Mike Conley
William Durand
Geoff Brown
Mark Banner
Csoregi Natalia
Hiroyuki Ikezoe
Gijs Kruitbosch
Eitan Isaacson
Julian Descottes
Henrik Skupin
Chris H-C
alwu