I made the variable name up, since I didn't see another similar thing.
Let me know if I should change it.
Differential Revision: https://phabricator.services.mozilla.com/D4239
--HG--
extra : moz-landing-system : lando
Waiting for the browser to have switched remoteness before waiting for
it to load the non-about:preferences page should be enough to address this orange.
Differential Revision: https://phabricator.services.mozilla.com/D4208
--HG--
extra : moz-landing-system : lando
This also moves the call to 'fetch_artifacts' in run-task down inside the
try/finally block. This way if something goes wrong, we'll still cleanup
MOZ_FETCHES_DIR.
Differential Revision: https://phabricator.services.mozilla.com/D4152
--HG--
extra : moz-landing-system : lando
Oddly, on 63 Beta simulation, nsIDocument::GetWindow() may return nullptr
when HTMLEditor is being destroyed by unload of the page. I'm not sure if
this is an expected change. However, HTMLEditor::HideResizers() should
not stop cleaning up even if it meets unexpected situation.
Additionally, this patch moves all HTMLEditor members related to resizers
to local variables since while HideResizers() is cleaning up old resizers,
the members may be overwritten by ShowResizers() if mutation event listener
or something does something.
Differential Revision: https://phabricator.services.mozilla.com/D4057
--HG--
extra : moz-landing-system : lando
So that explicitly disabling TRR for specific resolves won't end up just
using the cached entry resolved with TRR!
MozReview-Commit-ID: HZ4AyKOMpet
Differential Revision: https://phabricator.services.mozilla.com/D4215
--HG--
extra : moz-landing-system : lando
We rename a method in FrameStatistics to better match what it's actually doing.
Differential Revision: https://phabricator.services.mozilla.com/D4213
--HG--
extra : moz-landing-system : lando
Count number of requests/streams per connection done when the connection
was used for TRR.
MozReview-Commit-ID: 50NVSCcd6jy
Differential Revision: https://phabricator.services.mozilla.com/D4083
--HG--
extra : moz-landing-system : lando
This change means that the #pocket-button-box hbox is pruned from the accessibility tree as it should be.
Normally, hbox elements aren't exposed to accessibility, as they are semantically meaningless.
However, this code was previously setting aria-label on hbox elements, which forces the hbox to be exposed to accessibility.
Differential Revision: https://phabricator.services.mozilla.com/D2987
--HG--
extra : moz-landing-system : lando
When dealing with an editor which contains multiple accessibles, the previous spelling error range might be in a previous accessible, not the accessible currently being queried.
In this case, DOMPointToOffset will return the length of this accessible.
Previously, we weren't checking for this and were overriding the start offset of the returned range regardless, resulting in broken offsets.
Now, we leave the start offset alone in this case.
Differential Revision: https://phabricator.services.mozilla.com/D3960
--HG--
extra : moz-landing-system : lando
Screenshots moved from a Photon page action to a pure WebExtension page
action, but this move introduced some UI bugs where the two page actions
behave differently. Since this change isn't needed for 63, seems better
to just temporarily revert.
Differential Revision: https://phabricator.services.mozilla.com/D4162
--HG--
extra : moz-landing-system : lando
Wait for Search services to initialize before we try to access any properties
Differential Revision: https://phabricator.services.mozilla.com/D4150
--HG--
extra : moz-landing-system : lando
This is the fix for the bug. In this case, the top-level principal is
picked from the loading principal of the load info object, and it is
different from the triggering principal.
Since we already fall back to the triggering principal while computing
the top-level principal, there is no need to do that explicitly here.
In fact we need all of the same rules as previously implemented above
in the same function, so we may as well use the toplevelPrincipal
variable.
I couldn't think of a good way to write a test case for this, sadly.
The transition property in this test is shorter than the period of chaging
parent viewport height so that it's possible that a new transition happens
after a transitionend event was dispatched. The new transition will reduce
the element width (i.e. it's opposite direction of the first transition),
so the transitioned yellow box was smaller than the expected result.
Differential Revision: https://phabricator.services.mozilla.com/D4183
