We may not really receive a dragend event if we're fast enough.
Calling _onDragEnd multiple times is fine (it should be idempotent).
This particular exception was added in bug 978084 along with all the _onDragEnd
calls, but I don't think it's sound over-all.
I don't really want to dig into the XUL button code to see why drag end was
consistently firing there, unless you think it's really really needed :)
Differential Revision: https://phabricator.services.mozilla.com/D2019
--HG--
extra : moz-landing-system : lando
This was causing an empty message to appear in the
browser console when clicking the clear button.
This specific call was introduced 5 years ago without
much explanation, and since the error console is now
gone, I think it's safe to remove the call.
A test is added to make sure we do not print any extra
messages when clearing the browser console.
Differential Revision: https://phabricator.services.mozilla.com/D2551
--HG--
extra : moz-landing-system : lando
Fix the clear() call to clear highlights in addition to the selection.
MozReview-Commit-ID: 1DNXa8fIGTP
--HG--
extra : rebase_source : c84033c644becf2c9b0e7df8d2580523e75de97d
This copies over the early-exit conditions from MaybeDrawTitlebar which
is the non-WR codepath where this gets drawn. In particular, the
!mIsCoveringTitlebar clause is true when the titlebar is enabled.
MozReview-Commit-ID: 6B7vKYuyrRP
--HG--
extra : rebase_source : b8f73d2c4f9e582bdb018e6aa121e92d54c60334
Checking if file upload works for files from different folders
is outside the scope of the wdspec tests. As such those tests,
and the `createFile` fixture can be removed.
MozReview-Commit-ID: DJ2seBjinxZ
--HG--
extra : rebase_source : 89bb61fa853cafece776534603aff62257de74f6
Re-enable the test that was disabled in bug 1381305 and fix the
underlying issue that caused th intermittent failure in the first place.
MozReview-Commit-ID: BL9wS2fogaf
--HG--
extra : rebase_source : 685f43b2e47d80f71814385a5c8b94fd3000eac9
This ensures that the check that was introduced by bug 1370499 still
continues to work even though it was refactored by the previous commit.
MozReview-Commit-ID: GdbIPA6vxIB
--HG--
extra : rebase_source : 9246a1d6855de45eca8de5ee806d3a3e5ab7f0be
This allows to create NetworkEventActor directly from the parent process
and avoid most of the data being piped from the parent to the content processes.
MozReview-Commit-ID: 8p3A5yl5eVB
--HG--
extra : rebase_source : 3f022b2be7d1ab79c926ad9302e9ee232acc48b2
The loop was mutating the nsCSSPropertyID used to guard the exit, which is
obviously wrong.
This branch is pretty rarely taken, since people don't usually specify `all` as
a transition property other than the first, for which case we take the fast path
with `checkProperties = false`. Our test-suite failed to catch this.
Added a crashtest that hangs without this patch.
The reason bug 1478990 regressed this is because it changed the order of
nsCSSPropertyID so that `p` actually went backwards causing the infinite loop,
but the bug was introduced (by me, whoops) in bug 1309752.
Differential Revision: https://phabricator.services.mozilla.com/D2552
MozReview-Commit-ID: Ii3D1FaZ31R
--HG--
extra : source : 78be4bbf4b050f6614bb9f4115f57fb61f4890df
This is generally helpful. I'm also seeing much less than 50% of the
wrQualified people in the study getting webrender so this could help
determine why.
MozReview-Commit-ID: 2neTFBytzPz
--HG--
extra : rebase_source : 97b1b1fe80f1a2c574141eaef8ad23499699fb82
