mStreams should only ever be accessed on the MSG thread. However, under some shutdown circumstances, it can be accessed on the main thread while the MSG thread is still alive.
This will be corrected in bug 1408276.
MozReview-Commit-ID: 6xWzxxV1Dv3
--HG--
extra : rebase_source : bce92961609da6ea8609ec8ada5a8a30263a84c9
mForceShutdownTicket and mShutdownTimer are only ever accessed on the main thread. We don't need the use of the monitor to reset them.
MozReview-Commit-ID: 1DL8bLmzEH5
--HG--
extra : rebase_source : 84d56c7f4428143426cd22e88ef2912330efba4e
We only access mLifecycleState via a helper which strongly enforced how the member can be accessed.
Two non-safe accesses are corrected.
MozReview-Commit-ID: 6LYk7t4rSyB
--HG--
extra : rebase_source : 9727771e1b04ba1b39f5cf9a6cf94093b7e92b27
They are accessed across multiple threads without the use of monitors.
While it could be argued that some use of the monitor in functions accessing those members would set in place memory barriers, making them atomics remove all doubts as to the thread safetyness of their use.
MozReview-Commit-ID: tyTqeGgDNM
--HG--
extra : rebase_source : 420c38abcfeaa5fca2449034d8e1e3d82949d49d
Describe which members are accessed on the main threads. Other members are only accessed on MSG thread.
MozReview-Commit-ID: CFU4ipRHB1P
--HG--
extra : rebase_source : ad4843da513997a633d2d402384f9478df29c3a7
This uses a similar strategy as that employed by moz_places_afterdelete_trigger,
creating a temp table which we write host inserts into, and then deleting all
the rows from it when we're done inserting, effectively resulting in a per-
statement trigger to only do the significant work per host.
MozReview-Commit-ID: 5TUueknq3ng
--HG--
extra : rebase_source : 1892edfcaa7b6afd29ce794a93d6ab3d46c48895
These methods are instantiated by the Gecko library, and used during
querySelector, which means that they end up being super-hot in micro-benchmarks.
MozReview-Commit-ID: K1XJb0QyX5a
Source-Repo: https://github.com/servo/servo
Source-Revision: 85fa6409bb699647b4f5e22952538365e87418d7
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 156224040ad2191714b888e91c9b555e7efc9bb6
Switch some calls to addOneTimeListener from callback-style to Promise.
MozReview-Commit-ID: F9AlSvK0MAH
--HG--
extra : rebase_source : 076522e89004f8a4634b4f7732800a5ec14ce633
Enable browser.tabs.drawInTitlebar on all platforms.
MozReview-Commit-ID: 9lko61izj4r
--HG--
extra : rebase_source : c4fd8dbf9d4a0eed78d3ac2a7a25bf36988c6f13
Once the test was migrated, it was failing because we did not show
error messages for invalid cd() calls.
There was a missing part in the evaluation result prepare message, which
this patch fixes. A stub and a mocha test were added to make sure we do
display those kind of messages.
MozReview-Commit-ID: FcTsP2pr3vD
--HG--
rename : devtools/client/webconsole/new-console-output/test/mochitest/test-bug-609872-cd-iframe-child.html => devtools/client/webconsole/new-console-output/test/mochitest/test-cd-iframe-child.html
rename : devtools/client/webconsole/new-console-output/test/mochitest/test-bug-609872-cd-iframe-parent.html => devtools/client/webconsole/new-console-output/test/mochitest/test-cd-iframe-parent.html
extra : rebase_source : 8fc82b71875cebfed0e318d1eba8b5332dc650c7
This is cleanup that allows me to fix https://bugzilla.mozilla.org/show_bug.cgi?id=1415013 in a more straight-forward way.
Source-Repo: https://github.com/servo/servo
Source-Revision: d117694eccc8d8f89d14213e88a9931d3adee572
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6c775f7727561cf39ddf0f84f454d6b24d90f975
The WaitForDataPromise cannot be resolved even when key has been updated and decode request has be resolved.
2 ScheduleUpdate(NotifyTrackDemuxer, NotifyNewOutput) are merged into 1 so that only mReceivedNewData is set to false again but MFR will
never have a chance to trigger another Update to call CancelWaitingForKey.
By refactoring the condition to resolve the WaitForDataPromise, MDSM is able to request new data and MFR is able to cancel waitingforkey then continue the flow.
MozReview-Commit-ID: 31brwzOoUvF
--HG--
extra : rebase_source : 8caf8b426dd693e2806ebb8a059a3b91026d7f52
This should fix [bug 1417207](https://bugzilla.mozilla.org/show_bug.cgi?id=1417207).
Source-Repo: https://github.com/servo/servo
Source-Revision: b2c19b15447b126cbcb4726fccb416675532dd11
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 9f8e1b678e8944ba254e774e98b472b65a14018b
ReturnInListItem and ReturnInHeader uses Element as parameter, but
ReturnInParagraph doesn't use Element parameter even if it is Element.
So we should use Element for parameter.
MozReview-Commit-ID: 35JJTETFK45
--HG--
extra : rebase_source : aa101c921d176b7ae7807c461bca1c4a51f9aecc
Jean-Yves Avenard
Simon Sapin
Grigory Kruglov
Tim Nguyen
Shane Caraveo
Jan Henning
Tarek Ziadé
Doug Thayer
Brad Werth
Dale Harvey
Emilio Cobos Álvarez
Nicolas Chevobbe
Dão Gottwald
Andi-Bogdan Postelnicu
Alessio Placitelli
Martin Stransky
Michael Froman
Michael Ratcliffe
Kilik Kuo
Xidorn Quan
Valentin Gosu
Ray Lin
Mark Banner
Cameron McCormack
Ricky Chien
shindli
Margareta Eliza Balazs
Jon Leighton
Julian Descottes
Makoto Kato