On Tue, Oct 13, 2015 at 12:35 PM, Domenic Denicola wrote:
> especially since custom elements are unable to participate in the form
> control ecosystem
That is very fixable though. There have been good proposals made.
/ Jonas
On Wed, Aug 12, 2015 at 3:31 AM, Olli Pettay wrote:
>> There are two options to get an interop solution:
>> Option 1. Change the spec to reverse order, making the workaround
>> supported
>> officially.
>> Does anybody know if there was any specific reasons behind the current
>> order?
>
> If we do
On Sat, Jul 11, 2015 at 10:51 AM, Anne van Kesteren wrote:
> On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour wrote:
>> Minor bikeshed:
>> I have put scrollRestoration on history.options instead of directly history
>> itself in order to use history.options as an interface to contain any other
>>
On Fri, Jul 10, 2015 at 1:54 PM, Majid Valipour wrote:
> On Mon, Jun 29, 2015 at 5:20 PM Jonas Sicking wrote:
>>
>> FWIW I still prefer an API like
>>
>> history.scrollRestoration = 'manual';
>>
>> The main reason is that it seems to me that pushS
On Thu, Jul 9, 2015 at 12:06 PM, Rick Byers wrote:
> On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers wrote:
>>
>>
>> On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking wrote:
>>>
>>> On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky wrote:
>>> > On 7/9/15
On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky wrote:
> On 7/9/15 1:32 PM, Rick Byers wrote:
>>
>> Done. How does example 2 look now?
>>
>> http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
>
> Looks like it would work. Also looks kind of ugly because of the
> obje
>> Speaking
>> of that, having a new function makes it an option to let mayCancel be
>> false by default, compat-wise at least.
>
> That's a good question regardless of which approach we take. Filed
> https://github.com/RByers/EventListenerOptions/issues/17
I definitely think that if we're going t
FWIW I still prefer an API like
history.scrollRestoration = 'manual';
The main reason is that it seems to me that pushState/replaceState has
a largely orthogonal set of use cases that it tries to address from
scroll restoration. So I suspect that grouping the two together will
create awkwardness
On Tue, May 19, 2015 at 2:07 PM, Domenic Denicola wrote:
>> An API being proposed on a mailing list such as this one?
>
> The API is already proposed (see the rest of this thread).
Ah, sorry, I misunderstood your earlier email to mean that you were
intending to experiment with the API as well.
/
On Tue, May 19, 2015 at 2:04 PM, Domenic Denicola wrote:
> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas
> Sicking
>
>> That sounds hard to provide feedback on...
>
> What working mode would you prefer?
An API being proposed on a mailing
On Tue, May 19, 2015 at 1:57 PM, Domenic Denicola wrote:
>> It's hard to say what "this" you're talking about implementing in Chrome in
>> terms of the task-queueing behavior. Is that something you just haven't
>> decided on yet?
>
> Yeah, I think this will be something that gets nailed down more
On Mon, May 4, 2015 at 9:54 PM, Anne van Kesteren wrote:
>> More specifically, I'm proposing to remove the persistentPermission()
>> function in favor of using navigator.permissions.query({ name:
>> "persistent-storage" });
>
> Okay, I defer to e.g. these recent threads
>
> https://github.com/w3
On Mon, May 4, 2015 at 1:58 AM, Anne van Kesteren wrote:
> On Fri, May 1, 2015 at 9:40 PM, Jonas Sicking wrote:
>> Can't we use the permission API [1] for this? I.e. use the permission
>> name "persistent-storage" or some such? So rather than "default" w
Can't we use the permission API [1] for this? I.e. use the permission
name "persistent-storage" or some such? So rather than "default" we're
return "prompt".
[1] https://w3c.github.io/permissions/
/ Jonas
On Fri, May 1, 2015 at 5:11 AM, Anne van Kesteren wrote:
> Based on the discussion on this
On Tue, Apr 28, 2015 at 9:16 AM, Majid Valipour wrote:
> On Mon, Apr 27, 2015 at 9:54 PM Jonas Sicking wrote:
>>
>> Jumping in at the end here.
>>
>> As I've said before, I like the general idea of giving pages more
>> control over scroll restoration, but
On Mon, Apr 27, 2015 at 7:37 PM, duanyao wrote:
> In iframe, srcdoc attribute seems as secure (insecure) as data: URL in src,
> so should it be removed from the spec?
The difference there, and in the other examples that you mention, is
that you know that you are loading content in your own domain
Jumping in at the end here.
As I've said before, I like the general idea of giving pages more
control over scroll restoration, but I don't think we should tie this
to pushState()/replaceState()/onscroll.
My proposal is instead that we add an API like
history.restoreScroll = boolean;
This proper
On Mon, Apr 27, 2015 at 2:20 PM, Tab Atkins Jr. wrote:
> On Mon, Apr 27, 2015 at 7:00 AM, Anne van Kesteren wrote:
>> Currently Chrome supports data URLs inside EventSource whereas in
>> Firefox EventSource is restricted to http/https URLs:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=115
Is this really something we should tie to the pushState/replaceState API?
It seems like websites that lazily add more content as the user scroll
down, like the facebook feed or twitter feed, might not use
pushState/replaceState, but would still like to handle restoring
scroll position themselves.
On Tue, Mar 10, 2015 at 5:54 PM, Mounir Lamouri wrote:
> On Tue, 10 Mar 2015, at 22:44, Jonas Sicking wrote:
>> On Tue, Mar 10, 2015 at 3:05 PM, Mounir Lamouri
>> wrote:
>> >
>> > On Tue, 10 Mar 2015, at 21:44, Jonas Sicking wrote:
>> >> I think I
On Tue, Mar 10, 2015 at 3:05 PM, Mounir Lamouri wrote:
>
> On Tue, 10 Mar 2015, at 21:44, Jonas Sicking wrote:
>> I think I'd prefer to define "on" and "off" as defined values unless
>> there is very little usage of them. We can certainly mark them
On Tue, Mar 10, 2015 at 1:29 PM, Mounir Lamouri wrote:
> (bcc: public-webapps@)
>
> Hi,
>
> I would like to standardize the Apple's proprietary autocapitalize
> attribute. This attribute is widely used and it would probably benefit
> the platform to have a broader support for it. The implementatio
On Fri, Mar 6, 2015 at 5:05 AM, Anne van Kesteren wrote:
> If that's a legacy artifact, can we call that out somewhere?
Yes. It's a legacy artifact since before we had the generic concept of
transferring and ports was this special one-off thing that you could
stick in the second argument when pos
Hi Anne,
Great to see that this is being worked on! And it's great to see that
it enables integration with built-in share functionality provided by
the UA. I also *really* like the idea of integrating with "save as"
and .
However there's a couple of use cases that seems good to address.
First of
On Tue, Oct 14, 2014 at 12:06 AM, Anne van Kesteren wrote:
> On Tue, Oct 14, 2014 at 1:02 AM, Jonas Sicking wrote:
>> We'd definitely need to treat the header as a content-set header from
>> a CORS perspective. Otherwise we'd have problems not just with pages
>
On Mon, Oct 13, 2014 at 6:53 AM, Anne van Kesteren wrote:
> Per XMLHttpRequest User-Agent has been off limits for script. Should
> we keep it that way for fetch()? Would it be harmful to allow it to be
> omitted?
>
> https://github.com/slightlyoff/ServiceWorker/issues/399
>
> A possible attack I c
On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren wrote:
> On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. wrote:
>> You keep ignoring the past "turns out we like using async errors for
>> 'soft failures' of this kind, and have done it lots of times, and
>> nobody seems to complain" argument.
>
>
On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren wrote:
> On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
> wrote:
>> What I find interesting here is the claim that people find try/catch
>> annoying or distasteful.
>
> I don't think you should need try/catch for a common failure case.
> That i
On Wed, Oct 8, 2014 at 7:13 AM, Anne van Kesteren wrote:
> On Tue, Oct 7, 2014 at 7:33 PM, Jonas Sicking wrote:
>> I don't know of a use-case for that. And given that I think we should
>> define that non-persistent notifications go away after a timeout, I
>> think t
On Tue, Oct 7, 2014 at 5:42 AM, Anne van Kesteren wrote:
> On Mon, Oct 6, 2014 at 9:11 PM, Jonas Sicking wrote:
>> Though based on Andrew's latest comments, I don't know that anyone
>> strongly feels that we need to keep the event?
>
> If you create a non-persist
On Mon, Oct 6, 2014 at 9:29 AM, Anne van Kesteren wrote:
>
>>> Yeah, it seems like we need to keep this. Through opt-in works.
>>
>> It seems like if we keep this event it should at the very least be
>> possible to tell "closed because of user action" from "closed because
>> of timeout or other pl
On Mon, Oct 6, 2014 at 9:26 AM, Anne van Kesteren wrote:
> On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking wrote:
>> I agree. One of the big shortcomings of the current spec is that it
>> leaves UI too undefined. This is particularly problematic given that
>> notifications is
On Oct 1, 2014 4:31 AM, "Anne van Kesteren" wrote:
> Combined with dropping the open event, I think I have enough to rework
> the current Notifications API. Is there anything I'm missing?
I just remembered that another thing that came up was the ability to remove
a notification bases on tag. I.e.
On Mon, Oct 6, 2014 at 12:05 AM, Andrew Wilson wrote:
> On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking wrote:
>>
>> Another thing we could do here is to simply not address this use case.
>> Does gmail for android do the same thing? I wasn't able to reproduce
>
On Wed, Oct 1, 2014 at 4:31 AM, Anne van Kesteren wrote:
> On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo wrote:
>> * Life-time of existing notifications.
>>
>> Chrome currently treats Web Notifications as "persistent" ones. When the
>> page goes away, the notification stays. Interaction with th
On Sep 30, 2014 1:26 AM, "Andrew Wilson" wrote:
>> In any case it sounds like gmail would not notify properly on platforms
>> where notifications do dissappear after a few seconds, which seems
>> problematic, no?
>
> I think that Chrome doesn't generate a close event in the case that the
> noti
On Fri, Oct 3, 2014 at 5:09 AM, eberhard speer jr. wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/10/2014 09:38, Jonas Sicking wrote:
>> On Thu, Oct 2, 2014 at 9:24 PM, eberhard speer jr.
>> wrote:
>>> If you are interested in the intricacies
On Thu, Oct 2, 2014 at 9:24 PM, eberhard speer jr. wrote:
> If you are interested in the intricacies of "UA-sniffing", client and
> server-side, the use-cases, the esoterica etc I'll gladly contribute
> what I can.
I guess the question at hand is:
What are the client-side situations when people
On Thu, Oct 2, 2014 at 3:57 AM, Mounir Lamouri wrote:
> On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote:
>> On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri wrote:
>> > On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote:
>> >> On Tue, Sep 30, 2014 at 4:40 A
On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri wrote:
> On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote:
>> On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri
>> wrote:
>> > On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote:
>> >> Thoughts?
>> >
&
On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri wrote:
> On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote:
>> Thoughts?
>
> Do you have any data that makes you think that those websites would stop
> using UA sniffing but start using navigator.deviceModel if they had that
&g
On Sep 30, 2014 12:48 AM, "Andrew Wilson" wrote:
>
>
>
> On Mon, Sep 29, 2014 at 9:14 PM, Jonas Sicking wrote:
>>
>> On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson
wrote:
>> > OK, looked back into the Gmail code (since it'd been a coup
On Mon, Sep 29, 2014 at 12:14 PM, Jonas Sicking wrote:
> For an app that uses non-persistent notifications, such as gmail, I
> think we have two options. Either use Notification.get() here too. Or
> we allow "close" events to be fired for non-persistent notifications.
Actual
On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson wrote:
> I'm sorry, I meant that you can only use the 'data' attribute, if the data
> you want to associate with the notification is structured-cloneable. Which
> precludes lots of interesting stuff, like objects with attached methods,
> memoized func
On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson wrote:
> OK, looked back into the Gmail code (since it'd been a couple of years since
> I was really down in that notification code). There are two places where we
> listen for close events currently:
>
> 1) When closing an email notification - gmail
On Mon, Sep 29, 2014 at 4:55 AM, Andrew Wilson wrote:
> On Mon, Sep 29, 2014 at 1:40 PM, Jonas Sicking wrote:
>> On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson
>> wrote:
>> > I'm sorry, I meant that you can only use the 'data' attribute, if the
>&g
On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson wrote:
> I'm sorry, I meant that you can only use the 'data' attribute, if the data
> you want to associate with the notification is structured-cloneable. Which
> precludes lots of interesting stuff, like objects with attached methods,
> memoized func
On Mon, Sep 29, 2014 at 3:10 AM, Andrew Wilson wrote:
> That only works if 'data' is a structured-cloneable data structure.
Per spec it is yes.
/ Jonas
On Sun, Sep 28, 2014 at 11:15 PM, Andrew Wilson wrote:
>> * Dropping the close event.
>>
>> I've been wondering myself whether it's valuable to support this. Like
>> Tab, I'm not aware of any messaging application actually using the close
>> event as an indication that the message has been read. T
On Fri, Sep 26, 2014 at 7:36 AM, Peter Beverloo wrote:
> Let me reply to a few points mentioned in this thread -- it's quite
> overloaded :-).
>
> I've also added Andrew, who might know some historical reasons for the
> events. (Andrew: most of this is in context of persistent notifications.)
>
>
On Fri, Sep 26, 2014 at 6:40 AM, Anne van Kesteren wrote:
> On Fri, Sep 26, 2014 at 3:31 PM, Jonas Sicking wrote:
>> On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren wrote:
>>> On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking wrote:
>>>> promise
On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren wrote:
> On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking wrote:
>> Or, should persistent notifications not use a constructor at all?
>> What's the purpose of having a reference to a Notification object if
>> no events w
On Thu, Sep 25, 2014 at 4:42 PM, Tab Atkins Jr. wrote:
> The one example I can think of that's kinda like this is the Google
> Maps Navigation "Notification". It actively resists being closed, for
> one thing, but it does have a Dismiss button on itself (because it's a
> Rich Notification or what
On Thu, Sep 25, 2014 at 3:25 AM, Jake Archibald wrote:
> On 24 September 2014 01:21, Jonas Sicking wrote:
>>
>> * Notifications that close when a page goes away does not seem useful
>> on mobile, but could be useful on desktop to enable minimized
>> applications, or a
On Thu, Sep 25, 2014 at 3:02 AM, Anne van Kesteren wrote:
> On Thu, Sep 25, 2014 at 2:28 AM, Jonas Sicking wrote:
>> On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren wrote:
>>> Strawman: We classify existing notifications as non-persistent
>>> notifications. Only no
On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren wrote:
> On Wed, Sep 24, 2014 at 2:21 AM, Jonas Sicking wrote:
>> * We should consider the case of persistent notifications separate
>> from notifications that automatically close when a page goes away.
>
> Strawman:
On Sep 24, 2014 3:51 AM, "Silvia Pfeiffer"
wrote:
>
> On 24 Sep 2014 20:40, "James Graham" wrote:
> >
> > On 24/09/14 02:54, Jonas Sicking wrote:
> >
> > > In the meantime, I'd like to add a property to window.navigator to
> >
On Sep 24, 2014 3:40 AM, "James Graham" wrote:
>
> On 24/09/14 02:54, Jonas Sicking wrote:
>
> > In the meantime, I'd like to add a property to window.navigator to
> > enable websites to get the same information from there as is already
> > available
Hi All,
Right now all mobile browsers expose the mobile device model through
the UA string.
There are lots of us, me included, that wish that we could stop doing
this. The problems are at least:
* Exposes more finger printing bits. (I'm aware that people feel
differently about how big of a probl
On Tue, Sep 23, 2014 at 5:32 PM, Tab Atkins Jr. wrote:
> On Tue, Sep 23, 2014 at 5:21 PM, Jonas Sicking wrote:
>> After having talked to our web developers, and having talked to Olli,
>> I've come to the following conclusions:
>>
>> * We should consider the
After having talked to our web developers, and having talked to Olli,
I've come to the following conclusions:
* We should consider the case of persistent notifications separate
from notifications that automatically close when a page goes away.
* Notifications that close when a page goes away does
On Tue, Sep 9, 2014 at 6:21 PM, Marcos Caceres wrote:
> On September 9, 2014 at 9:10:27 PM, Jonas Sicking (jo...@sicking.cc) wrote:
>> On Tue, Sep 9, 2014 at 5:13 PM, Marcos Caceres wrote:
>> >> What about icons that need to change daily? E.g. for a calendaring site?
>>
On Tue, Sep 9, 2014 at 5:13 PM, Marcos Caceres wrote:
>> What about icons that need to change daily? E.g. for a calendaring site?
>
> This is scary, IMO. A hijacked site could have its icon replaced for a bank's
> icon or something. I dunno.
At least in FirefoxOS we found that we need to support
On Fri, Aug 29, 2014 at 9:18 AM, Robert Bindar wrote:
> My thought is to firstly introduce a small package of behaviors that
> would include "lights", "vibration" and "disrupting"
> (and maybe "noclear" too).
> The default value for all these 3 behaviors is false.
I don't think we'll want to defa
On Tue, Aug 26, 2014 at 10:36 AM, Domenic Denicola
wrote:
> +Marcos because he is really good at that kind of investigative work, and
> might have some idea what FFOS is doing for numeric badges.
We don't do anything yet. But we'd like to. I definitely feel like
having a badge is a separate API
On Tue, Aug 26, 2014 at 2:18 AM, Anne van Kesteren wrote:
> On Tue, Aug 26, 2014 at 11:06 AM, Jonas Sicking wrote:
>> I don't see a problem with firing events on all Notification
>> instances, and only changing focus if none of the events were
>> cancelled.
>
>
On Tue, Aug 26, 2014 at 12:15 AM, Anne van Kesteren wrote:
> On Mon, Aug 25, 2014 at 6:42 PM, Jonas Sicking wrote:
>> I definitely think we need the ability for code running in Windows
>> (i.e. code that handles UI) to be able to enumerate any notifications
>> created by
On Mon, Aug 25, 2014 at 1:29 AM, Anne van Kesteren wrote:
> On Sun, Aug 24, 2014 at 11:18 AM, Olli Pettay wrote:
>> Given the very odd Notification API, where the same user input may end up
>> being
>> represented by several click events in the browser...
>> (I think we need to change that someho
The main question that I have is what is the security model?
The security section of the spec is very light.
/ Jonas
On Aug 22, 2014 6:34 PM, "Jeffrey Yasskin" wrote:
> We have a draft API for Bluetooth device access at
> https://webbluetoothcg.github.io/web-bluetooth/, for which I'm planning t
On Wed, Aug 20, 2014 at 1:33 AM, Anne van Kesteren wrote:
> On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking wrote:
>> FWIW, the web platform sorely needs a construct for "readonly state
>> variable + event whenever the state changes". I.e. some form of
>> obse
On Tue, Aug 19, 2014 at 1:29 PM, Marcos Caceres wrote:
> interface WakeLock : EventTarget {
>Promise request();
>Promise release();
>attribute EventHandler onlost;
> }
What are the use cases for onlost?
Though I don't really mind exposing this state. My experience is that
if any sane
On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri wrote:
> On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote:
>> Note that in the API that I'm proposing, there is no way to
>> accidentally rely on GC behavior. If a WakeLock object is GCed before
>> it has been release(
On Mon, Aug 18, 2014 at 5:35 PM, Marcos Caceres wrote:
> The reason I didn't make it a boolean was because of the IPC involved and
> because I wanted to support multiple types of locks without needing to add
> new attributes in the future (and if we need to add the complex stuff later).
What's
On Mon, Aug 18, 2014 at 5:37 PM, Marcos Caceres wrote:
> On Monday, August 18, 2014 at 6:41 PM, Kornel Lesiński wrote:
>> WakeLock.request() expecting a string isn't very friendly to feature
>> detection.
>
> The API tells you if a wake lock type is not supported by either rejecting
> with a Typ
On Mon, Aug 18, 2014 at 4:37 PM, Marcos Caceres wrote:
>> while(navigator.wakeLock.isHeld("screen"))
>> navigator.wakeLock.release("screen"); // just release the damn thing in my
>> leaky code!
>
> That would just halt the browser as the script would never complete:
> currently releasing happen
On Mon, Aug 18, 2014 at 2:04 AM, Mounir Lamouri wrote:
>
>> > It's also not clear
>> > how this solution is superior than the current solution [1] with regards
>> > to multiple releases or requests. In [1], if you call .request() or
>> > .release() multiple time, the promise reacts appropriately.
On Fri, Aug 15, 2014 at 11:12 PM, Anne van Kesteren wrote:
> On Sat, Aug 16, 2014 at 8:09 AM, Anne van Kesteren wrote:
>> On Fri, Aug 15, 2014 at 11:28 PM, Jonas Sicking wrote:
>>> Could we introduce a "always-origin" value for which
>>> combines the "
On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri wrote:
> On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote:
>> I am however more worried about that only having a request() and a
>> release() function means that pages that contain multiple independent
>> subsystems will h
Hi All,
Right now the spec has two separate features:
You can specify a "origin" policy which enables sending just the
origin whenever a referrer is sent.
You can also specify "always" in order to override UA policies like
"don't send referrer when navigating from https to http sites".
However
On Aug 15, 2014 1:57 AM, "Anne van Kesteren" wrote:
>
> On Fri, Aug 15, 2014 at 1:37 AM, Robert Bindar
wrote:
> > We can not say accurately if the default will always be false because
> > the platform may or may not support the behavior, or it might be
overridden
> > by a user defined setting.
>
idea though.
/ Jonas
> Jesper Kristensen
>
> Den 14-08-2014 kl. 03:00 skrev Jonas Sicking:
>
>> On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres wrote:
>>>
>>> On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote:
>>>
>>>> On Thu, 17 J
On Thu, Aug 14, 2014 at 6:33 AM, Nils Dagsson Moskopp
wrote:
> So what would happen if I want my laptop to go to into low-power mode by
> closing the lid? Would I have to close a lot of risky web pages first?
We need indeed something to prevent abuse here. Especially for CPU
locks given that they
On Thu, Aug 14, 2014 at 4:44 AM, Biju wrote:
> So what happens when we have following function call.
> How do we release the runaway lock request.
> Another case is a page made lock and user navigate away from the page.
> Do the browser keep the lock for ever ?
>
> function xyz(){
>
> do_some
On Wed, Aug 13, 2014 at 9:46 PM, Biju wrote:
>
> On 13 August 2014 21:00, Jonas Sicking wrote:
>>
>> An alternative design would be something like
>>
>> x = new WakeLock("display");
>> x.request();
>> x.release();
>>
>> Extra call
On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres wrote:
> On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote:
>
>> On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
>> >
>> > I don't have a strong opinion. My concern was mostly about developers
>> > having to watch for a whole bunch of
On Wed, Aug 13, 2014 at 2:12 PM, Robert Bindar wrote:
> Concerning web notifications, it would be very helpful for content and web
> apps
> to have a way of specifying the behavior their notifications should have.
> For instance, a chat client may not always want to play a sound when sending
> a n
On Aug 11, 2014 8:38 AM, "Peter Beverloo" wrote:
> On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson wrote:
> You raise an interesting question. Given the following notification:
>
> var notification = new Notification('Title', {
> body: 'Hello, world!',
> icon: '/my-icon.png',
> items:
On Fri, Aug 8, 2014 at 5:48 AM, Peter Beverloo wrote:
> I think the benefit of being able to closely match the UI and UX of native
> notifications on the platforms is something that's enabled by using
> declarative properties, whereas that would be near impossible to do with
> HTML notifications.
On Tue, Aug 5, 2014 at 7:09 AM, Anne van Kesteren wrote:
> On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote:
>> I think the most low hanging fruit would be to add the following as
>> data that can be displayed in a notification:
>>
>> * Progress bar
>
>
On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson wrote:
>
> On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking wrote:
>>
>> On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson
>> wrote:
>> >
>> > On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote:
>&g
I'd really like to avoid sticking this in specs. We already have 3
ways of adding icons, /favicon.ico, and . That's probably about 2 too many. We shouldn't add a
4th one. Generally speaking, eventually I think manifests is what will
encourage the best UX and the easiest syntax for authors.
Given
On Jul 21, 2014 9:55 AM, "Ben Maurer" wrote:
>
> I was walking with Will about how the browser prioritizes the loading of
> scripts and stylesheets. An idea that came up in our conversation was
> allowing the user to directly access Fetch objects associated with scripts
> and stylesheets. Some exa
On Thu, Jul 10, 2014 at 8:01 AM, Peter Beverloo wrote:
>
> On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking wrote:
>>
>> We need to change the GC behavior. Right now it seems like if a
>>
>> Notification object is created, but no event listeners are attached,
>&
On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson wrote:
>
> On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking wrote:
>>
>> Hi All,
>>
>> We've on and off discussed various features added to notifications.
>> It'd be great to move forward with some of
Hi All,
We've on and off discussed various features added to notifications.
It'd be great to move forward with some of these improvements.
I think the most low hanging fruit would be to add the following as
data that can be displayed in a notification:
* Progress bar
* Lists of title/body pairs
On Thu, Jul 3, 2014 at 10:00 AM, Anne van Kesteren wrote:
> On Tue, Jun 3, 2014 at 12:21 AM, Jonas Sicking wrote:
>> srcdoc is like eval(). Yes, it's definitely a tool that enables you to
>> run 3rd party code in your own context and with your own principal.
>> Ho
On Mon, Jun 23, 2014 at 8:46 AM, Domenic Denicola
wrote:
>
>> It might be instructive to think about how the Node community would
>> structure these APIs. Node has a much stronger notion of modules and
>> dependencies than browsers because Node uses npm. As Node developer, I
>> would be sad i
On Mon, Jun 16, 2014 at 6:57 PM, Jussi Kalliokoski
wrote:
>
> var doesFetchSupportJson = function () {
> return fetch("data:application/json;base64,e30=").then(function
> (response) {
> return response.body.to("json");
> }).then(function () {
> return true;
> }).catch(f
On Mon, Jun 2, 2014 at 6:03 AM, Boris Zbarsky wrote:
> On 6/2/14, 9:00 AM, Anne van Kesteren wrote:
>>
>> You're not persuaded by the attack scenario?
>
> Correct. I mean, the same scenario applies to srcdoc, document.write() into
> an iframe, etc. Why are data urls special?
srcdoc is like eval
On Fri, May 23, 2014 at 5:23 PM, Adam Barth wrote:
> When is it safe for a user agent to garbage collect a BroadcastChannel
> instance?
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts
>
> Given that another document might
1 - 100 of 1065 matches
Mail list logo
