It was not installed consistently across platforms, and I think the only
reason we installed it had been superseded by the `mach uuid` command
(which didn't rely on it), and the `mach uuid` command was removed in
bug 1639509.
Differential Revision: https://phabricator.services.mozilla.com/D162636
One thing to note is that if the user shrinks this number we won't reclaim any memory - this is because I wanted to avoid doing any more work than necessary when we're logging messages. Let me know if you think this is a problem!
Differential Revision: https://phabricator.services.mozilla.com/D161156
At :handyman's suggestion, just removing the messages when we get a WM_DESTROY message works great and is way less complicated than the previous version of this :-)
Differential Revision: https://phabricator.services.mozilla.com/D161155
This is the list of messages that handyman and rkraesig suggested.
Since we're recording WM_GETMINMAXINFO, we now have better logging for that message.
Differential Revision: https://phabricator.services.mozilla.com/D161150
This is helpful for the normal event log, and also necessary since we want to group the messages up by window in the about page.
Differential Revision: https://phabricator.services.mozilla.com/D161149
When a selection event is dropped due to coalescence, we still include the impacted Accessible in the SelectedAccessiblesChanged notification we send to the parent process.
Although we skip events with defunct targets, we weren't skipping defunct items referenced by selection events.
This meant that if an Accessible was selected/unselected but was shut down before we sent SelectedAccessiblesChanged, the notification would include a dead Accessible.
This was causing an assertion in the parent process.
To fix this, we now ignore defunct items in selection events.
Differential Revision: https://phabricator.services.mozilla.com/D162551
Gecko switched to mutating the tree structure for aria-owns many years ago instead of using relations, so this is now dead code.
Note that a test case was added for this aria-owns case in accessible/tests/mochitest/role/test_general.html in bug 1044431.
This still passes with this code removed.
Differential Revision: https://phabricator.services.mozilla.com/D162459
It used to be necessary to set the target for android builds, but that
hasn't been the case since bug 1523341. In fact, that bug removed the
--target for non-artifact android builds, but somehow left this one
alone.
Differential Revision: https://phabricator.services.mozilla.com/D162634
--enable-application is the historic flag, and --enable-project was
added to handle the non-application things we build, while encompassing
the meaning of --enable-application. --enable-project has been preferred
for a while and we should reflect that more consistently in mozconfigs,
documentation, etc.
Differential Revision: https://phabricator.services.mozilla.com/D162625
At the time the message is printed, installing git-cinnabar hasn't even
been tried (it happens in the in-tree bootstrap, not the sandalone
bootstrap, which this is) ; we have installed a temporary copy of
git-cinnabar, which may fail, but if it does, we'd throw an exception
before reaching this message anyways.
Differential Revision: https://phabricator.services.mozilla.com/D162611
The change disables ZeroCopyNV12Texture for checking if the video overlay works without ZeroCopyNV12Texture with non-intel GPU.
For now, on release, ZeroCopyNV12Texture is not enabled with non-intel GPUs. It blocks to enable video overlay with non-intel GPUs. Then it seems better to enable video overlay with non-intel GPUs on release without ZeroCopyNV12Texture if possible.
Differential Revision: https://phabricator.services.mozilla.com/D160744
Instead of relying on OS.File.setCurrentDirectory in the xpcshell test harness
we instead provide a function to directly change directory.
Differential Revision: https://phabricator.services.mozilla.com/D148977
The test sometimes receives zero Merino suggestions when it expects some. I
noticed a few potential problems:
1. The `merino.timeoutMs` pref keeps its default value of 200ms throughout most
of the test. That's low enough that it might cause the client to time out
waiting for Merino, especially on slow machines in verify mode. To fix that,
I set the timeout pref to a large value at the start of the test.
2. The Merino test server should probably cancel its delayed-response timers
when `reset()` is called on it. Otherwise the server will still send
responses once the timers elapse, which might interfere with later tasks.
3. I'm not sure about this, but the test server's `#handleRequest()` method
probably shouldn't be async. Right now it's async to handle sending delayed
responses. This patch makes it sync and it just handles that using a `then()`
instead.
[Retriggers on try](https://treeherder.mozilla.org/jobs?repo=try&revision=e8ba8f1d05d2a701498bd9fe6a69fd88ba74eb37) are green.
Differential Revision: https://phabricator.services.mozilla.com/D162480
