The test failing intermittently on test-verify jobs seems to be only the one that covers the newly added
Glean timespan metric named "extensions.startupCacheLoadTime".
Given that it seems to be only failing in test-verify jobs, and with the Glean metric set to a numeric value as expected
just not always a non-zero value as the test expectes, I suspect it may be because the startupCache is technically
empty or only including a pretty small amount data and so it may be able to be loaded so fast that the resulting
value is 0 milliseconds.
I'm unable to reproduce the same locally even when running the test locally using --verify, and so this patch
is actually relaxing the failing assertion to only check that the Glean metric value is numeric and the
mirror scalar is set to the exact same value, and in addition to that the test is not reseting the FOG data
and assert that the Glean metric is initially undefined until we expect it to be collected and set to a numeric value.
Differential Revision: https://phabricator.services.mozilla.com/D145904
I chose to write a minimal test case and defer more test coverage to Bug
1723763 since this bug already existed. The change in `ext-android.json`
is similar to what has been done in D113461.
Differential Revision: https://phabricator.services.mozilla.com/D146061
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
My previous patch for bug 1755570 contained an oversight that caused
problems when deleting history downloads' target files. This patch just
adds a minimal data removal method to the history download prototype,
so the DownloadElementShell methods can execute without exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D145279
The failures are triggered by the pending request used by the initial four test cases, due to the pending request
being aborted (after all the tests in the test file have been executed and the test harness executes all the
registered cleanup functions) and its related promise rejection not being caught by the test itself.
Apparently the failures seems to be able to be triggered more often on windows builds, but I have been able to trigger it
on Linux using --verify even if way less often then on Windows (where I was able to trigger the failures consistently
by running the test file once and without --verify).
The attached patch prevents the failure by explicitly:
- handling the promise rejection (by catching the rejection, emit a log if the rejection is the expected one and
trigger an explicit failure nearby where it is triggered otherwise, to make it easier to investigate other issues
in the future if needed, by prevent the rejection to become silent and by triggering a failure easier to be
correlated with what is actually triggering it)
- clearing the last pending request created right at the end of the test task that has created it (mainly to avoid
keeping the request active if the related test is already exiting)
Differential Revision: https://phabricator.services.mozilla.com/D145958
My previous patch for bug 1755570 contained an oversight that caused
problems when deleting history downloads' target files. This patch just
adds a minimal data removal method to the history download prototype,
so the DownloadElementShell methods can execute without exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D145279
Change tests and snippets in documentation to use `Date.now()` instead of an arbitrary number like `42`.
This way, we make sure the packaged dump isn't loaded on top of the tests data. Indeed, since Bug 1718083 we load the packaged dump if it's newer than local data.
Differential Revision: https://phabricator.services.mozilla.com/D145579
Even if `<datalist>` is dynamically changed, autocomplete controller still uses
previous search result. If changed, we have to ignore previous result that may
be invalid.
Also, even if `<datalist>` is changed, we have to keep selected index (Bug
595069), so we cannot use `ResetInternalState` at this situation. It resets
selected index.
Differential Revision: https://phabricator.services.mozilla.com/D116679
updated patch for android_hardware_unittests.py, asking for a review- please look at the interdiff to see recent changes.
Differential Revision: https://phabricator.services.mozilla.com/D144985
criss
Luca Greco
William Durand
Emilio Cobos Álvarez
M. Sirringhaus
Calixte
Jan-Erik Rediger
Bob Owen
Noemi Erli
Cristian Tuns
Travis Long
Nika Layzell
Nick Alexander
Benjamin VanderSloot
Thomas Wisniewski
Shane Hughes
Nico Grunbaum
Chris H-C
Mark Banner
Joel Maher
Punam Dahiya
Andreea Pavel
Sergey Galich
Butkovits Atila
Mathieu Leplatre
Sarah Clements
Yoshi Cheng-Hao Huang
Gabriele Svelto
Makoto Kato
Kagami Sascha Rosylight
Marian-Vasile Laza
Katherine Patenio