Previous design allows us calling resume/block from both front-end and back-end,
it's not easy to know who called these operations.
So move all these logic to frond-end side, it's more clear than before.
One important thing is that we should block tab before loading the content.
If we block the tab after loading, the media might not be blocked because it had
already started (that is one situation I observed from test).
The value of block state would be stored in the outer window, before media want
to start, it would check this value to know whether it can start playing or not.
---
In addition, introduce new attribute "media-blocked".
The "media-blocked" attribute indicates that whether the tab is allowed to play autoplay media.
The "activemedia-blocked" attribute indicates whether the tab has blocked the autoplay media.
MozReview-Commit-ID: FnNh3zmItxo
--HG--
extra : rebase_source : cdc890c0c47a4a03ea8dbbdfee24c66b52945c60
Since now we move the block/resume logic to front-end side, we can remove
the changing from bug1319771 and other related bugs which are used to ensure the
pinned tab should be blocked successfully after session restore.
MozReview-Commit-ID: Ixe7tOvCEhv
--HG--
extra : rebase_source : 190e63b5df53c85f7282b5c2144ae7e7830d7ad3
This uses XPCOM to replace the default process selector with one that always
asks for a new process and then put the old one back again. This comes with a
test to prove that it works.
MozReview-Commit-ID: Bq6KP4VzP7W
--HG--
extra : rebase_source : a42662d67f7eeca8bc5870d3c70c086abf582164
This was originally added in bug 1133439 but it's not clear that it is needed.
It may be that we thought that new SMIL animations should trigger transitions
but that's not the case.
We want to remove this as part of this bug since Servo_NoteExplicitHints is
currently not capable of handling animation restyle hints and non-animation
restyle hints at the same time.
--HG--
extra : rebase_source : 729947c29efc51864333397cf772079646c1f197
Perhaps, test_nsITextInputProcessor.xul is copied from another file and I failed to remove unnecessary code. That might cause stealing focus from child window and preventing to run waitForFocus().
MozReview-Commit-ID: 5Sym3mcauH7
--HG--
extra : rebase_source : 9a9118f29b64f223935d1199645425a75a936daf
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
This patch implements chrome-only Selection#setColors and
Selection#resetColors methods, and use it to set the background color of
the preferences search highlight.
MozReview-Commit-ID: 2U92aBCAyeh
--HG--
extra : rebase_source : b07af1f37309d8184584b298a720cd5c1382929a
Previously, we cleared mCachedRootElement a bit later -- after removing *all*
of the children and calling nsNodeUtils::ContentRemoved() and UnbindFromTree on
each of them. This was problematic, because these cleanup functions can
involve calls to GetRootElement() -- and prior to this patch, any such
GetRootElement() calls would likely return the stale value in
mCachedRootElement.
Now, with this patch, we'll be clearing mCachedRootElement
sooner, so these GetRootElement() calls will return the correct current root
(which will likely be null in this case, since we're emptying the document of
children).
MozReview-Commit-ID: 8skGJyic1pC
--HG--
extra : rebase_source : 2a1c3880c676123b2bfa9dd21ae296e663ba6a38