We were using a StaticRefPtr without it being fully defined for
SystemGroupImpl::sSingleton, resulting in a non-unified build failure.
MozReview-Commit-ID: AgSuVvGTri7
--HG--
extra : rebase_source : 906e30e8c2c21e13a045a941e9d92e1d2d2af079
- Send a ping when user type in "Home page" box.
- String is longer than 4 letters and with at least one ".".
- String is not deleted after 3 seconds.
- Send a ping when "Use Current Page" is clicked.
- Send a ping when "Use Bookmark" is clicked.
- Send the number of "|" is detected in "Home page" box.
MozReview-Commit-ID: 6bYK0eCkYym
--HG--
extra : rebase_source : 8ead54eff6e34fb8cc33d8a0a9d463902ed534e7
Warn about duplicated conditions in if-else-if chains, which are unreachable code and likely copy/paste bugs. The -Wduplicated-cond flag is available in gcc 6 and later.
int example(int a)
{
if (a == 0)
a = 42;
else if (a == 0) // -Wduplicated-cond warning!
a = 43;
return a;
}
MozReview-Commit-ID: F9hqxMCct74
--HG--
extra : rebase_source : 71168f79ce8f03f650167cdedbbd2e5802846eab
The issue is: when we hit some failure conditions in DragCaretInternal()
such as the frame is not selectable, or no frame is under the point, etc.,
we'll early return so that the auto scroll code is not being executed.
The logic in StartSelectionAutoScrollTimer() is similar to how
nsFrame::HandleDrag() handles the auto scrolling.
MozReview-Commit-ID: FtXZ8BWp3BX
--HG--
extra : rebase_source : 9526c10987286316ac76c536cc9086de65931797
We don't need to check GetFrameSelection() because valid GetSelection()
implies valid GetFrameSelection().
MozReview-Commit-ID: 9WH7HxN27yF
--HG--
extra : rebase_source : 0d97ae57600b239a4beb48580f74bf20d6137be5
The malloc_spin_* functions have ended up being strictly identical to
the malloc_mutex_* functions, so use the latter instead of the former.
--HG--
extra : rebase_source : 746bdf57cb4a33fd65335174a748cb567630e05b
This doesn't actually help https://bugzilla.mozilla.org/show_bug.cgi?id=1405411 but seems like something we should do.
Source-Repo: https://github.com/servo/servo
Source-Revision: b1c7a2fa6dd94bde092bc4d9baed456e7a8bf45b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : dd7195b7cfaef114f69ace40a53bafeb6c335c05
This is the Servo side change of [bug 1401825](https://bugzilla.mozilla.org/show_bug.cgi?id=1401825).
Source-Repo: https://github.com/servo/servo
Source-Revision: 3c6e7b56c3469d29df8f6ff3332f50e447671d91
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4b570a20513ce9bef7e4a4c653293376647ee740
Refactor SafeBrowsing code so we can get the payload of gethash/update request when
updates fail.
MozReview-Commit-ID: NB1oacd185
--HG--
extra : rebase_source : 87e7ce94fd5cde9697946a00de90a821e5561168
The first AsyncCubebTask dispatch from AudioCallbackDriver::Start() may either
be from MediaStreamGraphImpl::RunInStableState() on the main thread or
ThreadedDriver::RunThread() on a threaded driver thread.
These could potentially occur concurrently when there are multiple
MediaStreamGraphs.
This change removes the race around setting sThreadPool.
SharedThreadPool::Get() would have returned the same pointer, and so
that race was probably mostly benign apart from the potential to add an
extra reference and so hang on shutdown in SharedThreadPool::SpinUntilEmpty().
Storing the reference to the SharedThreadPool on the object using it is the
typical way to use SharedThreadPool. It lets the thread pool be released when
not in use, and lets SharedThreadPool deal with multi-thread access and
shutdown.
MozReview-Commit-ID: 8WutVsAMfJo
--HG--
extra : rebase_source : a3d0ce75d65889fff47389ccd80640c3f1150244
