Right now, the firstPartyDomain won't be set when using IP addresses as
first party domains. It is because of that the TLD service won't accept
IP addresses as valid hosts. The patch fixes this problem by detecting
that if the host is a IP address. If it is, we will still set the
firstPartyDoamin with the IP address.
Differential Revision: https://phabricator.services.mozilla.com/D1977
--HG--
extra : moz-landing-system : lando
We can start playing while we're awaiting a response to an autoplay-media
permission prompt, for example if the user clicks on a play button. In such
cases, it doesn't make sense to keep the autoplay permission request promise
connected in HTMLMediaElement, as since we're playing we'll be resolving the
play() promises and thus we won't be taking action on the autoplay request
promise's result. So we should just disconnect the autoplay permission request
promise if it's connected when we start playing.
MozReview-Commit-ID: 1aiCLXV7Ja9
--HG--
extra : rebase_source : c439e8f084ac8cc01db578d712e15d3174a08e71
If we're showing a permission UI prompt for "autoplay-media", the user can
still actually play media without interacting with the doorhanger; if they
click a "play" button in the document, they'll "gesture activate" the document
and unblock autoplay and be able to start playback.
It doesn't make sense to keep showing the permission doorhanger to approve
autoplay when the page is already playing, as playback has already started, and
if they clicked on "block" then the site would receive a promise reject on the
promise returned on the first call to HTMLMediaElement.play() for which we were
showing the permission prompt for, even though the media is actually playing.
This will likely confuse JS video players.
So we should hide the permission prompt when playback in the page starts.
MozReview-Commit-ID: 1XU47AfT6vf
--HG--
extra : rebase_source : 3d5c164527e26ba8f58f0baac3474d5b2d7fb587
We're already committing jump lists on mIOThread, and I see
no errors or problems with initting on mIOThread either, so
I think this is okay. Had to restructure some things to
make using a Promise simple, and to avoid dispatching to
mIOThread from within mIOThread (since we can only dispatch
to a LazyIdleThread from the owner thread).
MozReview-Commit-ID: 1imBF8Jzmn6
--HG--
extra : rebase_source : 4f912e819cec898910e72d95311e3924714a3090
This is just the js side of the equation for initting jump lists
on a background thread. It should just be functionally equivalent
to the old code with the exception that it works asynchronously
on a promise of an array of urls rather than an nsIMutableArray.
MozReview-Commit-ID: 2handMr6FWS
--HG--
extra : rebase_source : bcd71b96778a3bbcc141513c9e5b0213accf8705
Now that all properties handle currentcolor via mozilla::StyleComplexColor,
unify test_currentcolor_transition() and test_true_currentcolor_transition()
into test_currentcolor_transition().
MozReview-Commit-ID: 81hlAgTotpL
--HG--
extra : rebase_source : 0c77a60918a365eb907327e16ff7253df955cf17
Changing to Stylo for animation of color with currentColor. Stylo uses
a different distance metric for numeric colors to currentColor. The
result is that a different pacing is used in the fill case.
MozReview-Commit-ID: 5x8c3IF5owV
--HG--
extra : rebase_source : fd1656237fd5df03481e410bae29167df2317536
Before this patch, there is a race condition that the refresh driver updates
the most recent refresh time but animations corresponding to the refresh driver
don't update their internal state, that causes the inconsistency that such
animations are regarded as finished on the most recent time whereas their
internal states represent the animations are still in active. This is the one
of the cause of bug 1466010, i.e. the display item corresponding to the
animation is going to be rebuilt without calling MarkNeedsDisplayItemRebuild.
MozReview-Commit-ID: 9adzDV9E3ka
--HG--
extra : rebase_source : 7120e9f462309d1c4efe995ef64aeead9e29ff8f
This patch adds a new IPDL protocol PBackgroundLocalStorageCache. It is used by LocalStorageCache object to broadcast changes in local storage cache to other content processes. Each origin has its own PBackgroundLocalStorageCache, so now we can notify content processes that actually have a local storage cache for given origin. This greatly improves performance and reduces memory footprint especialy when local storage changes carry big strings and/or happen very quickly (before this patch all child processes were blindly notified).
Updated rsdparsa to 75d5c6df6728fbab502db06940062e0358536f9f from github
upstream
MozReview-Commit-ID: 9hr7DV6KTkK
--HG--
extra : rebase_source : c5b2c003e76489e267390402ebb5947cf3ec48b6
This fixes a regression from bug 1454640 where urls had an extra 'docs' path inserted into them, e.g:
toolkit/components/telemetry/telemetry/index.html
became:
toolkit/components/telemetry/docs/telemetry/index.html
Differential Revision: https://phabricator.services.mozilla.com/D2079
--HG--
extra : histedit_source : 15c679e2f9366c1ea424adc4c82d7c184d80b3bb
This uses the same event handling as the "listbox" and "listitem-checkbox" bindings that are scheduled for removal, and copies the required styles locally.
There is no need to preserve the scroll position explicitly anymore, because "richlistbox" handles scrolling like regular elements, and we don't want to persist the position when the selector is closed and reopened.
MozReview-Commit-ID: 4gYhwlprPN7
--HG--
extra : source : a92f9683c6cdaeb5541b85eb77adf46448716a7b
Support for "listbox" in preferences is also removed, in preparation for the removal of the "listbox" element and binding.
MozReview-Commit-ID: Bi2VKKi5rdk
--HG--
extra : source : 762819bac1b9efe0e939be07394bd7d293638c40