On 04.01.2018 04:46, Karl Dubost wrote:
> Jonathan,
>
> Le 4 janv. 2018 à 00:15, Jonathan Kingston a écrit :
>> Firefox has an implementation that only can be used to allow a web page to
>> handle RSS feeds.
>
> in Firefox 8, the feeds panel was removed from Firefox. It created a bit of
> ba
On Thu, Jan 4, 2018 at 5:50 PM, wrote:
> FYI: As implemented in Chrome, permission is automatically granted to use the
> Generic Sensor API (`chrome://flags/#enable-generic-sensor`) in secure
> contexts (e.g., HTTPS, localhost).
Requiring secure contexts is not a security feature. It's necess
I’m unclear of which side of the line we want to fall on between supporting
existing sites or requiring them to change.
If we are going to break existing websites, then perhaps looking at the Generic
Sensor API (as CVan suggests in his email) is a more rational approach; is it
implemented in F
On Thu, Jan 4, 2018 at 9:06 PM, chris wrote:
> Thanks for the clarification, Martin. Providing that the UA persists
> permissions (based on user action –or perhaps also leveraging Google’s Safe
> Browsing API which Firefox and all other browsers already rely upon –
> revoked and prompted -> denied
My hope is that any stickiness would be transitory.
If someone is obviously using a VR headset, I don't think we would
require much movement at all to trigger the automatic permission.
That's clearly a primary input interface.
On Thu, Jan 4, 2018 at 9:15 PM, Blair MacIntyre wrote:
> I’m unclear
On Thu, Jan 4, 2018 at 11:15 AM, Blair MacIntyre wrote:
> If we are going to break existing websites, then perhaps looking at the
> Generic Sensor API (as CVan suggests in his email) is a more rational
> approach; is it implemented in FF yet? Plans for it?
See https://github.com/w3ctag/design
On 03/01/2018 23:18, Nihanth Subramanya wrote:
++ from me as well, this sounds awesome.
Ideally, I would like a solution where especially JS-only observer topics don't require a non-artifact build. A JS forwarder for the
"real" observer service may help with that goal, by making the "new" argu
On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly wrote:
> On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote:
>> So after validating my approach in that bug (which is almost ready) I've
>> thought that it might be time to give the observer service the same
>> treatment. First of all we'd have a list
On Thu, Jan 4, 2018 at 10:00 AM, Nathan Froyd wrote:
> On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly wrote:
> > On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto
> wrote:
> >> So after validating my approach in that bug (which is almost ready) I've
> >> thought that it might be time to give the obser
+1 to Martin's feedback.
On 1/3/18 10:19 PM, Martin Thomson wrote:
> Without the protocol pieces, this remains vendor-specific. We should
> comment on this and make it clear that we think that definition of a
> generic protocol for interacting with the second display has not been
> given sufficie
On 2018-01-04 10:00 AM, Nathan Froyd wrote:
…
2) How would one shoehorn this into *DL? The options that come to mind are:
- Separate methods for every observer topic, which sounds terrible
from a code duplication perspective. Though maybe this would be nice
for JS clients, so we could say thin
I am curious what Enterprise users are asking for. I'd like to
think/hope that a primary concern of enterprise is "Security" (or the
separate topic of Privacy); but I'm not certain it is.
In particular, I am curious if enterprise users would be interested in
flipping preferences that would provid
I took over the DOM: Device Interfaces component last month, and as part of
that was looking at the Generic Sensor APIs (and have been following this
conversation too). I've read over the spec, but that's about it so far.
While we've had a couple of outside questions about implementation, it
hasn't
[SNIP]
>> If foo->bar() can mutate the lifetime of foo, of course you must take a
>> strong
>> reference to foo. Nothing about auto or range-for changes this.
>
>What auto does is make it really hard to tell whether a strong reference is
>being taken.
>
>> If you don't understand your lifetimes, y
On 03/01/18 23:30, Ben Kelly wrote:
> Could we use our existing idl/webidl/ipdl for this? It would be nice
> not to have to maintain another code generator in the tree if possible.
AFAIK there is no way in IDL to declare an enum. Constants can be
declared but one needs to manually assign them a
On Thu, Jan 4, 2018 at 4:35 PM, Gabriele Svelto wrote:
> On 03/01/18 23:30, Ben Kelly wrote:
> > Could we use our existing idl/webidl/ipdl for this? It would be nice
> > not to have to maintain another code generator in the tree if possible.
>
>
> AFAIK there is no way in IDL to declare an enum.
On 04/01/18 22:39, Ben Kelly wrote:
> We can't have a comment explaining "please add any new constants in
> sequential order in the following list"?
We could, but what about removing one? Also if we have hundreds (or
thousands) the risk that one is accidentally duplicated is significant.
My ration
On Thu, Jan 4, 2018 at 4:44 PM, Gabriele Svelto wrote:
> On 04/01/18 22:39, Ben Kelly wrote:
>> Or make your "generator"
>> create the idl which then creates the js/c++?
>
> I tried as that could have worked! Unfortunately it doesn't seem to be
> possible ATM. mach bailed out with a weird error w
On 04/01/18 22:47, Nathan Froyd wrote:
> This is very doable, it just requires some build system hackery: we
> accept preprocessed/generated WebIDL files, and generated IDL files
> would require basically the same approach. I can help with the build
> system hackery if you want to continue pursuin
On 04/01/2018 22:49, Gabriele Svelto wrote:
On 04/01/18 00:05, Gijs Kruitbosch wrote:
Unfortunately, there are quite a lot (
https://searchfox.org/mozilla-central/search?q=obs.addObserver&case=false®exp=false&path=
-- sync, the add-ons manager, session store, etc. etc.).
That's not exactly what
On 04/01/2018 23:47, Gijs Kruitbosch wrote:
On 04/01/2018 22:49, Gabriele Svelto wrote:
On 04/01/18 00:05, Gijs Kruitbosch wrote:
Unfortunately, there are quite a lot (
https://searchfox.org/mozilla-central/search?q=obs.addObserver&case=false®exp=false&path=
-- sync, the add-ons manager, ses
I would say it comes down to the module. I'm very comfortable in my
modules using auto, perhaps because our lifetime management is more
clear. To me, the unsafe examples are pretty strawman-y, since it's
very clear that there are at-risk lifetimes involved. (Returning a
bare pointer and relying on
So I think Martin, Peter, and I share similar concerns here, and I'm
inclined to turn those concerns into an objection to this charter.
So how does this sound for proposed comments on the charter
(submitted as a formal objection)? Note that I've tried to turn the
comments into a specific suggesti
23 matches
Mail list logo
