On Wed, Jun 29, 2016 at 2:07 AM, Jonas Sicking wrote:
>
> Awesome! Do we have a restriction that pointerlock can only be entered
> during a user action, like a click?
>
Yes.
> And do we completely forgo the warning when the webpage is already in
> fullscreen mode?
>
Yes, that's the plan.
- X
Awesome! Do we have a restriction that pointerlock can only be entered
during a user action, like a click?
And do we completely forgo the warning when the webpage is already in
fullscreen mode?
/ Jonas
On Thu, Jun 23, 2016 at 2:47 AM, Dale Harvey wrote:
> In https://bugzilla.mozilla.org/show_b
Yay! Thank you :-)
--Jet
On Thursday, June 23, 2016, Dale Harvey wrote:
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1273351 I am working on
> removing the pointerlock permissions UI, now instead of a doorhanger
> permission that the user needs to respond to before entering pointerlock,
>
In https://bugzilla.mozilla.org/show_bug.cgi?id=1273351 I am working on
removing the pointerlock permissions UI, now instead of a doorhanger
permission that the user needs to respond to before entering pointerlock,
the pointer lock will be granted with a warning given to the user
explaining how to
On 05/03/15 07:40, Anne van Kesteren wrote:
> This would require everything that's like github.io to register as a
> public suffix.
github.io already is a public suffix :-) If some private entity is
handing out subdomains to mutually-untrusting 3rd parties, there are a
number of reasons they shou
Le 5 mars 2015 à 06:54, Jonas Sicking a écrit :
> Also, we might want to do something similar for permissions. It's
> somewhat annoying if a website can keep asking for geolocation by
> simply using new subdomains to do so, even if the user repeatedly
> clicks "no" and "remember this decision".
On Wed, Mar 4, 2015 at 10:54 PM, Jonas Sicking wrote:
> Also, we might want to do something similar for permissions. It's
> somewhat annoying if a website can keep asking for geolocation by
> simply using new subdomains to do so, even if the user repeatedly
> clicks "no" and "remember this decisio
On Tue, Mar 3, 2015 at 11:36 PM, Anne van Kesteren wrote:
> On Wed, Mar 4, 2015 at 12:48 AM, Justin Dolske wrote:
>> I don't actually think about:permissions is a good start, or that it's
>> implemented "most of the complicated bits." Quite the opposite, really: it
>> was a useful experiment, but
I don't actually think about:permissions is a good start, or that it's
implemented "most of the complicated bits." Quite the opposite, really: it
was a useful experiment, but has some serious problems. I'd briefly
summarize the two main flaws as (1) "manager" UIs are generally not great
(they provi
(Added dev.platform back.)
On Tue, Mar 3, 2015 at 7:04 PM, Shane Caraveo wrote:
> I tend to agree with Gerv, there should be an overly simplistic top level "I
> trust [social network name] to do something wrong but let them do it anyway"
> setting with a way to dig into more detailed settings if
On Wed, Mar 4, 2015 at 12:48 AM, Justin Dolske wrote:
> I don't actually think about:permissions is a good start, or that it's
> implemented "most of the complicated bits." Quite the opposite, really: it
> was a useful experiment, but has some serious problems. I'd briefly
> summarize the two main
+1, Philipp has thought about this a lot. Also: I'm really glad we're
having this conversation. We want to tackle this sooner than later.
On Mar 3, 2015 6:48 PM, "Justin Dolske" wrote:
> I don't actually think about:permissions is a good start, or that it's
> implemented "most of the complicated
Anne van Kesteren schrieb:
I'd like to ask that we start investigating how to best present these
to the user, including their persistence and implications.
Note that one idea that I had about 5 years back is implemented by default in SeaMonkey
as "Data Manager" and available as a Firefox add-o
On 2015-03-03 9:36 AM, Eric Rescorla wrote:
On Tue, Mar 3, 2015 at 5:55 AM, Anne van Kesteren mailto:ann...@annevk.nl>> wrote:
On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun mailto:fbr...@mozilla.com>> wrote:
> The good news is that most of the complicated bits are already
> implem
On Tue, Mar 3, 2015 at 5:55 AM, Anne van Kesteren wrote:
> On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun wrote:
> > The good news is that most of the complicated bits are already
> > implemented. See about:permissions.
>
> That seems like a good start, although it fails to cover a number of
> t
On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun wrote:
> The good news is that most of the complicated bits are already
> implemented. See about:permissions.
That seems like a good start, although it fails to cover a number of
things, such as cache, storage APIs, and the notifications API. And we
The good news is that most of the complicated bits are already
implemented. See about:permissions.
Though it operates on hostnames and not origins (bug 1066517).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listi
On Tue, Mar 3, 2015 at 12:40 PM, Anne van Kesteren wrote:
> I'd like to ask that we start investigating how to best present these
> to the user, including their persistence and implications. As well as
> strongly considering updating about:preferences to reveal how much we
> store for each page (a
The web already has a bunch of features that require permission UI,
such as passwords, geolocation, notifications, WebRTC, etc.
With service workers this will grow with permissions for push,
persistent storage, one-off synchronization, and periodic
synchronization. And likely more going forward
19 matches
Mail list logo
