While showing a doorhanger permisison prompt, if the user presses the ESC key
we call the secondary action callback, passing in whether any checkbox on
the popup notification was checked.
In the case of an autoplay-media permission prompt, we have a "remember"
checkbox, which is checked by default. So pressing ESC means the user will
remember a "block" result for the current site.
We believe that users don't expect pressing ESC to result in a remembered
decision, they expect pressing ESC to avoid making a decision. So we want to
ignore the checkbox when ESC is pressed for autoplay-media.
So this patch adds a new PopupNotification behaviour which reports the source
of event which caused the action callback to be called. This enables the ESC
key press to ignore storing a permission.
Note: the change here to not store a permission on ESC press applies to all
permissions, not just autoplay-media.
MozReview-Commit-ID: IUWFN8LG9VF
--HG--
extra : rebase_source : b004bc211177a7bfb6dcea563d75db9a6750b214
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
--HG--
extra : rebase_source : c525350a1954740873e85b045cbb14a8b43aa89d
I mistranslated the boolean success value of the old initListBuild
method. Simplifying it to just use a promise rejection should be
equivalent and simpler, since this is only run from the update
method of WindowsJumpLists, and the call sites for that don't do
anything afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D2244
--HG--
extra : moz-landing-system : lando
This fixes the tab throbbers not showing sometimes and not showing
the progress state in the all tabs menu.
MozReview-Commit-ID: FintGto9e9g
--HG--
extra : rebase_source : f83a0184e79be433d1f3e975d28e0f70a668a9c6
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
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
Also changes the tooltip on the home button to be independent of the URLs
it opens, per dolske.
Some tests explicitly set browser.startup.homepage, but only through
SpecialPowers.putPrefEnv. That's a good compromise, given the extra
functionality there.
MozReview-Commit-ID: FPLxzi3jQAP
--HG--
extra : rebase_source : c2b014f2fb1c78ce04859344bd1803ef48d5d68d
This ignores failures to get expiration data from favicon requests. It also adds
some safety to the rest of onStopRequest wrapping it in a try...catch block to
catch any unexpected errors and correctly reject the waiting promise.
Differential Revision: https://phabricator.services.mozilla.com/D1938
--HG--
extra : moz-landing-system : lando
Chris Pearce
Kris Maglione
Narcis Beleuzu
Michael Kaply
Cosmin Sabou
Tim Nguyen
Gijs Kruitbosch
Felipe Gomes
Mark Banner
Andreea Pavel
Shane Caraveo
Boris Zbarsky
Brian Grinstead
Dale Harvey
shindli
trisha
Doug Thayer
Alex Chronopoulos
Margareta Eliza Balazs
Mark Striemer
Oriol Brufau
Tiberius Oros
Julian Descottes
Ursula Sarracini
Axel Hecht
Dave Townsend
Michael Kelly