This adds support for a "post-prompt" that appears dismissed (only the icon showing) when
the browser decides to automatically deny a permission request from a site (either based on
internal heuristics or because the user prefers not to receive permission prompts).
In order to move quickly and not overload the patch I have only implemented the post-prompting
for desktop-notification so far, however, implementing it for other permissions should be
a trivial follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D25415
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
We've handle showing the blocking icon in patch2, so we don't need to set block permission in PermissionUI.
Differential Revision: https://phabricator.services.mozilla.com/D14797
--HG--
extra : moz-landing-system : lando
We've handle showing the blocking icon in patch2, so we don't need to set block permission in PermissionUI.
Differential Revision: https://phabricator.services.mozilla.com/D14797
--HG--
extra : moz-landing-system : lando
This is an attempt to fix a Talos regression caused by the cost of URL
parsing. The approach I'm taking here is to modify the requirements of
bug 1509047 part 2 slightly so that I can remove the expensive code
which resulted in the Talos regression.
The change in behaviour is that the automatic access grants for the
Storage Access API will use the number of unique domains visited in the
session as opposed to the number of unique origins visited.
Differential Revision: https://phabricator.services.mozilla.com/D14156
--HG--
extra : moz-landing-system : lando
Normally, permission prompts would define a permissionKey attribute in order
to get integrated with SitePermissions. Since SitePermissions is internally
hooked up to TemporaryPermissions, such permission prompts do not need any
extra handling for taking benefit from the temporary permissions infrastructure.
For the Storage Access API, however, we're not going to use SitePermissions,
and instead Gecko will be in charge of defining the required permissions in the
permission manager database when the prompt is responded to with an Allow
action. This means that by default we won't be integrated with the temporary
permissions setup either.
This patch allows prompts to define a new way to opt out of reading and writing
permissions through the permission manager but still being integrated with
temporary permissions. That is, through returning false from the new
usePermissionManager attribute and returning a name from the permissionKey
attribute. TemporaryPermissions will do the expected work in order to ensure
that each prompt with a unique key will be automatically blocked if a previous
instance of the same prompt type with the same key has been blocked in the
current tab.
Note that this doesn't yet include support for showGloballyBlocked or
permitTemporaryAllow since those features aren't needed for our use case.
Differential Revision: https://phabricator.services.mozilla.com/D12466
--HG--
extra : moz-landing-system : lando
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
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
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
These issues were previously ignored due to the nature of our global import
rules. They need to be fixed before that rule can be updated.
MozReview-Commit-ID: DCChktTc5TW
--HG--
extra : rebase_source : cffb1c9762191c579d1397c8169e6e7635d229da
extra : histedit_source : dea59ddd2daaae52069c5faceae9149a4f08dd73
Johann Hofmann
Boris Zbarsky
Liang-Heng Chen
Mihai Alexandru Michis
ui.manish
Razvan Maries
Narcis Beleuzu
Ehsan Akhgari
Kris Maglione
Ciure Andrei
alwu
Bogdan Tara
prathiksha
Mark Banner
Dale Harvey
Chris Pearce
Luca Greco
Sebastian Hengst
Florian Quèze
Kyle Machulis