Basically, this patch does three things as following:
1. Limit the scope of service worker to the controlling document so that it
won't influence other tests.
2. Ensure to catch the channel to controlling document if it's an internal
redirect. We should get two channel with the response.URL(The first one for the
service worker and the second one for the controlling document). Distingulish
them by the order.
3. Ensure to get the controller change event after posting the "claim" message
to the service worker.
--HG--
extra : rebase_source : fb2395fb6dce59ae0fd49b0b915aca52c78206e0
Summary:
In very rare situations, the right number of tabs and the right drop position
will lead to the drop event handler trying to start a translateX() transform
and then wait for the transitionend event that will never fire.
If the old and the new translateX values are too close together (e.g.
1259.1000061035156 and 1259.0999450683594) then the layout engine won't
actually start a transform.
A simple solution is to round translateX values before comparing them and
deciding whether to initiate a transition.
Reviewers: mconley
Reviewed By: mconley
Bug #: 1396833
Differential Revision: https://phabricator.services.mozilla.com/D265
--HG--
extra : amend_source : f1427cfe4c30066373b1acbd0d4017d8a02bc0ac
In practice we always use the same functions for these purposes.
MozReview-Commit-ID: 4Be9pRhUeff
--HG--
extra : rebase_source : 3dfafd9479371d3a47ec263a66942ddbfbefdb46
This patch makes it a proper class, and moves existing functions into it.
MozReview-Commit-ID: 5pbT3ljq44R
--HG--
extra : rebase_source : ac7ba98f9d39b3cd6f71498a5e108cb6757034e0
And use new/delete for them. And make mDomain a unique pointer so it doesn't
need explicit deallocation.
MozReview-Commit-ID: E1jLccXaSwT
--HG--
extra : rebase_source : 5a64135d5471297ab98f8ec4557f66dac8b7eff9
Maybe<PrefType> is a better way of representing "no type".
MozReview-Commit-ID: Fnha5RxbNg4
--HG--
extra : rebase_source : 8e8322b0443305ab71acd6d98ea2607f626c5bce
This field isn't accessed outside PrefHashEntry.
MozReview-Commit-ID: IvwQe5UtjjJ
--HG--
extra : rebase_source : 5447d4e24bbf0d0637ee29377cc749b9b77b4e1e
We can move the setting into ReplaceValue() and ClearValue(), and then those
methods aren't needed any more.
The patch also removes some getter calls within PrefHashEntry by directly using
field names.
MozReview-Commit-ID: 42EAx1Kh9Et
--HG--
extra : rebase_source : 3393a80a9c5d2d7c660171cdda8d3914c35e96ea
There's an "XXX" comment suggesting a possible leak when string user values are
cleared. Turns out a lot of the time there won't be a leak, because the string
pointer isn't overwritten and ClearEntry() frees the string when the pref is
destroyed. However, if the user value is subsequently overwritten with a
different string, there will be a leak. Also, even in the non-leak case, we
currently hold onto the string for longer than necessary.
This patch introduces ClearUserValue() -- which frees the string when
appropriate -- and uses it in all the places where values are cleared.
MozReview-Commit-ID: ARuWUNzPTfy
--HG--
extra : rebase_source : 4567e37ba96ba3b4ae9b1972d887eeaed1257cb0
Specifically:
- rename it as NotifyCallbacks();
- remove the return value, because it is always NS_OK;
- some minor naming and declaration clean-ups.
MozReview-Commit-ID: GcH81owPLsp
--HG--
extra : rebase_source : 501a85f76bb823cc45dba8e4601584f5218b1a9e
Andrea Marchesini
Ciure Andrei
Emilio Cobos Álvarez
Tim Taubert
Tom Tung
Jan de Mooij
Nicholas Nethercote
Milan Sreckovic
Adam Gashlin
Lucius Q. User
Matt Woodrow
sotaro
Timothy Nikkel
Coroiu Cristina
Bas Schouten
ffxbld
Henri Sivonen
Jonathan Kew
hrdktg
Tiberius Oros