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
This patch further simplify the logic of returning decoded data by
making it async.
As now we don't need to return decoded data on different thread than the
task queue, it also makes the threading for the video stream easier.
Differential Revision: https://phabricator.services.mozilla.com/D161550
The goal of this patch aims to solve the green frame issue which usually
happens on the start position or when changing the resolution.
The reason of causing the green frame is because of the fake data we
created. Therefore, we should only return decoded video data when the
video stream is able to generate one.
We added a new media queue to store the raw data, which would be used to
generate the output decoded data. The previous one we have is used to
feed raw data into the media engine, which has a different purpose.
Differential Revision: https://phabricator.services.mozilla.com/D159537
In profiles of the regressing benchmarks, it appears that there is some amount
of locking contention when large numbers of small messages messages over IPC.
While the bulk of this contention is probably caused by the OnIOCompleted
callbacks on the IO thread, there's not much we can do about those wake-ups.
This patch tries to reduce the contention by avoiding acquiring the mutex when
receiving IPC messages using the ChannelCapability introduced in part 1.
I am hopeful that this will slightly improve performance, however it seems
likely that there will still be slowdowns due to other parts (like NtWriteFile)
not being easy to optimize.
Future changes such as using a shared memory ring buffer for IPC on windows, or
an approach like ipcz which uses shared memory to avoid signalling messages in
some situations, may improve performance here in the future.
Differential Revision: https://phabricator.services.mozilla.com/D161855
This patch introduces a new combined capability, ChannelCapability, which
combines the previous Mutex and IOThread capabilities into a single common
capability. This capability can be asserted using the `Note` methods when
holding the specific inner capabilities to either allow shared access to
guarded variables while holding a single capability, or exclusive access when
holding all capabilities.
This is similar to the MutexSingleWriter pattern, however this implementation
is more flexible, as it also allows interacting with each individual inner
capability individually.
This patch just migrates existing attributes and mutex accesses to their new
names. Changes to behaviour will happen in part 2.
Differential Revision: https://phabricator.services.mozilla.com/D160532
In Classifier::ReadNoiseEntries(), we used to get the entire prefix set
in order to get noise prefixes. This patch improves it by getting noise
prefixes by index. So, we don't need the entire prefix set.
The patch introduces new functions in LookupCacheV2, V4 and
VariableLengthPrefixSet to allow getting target prefix by index. Also,
we need to inroduces new functions to get the length of the prefix set
to run the noise pick up algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D161771
This patch implements a nsUrlClassifierPrefixSet::GetPrefixByIndex() that
allows to get the specific prefix with the given index.
Differential Revision: https://phabricator.services.mozilla.com/D161769
We record the cookie banner service mode prefs in the 'idle-daily'
observer. This would allow us to observe the pref changes with time.
Differential Revision: https://phabricator.services.mozilla.com/D161286
