Re: [whatwg] Proposal for showing thousand separator in form controls.

[Jonas Sicking]

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

Re: [whatwg] Order of popstate event and scroll restoration - interop issue

[Jonas Sicking]

On Wed, Aug 12, 2015 at 3:31 AM, Olli Pettay o...@pettay.fi 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 this, I think popstate event should also become cancelable, so that
 web page could easily
 prevent  scrolling (in that case there wouldn't be need to play with
 scrollRestoration always)

Is there an advantage to having two ways to prevent scoll restoration?

Either way it seems like cancelling popstate would be a strange way
to do so. Cancelling popstate sounds like it would prevent the state
transition from happening, which, if I understand the proposal
correctly, it would not do?

/ Jonas

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Jonas Sicking]

On Fri, Jul 10, 2015 at 1:54 PM, Majid Valipour maji...@chromium.org wrote:
 On Mon, Jun 29, 2015 at 5:20 PM Jonas Sicking jo...@sicking.cc wrote:

 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 in the API in the future.

 But I don't have time to chase this issue.

 / Jonas

 Jonas,

 After some offline discussion with Rick, we have decided to converge to your
 preferred API. I hope this addresses your concern about potential future
 awkwardness and help make adoption easier.

 I have updated the proposed spec to reflect this change. The semantic of
 history.options.scrollRestoration is based on our previous discussion in
 this thread [1]. It short, it does not change any previous entries and
 navigating across documents resets its value so it only applies to entries
 created for the same document.

 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
 restoration related attributes which have similar semantics (e.g., recorder
 scroll position, scale restoration, recorded scale).

Thanks Majid! This sounds great!

/ Jonas

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Jonas Sicking]

On Sat, Jul 11, 2015 at 10:51 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour maji...@chromium.org 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
 restoration related attributes which have similar semantics (e.g., recorder
 scroll position, scale restoration, recorded scale).

 Is the History object Document-bound in all implementations? Otherwise
 adding new dependent objects will be problematic security-wise.

I think we've already made that assumption given that history.state
already relies on this.

/ Jonas

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

[Jonas Sicking]

 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 to have any chance of moving
significant portions of the web to have better performance, we need
things to be fast by default, and then opt-in to slower behavior.

And the more we can simply point to these APIs are fast, use these,
those APIs are slow, don't use those the better. It should be very
clear when you're falling off the fast path.

/ Jonas

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

[Jonas Sicking]

On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu 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
 object-truthiness bit, but I'm not sure there's any way to avoid that while
 keeping the overload a boolean and dictionary setup.

I'm not a fan of this approach. It'll be very hard to get users to opt
in consistently to the faster behavior. Especially given that it
requires much more typing.

/ Jonas

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

[Jonas Sicking]

On Thu, Jul 9, 2015 at 12:06 PM, Rick Byers rby...@chromium.org wrote:
 On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers rby...@chromium.org wrote:


 On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu 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
  object-truthiness bit, but I'm not sure there's any way to avoid that
  while
  keeping the overload a boolean and dictionary setup.

 I'm not a fan of this approach. It'll be very hard to get users to opt
 in consistently to the faster behavior. Especially given that it
 requires much more typing.


 Bigger picture, we're seriously exploring in chromium taking both a carrot
 and stick approach to the event-handler jank problem.  Carrots are this new
 API, better devtools tooling highlighting the problem, etc.  Sticks are more
 controversial so we're not ready to propose anything concrete yet.  But
 imagine if particularly slow sites that haven't opted out of blocking
 handlers got some sort of unresponsive UI notification
 (http://crbug.com/504904).  The window-greying-out behavior introduced in
 Windows Vista had a very strong impact on developers motivation to invest in
 UI-thread responsiveness :-).  Also Google search results already take page
 load time into account
 (http://googlewebmastercentral.blogspot.ca/2010/04/using-site-speed-in-web-search-ranking.html),
 if we could reliably collect scroll jank performance I don't see why that
 also wouldn't be a good signal to use in search rankings (though this is
 only my personal opinion - no inside knowledge here at all).

 Anyway, suffice it to say that I fully agree we can't expect big wins in
 practice just by shipping this new API (no matter how simple we make it,
 though the simpler the better of course).  But I'm still confident that
 having an API like this will open a lot of doors that together will lead to
 substantial user-experience improvements on the web.

Yes, I think that's the right way to think about it.

I think we need new APIs which enable people to do the scroll effects
that they want without getting jank.

I would imagine that most of the time that people listen for
scrollwheel events it is to actually implement some scrolling effects,
or to override the scrollwheel to do something other than scroll the
page.

In neither of these situations a { mayCancel: false } feature doesn't
really help. If they are implementing scroll effect using a
non-cancelling event, it will look crappy since the effect won't keep
up to date with the scrolling thread. If they are using the
scrollwheel event to do something other than scrolling, then they
*have* to cancel the event.

So new APIs are clearly needed here, especially for doing
scroll-driven effects. That would be the carrot. And then we need
incentives for people to move off of the old crappy APIs.

(Actually, for the latter use case the current API might actually be
fine since no scrolling will happen, and so janky scrolling isn't a
problem as long as the event handler always cancel.)

/ Jonas

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Jonas Sicking]

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 in the API in the future.

But I don't have time to chase this issue.

/ Jonas


On Mon, Jun 29, 2015 at 8:14 AM, Majid Valipour maji...@chromium.org wrote:
 On Wed, May 20, 2015 at 11:00 AM Majid Valipour maji...@chromium.org
 wrote:


 It will be great if we could make progress on getting a consensus on the
 API so that we can actually ship this feature. I think we have narrowed it
 down to two main options:

 1- Setting scroll options using history.{push, replace}State. This is what
 we have implemented in chrome (see IDLs above).
  history.replaceState(history.state, '','', {scrollRestoration:
 'manual'})

 2- Setting scroll options directly on history object. This is what Jonas
 has proposed. Per our earlier discussions in this thread it should be
 possible to define the semantics such that we get per-entry control.
 history.options.scrollRestoration = 'manual'

 Both  are equally powerful with #1 being better for complex situations
 where different entries may need to have different scroll restoration
 behaviour  and #2 being better for simpler case where the application wants
 the same scroll restoration for all its entries. As an experiment, I have
 created a small script that implements #2 on top of #1.

 Jonas prefers #2. I am partial to #1. Spec editors (Anne, Ian, Simon,
 Robin):
 Do you have a preference here?


 Anne, Ian, Simon, Robin,

 Do you have a preference one way or another for either of the above APIs?

 I have a git repo where I have spec'd the first option (as implemented in
 Chromium) and am tracking issues against it. Unless there is a strong
 preference against #1, I feel it is reasonable to try to ship it.

 Majid

Re: [whatwg] An API for unhandled promise rejections

[Jonas Sicking]

On Tue, May 19, 2015 at 2:07 PM, Domenic Denicola d...@domenic.me 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.

/ Jonas

Re: [whatwg] An API for unhandled promise rejections

[Jonas Sicking]

On Tue, May 19, 2015 at 1:57 PM, Domenic Denicola d...@domenic.me 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 during 
 implementation and writing of test cases.

That sounds hard to provide feedback on...

/ Jonas

Re: [whatwg] An API for unhandled promise rejections

[Jonas Sicking]

On Tue, May 19, 2015 at 2:04 PM, Domenic Denicola d...@domenic.me 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 list such as this one?

/ Jonas

Re: [whatwg] Storage Standard

[Jonas Sicking]

On Mon, May 4, 2015 at 9:54 PM, Anne van Kesteren ann...@annevk.nl 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/w3c/push-api/issues/136
   https://github.com/slightlyoff/BackgroundSync/issues/39

 where we decided to keep similar APIs.

Having both the separate permissions API as well as the APIs from the
two threads above is nuts. We should either reverse these two APIs
above, or nuke the permissions API. The fact that Google is pushing to
have both makes no sense at all to me.

Having a single consistent API makes more sense to me. A good reason
why is the recent thread about default vs. prompt. Whatever we
decide that the color of the bikeshed should be, having a single API
ensures that the color is consistent.

/ Jonas

Re: [whatwg] Storage Standard

[Jonas Sicking]

On Mon, May 4, 2015 at 1:58 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Fri, May 1, 2015 at 9:40 PM, Jonas Sicking jo...@sicking.cc 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 we're
 return prompt.

 [1] https://w3c.github.io/permissions/

 I'm sorry, what do you mean by this?

By this I mean the API discussed in this thread :)

More specifically, I'm proposing to remove the persistentPermission()
function in favor of using navigator.permissions.query({ name:
persistent-storage });

 I filed an issue a while back
 on that specification for trying to needlessly change terminology:

   https://github.com/w3c/permissions/issues/25

I'll comment there, but either way this seems like a bikeshed issue
that's not enough to kill the permissions spec.

 If you mean persistentPermission() by this, the reason that is there
 is because we have done the same thing for other new APIs, such as the
 Push API.

In the past we didn't have the navigator.permissions API. Now we do.

/ Jonas

Re: [whatwg] Storage Standard

[Jonas Sicking]

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 ann...@annevk.nl wrote:
 Based on the discussion on this list and on:

   https://wiki.whatwg.org/wiki/Storage
   https://github.com/slightlyoff/StorageDurability

 Here's a first draft:

   https://storage.spec.whatwg.org/
   https://github.com/whatwg/storage
   https://twitter.com/storagestandard

 It does not address multiple boxes for now. I hope we can continue
 discussing those in parallel, perhaps in the GitHub repository, as
 they are important to the gaming industry. Boxes can really help in
 the case where the site is trying to do the right thing and wants to
 avoid prompting the user, and also would allow introducing new global
 strategies such as an actual API-exposed cache (service workers' Cache
 API is all-or-nothing like any other API), or boxes with a max-age.


 --
 https://annevankesteren.nl/

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Jonas Sicking]

On Tue, Apr 28, 2015 at 9:16 AM, Majid Valipour maji...@google.com wrote:
 On Mon, Apr 27, 2015 at 9:54 PM Jonas Sicking jo...@sicking.cc 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 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;


 Interesting. I believe Simon has also proposed a similar API for which you
 can find my original objections here.

 One of my objections was that any proposed API should give developers
 control of scroll restoration per individual history entry. Initially I
 assumed a single boolean flag cannot provide that control but now I believe
 what you are proposing here can in fact provide per-entry control. More on
 this later.

 My other objection was that because scroll restoration behaviour is
 ultimately tied to a specific history entry, the API to control it should
 reflect this underlying fact. IMO a flag on history object hides this fact
 while original proposal does not.

 I understand that for pages that do not create any state other than their
 default initial state (e.g., infinite scrollers) setting
 history.restoreScroll is simpler than using
 history.replaceState({restorScroll: false}). But I think this additional
 complexity is not prohibitive and can be justified when the upside is an API
 that better explains the underlying behaviour and is simpler for pages that
 do create multiple states using history.pushState.

I agree that the difference between

history.restoreScroll = false;
and
history.replaceState({restoreScroll: false});

is not that big and mainly comes down to taste. I like the former more.

 This property would default to true. Whenever pushState() is called,
 or the user navigates away from the current page, for example by
 clicking a a href=... the value of history.restoreScroll is copied
 into the session-history-entry data that the browser keeps internally.
 As soon as the new session-history-entry is created, restoreScroll is
 set to true again.

 So history.restoreScroll is copied into current history entry anytime a new
 history entry is created (or replaced). If my reading is correct then this
 makes sense and it can give per history entry control. The value of
 history.restoreScroll is reset to its default when a new document is loaded.

 Consider this case where page A uses pushState once and then navigates to
 page B. This creates three history entries: 2 for A and one for B.

 A  --  Ai  (*)   == B
 where:
 --  pushState
 == navigation to new page
 (*) history.restoreScroll is set to 'false'

 This is what I think should happen:
 on A load:  history.restoreScroll is reset to default value: TRUE.
   history entry is created for A.

 on --:current entry (A) is updated with current restoreScroll: TRUE
history entry is created for Ai

 on (*):  history.restoreScroll is set to 'FALSE'.

 on ==:current entry (Ai) is updated with current restoreScroll:
 FALSE

 on B load:  history.restoreScroll is reset to default value: TRUE
history entry for B is created.

 A gets TRUE
 Ai gets FALSE
 B gets TRUE

Agreed.

 Additionally we could enable passing a boolean to pushState(), and
 this value would be used as the new initial value for restoreScroll.
 So something like pushState({ url: myURL, restoreScroll: false });.
 This would simply be syntax sugar for |pushState(, , myURL);
 history.restoreScroll = false;|.

 It is a nice syntax sugar but I don't feel it adds enough value to justify
 doing this at browser level. It can be done in Javascript by
 framework/poly-fill authors.

I'm fine either way.

 I think that's all that's needed.

 Yes. Both APIs are equally expressive and one may be built on top of the
 other.

 I suggest two minor changes though:

 1. We specifically proposed using a dictionary for options with scroll
 restoration being one of its parameters. This allows us to add additional
 history entry control parameters in the future. For example we can expose
 zoom restoration similarly if there is enough demand.
 2. As suggested earlier in the thread it is better to use a name that
 suggests more strongly that the author is expected to restore the position
 themselves.

 So:

 history.options = {
willRestoreScroll =  false
 }

I'm not strongly opinionated on naming. Are there other APIs in the
platform which are named similarly?

 In order to make it easier for pages we could also expose a
 history.restoredScrollPosition which is a readonly property which the
 UA writes to any time it restores a session history entry, which is
 the scroll position that it would have restored scrolling to if the
 page hadn't disabled scroll restoration for the given session history
 entry.

 This is isn't strictly needed though since the page can simply use
 sessionStorage

Re: [whatwg] EventSource and data URLs

[Jonas Sicking]

On Mon, Apr 27, 2015 at 7:37 PM, duanyao duan...@ustc.edu 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. The
problem with data: URLs is that the same API sometimes does a network
load, and sometimes parses content and runs in your security origin.

I'm happy to have a way to opt-in to enable loading data: in iframes
and Workers. But I strongly prefer an explicit opt-in.

Note that the chrome team apparently currently feels that data: in
iframe is so unsafe that they always load it in a sandbox. And never
allow data: in Workers. There's no way to even opt in to having it
behave any other way.

/ Jonas

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Jonas Sicking]

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 property would default to true. Whenever pushState() is called,
or the user navigates away from the current page, for example by
clicking a a href=... the value of history.restoreScroll is copied
into the session-history-entry data that the browser keeps internally.
As soon as the new session-history-entry is created, restoreScroll is
set to true again.

Additionally we could enable passing a boolean to pushState(), and
this value would be used as the new initial value for restoreScroll.
So something like pushState({ url: myURL, restoreScroll: false });.
This would simply be syntax sugar for |pushState(, , myURL);
history.restoreScroll = false;|.

I think that's all that's needed.

In order to make it easier for pages we could also expose a
history.restoredScrollPosition which is a readonly property which the
UA writes to any time it restores a session history entry, which is
the scroll position that it would have restored scrolling to if the
page hadn't disabled scroll restoration for the given session history
entry.

This is isn't strictly needed though since the page can simply use
sessionStorage and update the scroll position in a onscroll handler.
But history.restoredScrollPosition would reduce boilerplate code.
Also, using sessionStorage is somewhat complex to do correctly given
that the user might visit the same URL multiple times in the same
session.

(As an aside, it would be great if we had something like
sessionStorage, but specific for a given page. Right now
sessionStorage seems to make it very hard to store page specific state
unless I'm missing something obvious?)

/ Jonas


On Thu, Apr 23, 2015 at 3:25 PM, Majid Valipour maji...@chromium.org wrote:
 On Tue, Apr 21, 2015 at 4:58 PM Ian Hickson i...@hixie.ch wrote:

 On Sun, 12 Apr 2015, Anne van Kesteren wrote:
  On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson i...@hixie.ch wrote:
   I'd strongly recommend against adding new methods. It'll mean we now
   have two different ways to do the same thing, which means more bugs,
   which means less interoperability, more confusing behaviour for
   authors, more to document, etc.
 
  If the existing method didn't have the flaw with the title argument I
  wouldn't have suggested it. Also, since they both built upon the same
  primitive I think we'd be okay in the bugs and interop department.

 You are more optimistic than I. In any case, I strongly recommend against
 such redundancy.


 On Wed, 15 Apr 2015, Majid Valipour wrote:
 
  Actually URL is optional in current spec and it defaults to current URL.
  Why is this suboptimal?

 Because it means you can't bookmark the state or share the state,
 reloading the page loses the state, etc.


  In anycase If making URL required is a goal then it is best done by
  introducing a new method to avoid breaking compatibility.

 Why is that better?

 Changing the optional third argument to become required on the existing
 methods will break any call site that is not passing it. This is a non
 trivial compatibility issue which does not exists with a new method.



  I personally find a dictionary with only optional members which have
  appropriate defaults to be very convenient.

 I don't disagree... for new APIs. But when we already have an existing
 API, maintaining consistency and lack of redundancy IMHO trumps pretty
 much everything else, if you want the end result to be usable.

 A lot of the pain with using the Web's APIs is the inconsistency and
 redundancy that is rampant throughout.


 I understand the desire for maintaining consistency and reducing
 redundancy. On the other hand a new API will allow fixing some existing
 warts. I can see merits in both arguments. I am happy to defer the API
 decision to spec editors.

 I created the W3C bug for this proposal:
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28553

 Majid

Re: [whatwg] EventSource and data URLs

[Jonas Sicking]

On Mon, Apr 27, 2015 at 2:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Apr 27, 2015 at 7:00 AM, Anne van Kesteren ann...@annevk.nl 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=1156137

 What's the convergence we want here?

 It's rather frustrating when data: urls don't work in various places;
 they're an invaluable debugging tool, at minimum.  They should
 generally be treated as the same security level as the page, no?

There's definitely exceptions to this. For example chrome doesn't run
a iframe src=data:... with the same origin as its parent. For IMHO
good reasons since it's a potential XSS vector if a website accepts
URLs from third parties and render them inside a child iframe.

The same problem exists with accepting data: URLs in new Worker(...).

So no, I don't think it should be treated as the same security level
as the page.

For data-loading APIs, rather than script-running APIs, I see less of
such risk though.

/ Jonas

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

[Jonas Sicking]

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.

/ Jonas



On Wed, Mar 25, 2015 at 6:54 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, Mar 19, 2015 at 6:31 PM, Majid Valipour maji...@chromium.org wrote:
 partial interface History {
   void pushState(in any data, in DOMString title, in optional DOMString
 url, in optional StateOptions options);
   void replaceState(in any data, in DOMString title, in optional DOMString
 url, in optional StateOptions options);
   readonly attribute StateOptions options;
 };

 dictionary StateOptions {
 Boolean restoreScroll = true,
 }

 The only suggestion I have is that instead of having four-argument
 methods we might want to consider introducing two new methods that
 take a dictionary. E.g. history.push() and history.replace(). Giving
 the page more control over the scroll position when navigating makes
 sense to me.


 --
 https://annevankesteren.nl/

Re: [whatwg] Standardizing autocapitalize

[Jonas Sicking]

On Tue, Mar 10, 2015 at 5:54 PM, Mounir Lamouri mou...@lamouri.fr wrote:
 On Tue, 10 Mar 2015, at 22:44, Jonas Sicking wrote:
 On Tue, Mar 10, 2015 at 3:05 PM, Mounir Lamouri mou...@lamouri.fr
 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 as
  deprecated, but unless their usage is negligible, it seems better to
  document their behavior than to try to change all existing content not
  to use it.
 
  Especially since it'll also make the .autocapitalize JS property
  behave less surprising on/off is used.
 
  off is defined. The Non-conforming note means that the attribute
  reflection will behave like this:
  ```js
  input.autocapitalize = 'off';
  input.autocapitalize === 'none'; // true
  ```

 Right. My point is that this is unnecessarily confusing. Just like

 input.autocapitalize = 'on';
 input.autocapitalize === 'sentences'; // true

 is unnecessarily confusing.

 How is that different from
 ```js
 input.type = 'foo';
 input.type === 'text'; // true
 ```
 Unless we expect that doing |input.autocapitalize = 'on'| is common use
 case. Which I think isn't.

My point is that if 'on' and 'off' are commonly used on the web,
either in markup or in JS, then they are likely to stay so and we
should make sure that they work well. I.e. that they behave logically
and are well documented. That includes making them map properly to the
JS property, like most other attributes in HTML.

This is just my opinion though. I think mozilla would implement either way.

/ Jonas

Re: [whatwg] Standardizing autocapitalize

[Jonas Sicking]

On Tue, Mar 10, 2015 at 1:29 PM, Mounir Lamouri mou...@lamouri.fr 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 implementation cost
 should be fairly low while it can be very beneficial for the user
 experience with the keyboard on Mobile.

 I wrote a small proposal document based on Apple's document and live
 tests on latest Safari mobile:
 https://github.com/mounirlamouri/html-autocapitalize/blob/master/proposal.md

 I would be really interested to hear from other vendors, particularly if
 they would be interested to implement it.
 In addition, if Apple has some feedback about the proposal, it would be
 very valuable.

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 as
deprecated, but unless their usage is negligible, it seems better to
document their behavior than to try to change all existing content not
to use it.

Especially since it'll also make the .autocapitalize JS property
behave less surprising on/off is used.

/ Jonas

Re: [whatwg] Standardizing autocapitalize

[Jonas Sicking]

On Tue, Mar 10, 2015 at 3:05 PM, Mounir Lamouri mou...@lamouri.fr 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 as
 deprecated, but unless their usage is negligible, it seems better to
 document their behavior than to try to change all existing content not
 to use it.

 Especially since it'll also make the .autocapitalize JS property
 behave less surprising on/off is used.

 off is defined. The Non-conforming note means that the attribute
 reflection will behave like this:
 ```js
 input.autocapitalize = 'off';
 input.autocapitalize === 'none'; // true
 ```

Right. My point is that this is unnecessarily confusing. Just like

input.autocapitalize = 'on';
input.autocapitalize === 'sentences'; // true

is unnecessarily confusing.

Just like leaving mention of on out of documentation and specs would
be confusing for authors that are looking at other people's code and
learning from it (which is one of the great powers of the web
platform).

/ Jonas

Re: [whatwg] MessageEvent and ports

[Jonas Sicking]

On Fri, Mar 6, 2015 at 5:05 AM, Anne van Kesteren ann...@annevk.nl 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 postMessaging.

/ Jonas

Re: [whatwg] New approach to activities/intents

[Jonas Sicking]

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 input type=file.

However there's a couple of use cases that seems good to address.

First off, I think we also need to enable websites to render a share
button inside the page. This is sometimes useful simply in order to
share a canonical URL for a piece of content, rather than the URL that
the user is currently looking at. For example in a feed page which
contains multiple articles it'd be good to enable sharing a specific
article.

Second, it would be good to enable sharing more than just URLs. While
URLs are definitely a very common use case, being able to directly
share for example an image. For example to share an image with an
email application in order to add the image itself as an attachment.
This is also needed for the save as and input type=file use cases.

Another example of this is sharing a piece of text. I've seen websites
which allow selecting a piece of text and then click a twitter button
in order to tweet the selected text. Though I'm not sure how common
this is.

In order to support this we need not just a way to register handlers,
but also a more powerful API for those handlers to receive the shared
content. This is needed in order to enable the handler to receive a
blob.

A last use case which I think at this point is a bit more theoretical
is the ability to search the web for websites that can handle sharing.
This in order to enable UAs to build UI which allows the user to not
just choose from websites that the user has accepted registration
from, but also to search the web for other websites to share through.

This might be less useful for the simple case of sharing a generic URL
since there would be lots and lots of websites that could handle that,
and very little data to enable the UA to find the most relevant ones.

But if we expand this API to cover more than sharing (which I hope we
eventually will), or if we enable registering for handling sharing of
particular types (images vs. music vs. pdf vs. spreadsheets) then this
might be a more interesting use case.

/ Jonas


On Mon, Nov 3, 2014 at 8:42 AM, Anne van Kesteren ann...@annevk.nl wrote:
 A couple of us at Mozilla have been trying to figure out how to revive
 activities/intents for the web. Both work relatively well in closed
 environments such as Firefox OS and Android, but seem harder to deploy
 in a generic way on the web.

 What we've been looking at instead is solving a smaller use case. A
 Sharing API to start and then hopefully reuse the building blocks for
 other features that need to be liberated.

 https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very
 minimal Sharing API could look like.

 Our thinking is that something like the overlay browsing context could
 be reused to make e.g. input type=file or save as extensible going
 forward.

 However, admittedly it still doesn't really click. It feels a bit too
 much like e.g. the various search extensions browsers offer. Too much
 work for little return. Furthermore, freeing the web somehow from
 closely knitted silos seems like a worthwhile goal, but is often
 counter to what those silos are interested in. So it might be that
 we're still not quite there yet, thoughts appreciated.

 (I put WebApps and TAG on bcc, hope that's okay.)


 --
 https://annevankesteren.nl/

Re: [whatwg] Controlling the User-Agent header from script

[Jonas Sicking]

On Tue, Oct 14, 2014 at 12:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, Oct 14, 2014 at 1:02 AM, Jonas Sicking jo...@sicking.cc 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
 behind firewalls, but also websites that use cookies for
 authentication. I.e. most websites.

 I thought maybe if we just allow it to be omitted (and not set to any
 value) it would be okay. Just like we allow Referrer to be omitted.
 But maybe not.

I'd rather not. Seems like an unknown amount of risk for a pretty low
value. I would imagine that the main use case is to set a different
UA, not remove the UA.

/ Jonas

Re: [whatwg] Controlling the User-Agent header from script

[Jonas Sicking]

On Mon, Oct 13, 2014 at 6:53 AM, Anne van Kesteren ann...@annevk.nl 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 can think of would be an firewall situation that
 uses the User-Agent header as authentication check for certain
 resources.

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
behind firewalls, but also websites that use cookies for
authentication. I.e. most websites.

I still have some concerns about this. Though I can't think of any
problems off the top of my head. I suspect we'll want to run this past
our security team to make sure we're not missing anything.

FWIW, I don't think there's any difference between XHR and fetch(). If
we enable this for fetch(), I don't see a reason not to enable it for
XHR as well since it should mainly involve removing User-Agent from
some internal blacklist in the code.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Wed, Oct 8, 2014 at 7:13 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, Oct 7, 2014 at 7:33 PM, Jonas Sicking jo...@sicking.cc 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 this is the common scenario.

 The reason I think we should use timeouts is that this matches all
 OS-native non-persistent notifications that I know of, and also seems
 like a better UX.

 I started to remove the close event and then I noticed we also use it
 when a notification gets replaced by a newer one. Do we care about
 that?

Interesting. Though if we don't need an event for .close() being
called, I suspect we won't need one for a notification being replace.
It seems somewhat rare that either of these things would provide
significant use to the app if the notification is going away soon
anyway.

Also, BroadcastChannel was created to allow people to handle these
types of things themselves if needed. So we're not leaving people
without a workaround if for some reason there is a use case here.

/ Jonas

Re: [whatwg] Notifications: making requestPermission() return a promise

[Jonas Sicking]

On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
 dome...@domenicdenicola.com 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 is all. So yes, agreed with Tobie et al.

Another thing to keep in mind here is that it's pretty easy to convert
between either of these behaviors. It's just a matter of either doing

requestPermission().then((r) = { if (!r) throw Error(...) })

requestPermission().then(() = true, () = false)

Or, using the await syntax

async function() {
  if (!await requestPermission())
throw Error(...);
}

async function() {
  hasPermission = true;
  try {
await requestPermission();
  }
  catch {
hasPermission = false;
  }
}

So I think a more important question here is what behavior would an
author expect. I think one of the points Dominic tried to make earlier
is that the name is important for setting that expectation and help
authors understand how the function behaves. Sadly the name that we're
stuck with doesn't really provide much guidance either way.

But I think to some extent it's indicating that we're bikeshedding here.

/ Jonas

Re: [whatwg] Notifications: making requestPermission() return a promise

[Jonas Sicking]

On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com 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.

 A user saying no to notifications is not an error. You ask the user to
 make a decision, the user decides. Either way is a success. An error
 would be invoking the method in the wrong way.

This is more of a coding pattern thing than an expectation thing.

For example in gecko we often implement security checks by calling
functions that throw exceptions if the security check failed. Mainly
because this means less typing. So rather than writing:

function implDOMThingy(x, y, z) {
  if (!callerCanAccess(x))
throw Error(...);

  if (!isSameOrigin(x,y))
throw Error(...);

  ... do stuff here ...
}

we write

function implDOMThingy(x, y, z) {
  assertCanAccess(x);
  assertSameOrigin(x,y);

  ... do stuff here ...
}

So assertCanAccess/assertSameOrigin throws exceptions if a given
security check doesn't pass. Not because the security function was
called the wrong way or otherwise had an error, but because it makes
callsites easier to write.

However the experience that I personally have with this pattern is
that it requires that the throwing function takes care of everything
that needs to happen when an exception is thrown. For us that meant
things like log errors to the developer console. So this is more
appropriate in places when the throwing function provides a complete
package of functionality.

This also means that the functions are less reusable. Since they don't
just do one thing.

But it is quite awesome when you have such a resuable package that you
can use in several callsites. Definitely makes the code less
cluttered.

But I think that's an indication that we should not do that here. I
would for example expect that authors want to put up some UI to the
user indicating that the reason some feature isn't working is because
the user has denied access.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Tue, Oct 7, 2014 at 5:42 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Mon, Oct 6, 2014 at 9:11 PM, Jonas Sicking jo...@sicking.cc 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-persistent notification, would you not want to
 know when the user agent closed it (only relevant if the user agent
 closes them before the document closes)?

 If that scenario is not important, we could remove this event too I think.

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 this is the common scenario.

The reason I think we should use timeouts is that this matches all
OS-native non-persistent notifications that I know of, and also seems
like a better UX.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Mon, Oct 6, 2014 at 12:05 AM, Andrew Wilson atwil...@google.com wrote:
 On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc 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
 it though I might have done something wrong.

 AFAICT, no - gmail for android doesn't use web notifications. In
 general the mobile versions of gmail are kind of bare-boned fallbacks
 in favor of the native apps.

Actually, my question was in regards to the native gmail app. Not
web content of any sort.

 I'm not sure that we should pay too much attention to the use case of
 apps like gmail that want to do lots of hands-on control of their
 notifications - I think that's pretty much a rare case. I do think
 it's useful to have some guidelines for how platforms handle
 notifications, though, just to make sure that some web developer
 doesn't just test on one platform, and get unexpected behavior on
 others.

 So, trying to encourage auto-close behavior (maybe via SHOULD language
 in the spec) would be good for consistency's sake. Clarifying what
 should happen when the user clicks on a notification would also be
 good (should it bring the tab to the foreground? Should it leave it up
 to the app? Should it provide a default, but allow apps to override
 it?) - I think all three of these behaviors are currently implemented
 (or have been in the past) by different UAs.

I agree with this.

Generally speaking we tend to leave UI up to browsers and avoid
speccing it. However given that notifications is all about UI I think
doing so effectively makes the feature untrustable for authors. We
don't need to define exact pixels etc, but I think we need to define
some semantics in the form of expected behavior of UI.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Oct 1, 2014 4:31 AM, Anne van Kesteren ann...@annevk.nl 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. without having to get a reference to the
notification instance.

This is probably extra helpful if .get() doesn't return non-persistent
notifications. For example to simplify the case when one tab creates a
notification, but then the user opens the same app in another tab. The
newly opened window might want to close any notifications about pending
messages.

This could be accomplished using BroadcastChannel, but would be much
simpler if we had the ability to close directly using a tag.

In fact, the common case when wanting to close a notification is likely one
where you know which tag you want to close, but don't have a reference to a
Notification instance.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Mon, Oct 6, 2014 at 9:26 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc 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 all about using UI to get certain types of user
 attention.

 I'm willing to try making more specific UI recommendations. Have any in mind?

I think we should define that non-persistent notifications disappear
after a timeout. And define that on mobile platforms with
notification centers, that these notifications are *not* added
there, but rather is just displayed on screen for a short period of
time.

I also think that we should define that for persistent notifications,
that these *are* added to mobile notification centers.

I also think that we should define that clicking a non-permanent
should as default action focus the window which created the
notification. We should also define that during the click event the
browser is encouraged to allow calls to window.focus() to, work. Even
in UAs which have restrictive policies about when window.focus() is
honored.

Though some care needs to be taken to not enable pop-unders, but as
long as we don't require that UAs honor window.focus() and instead
just encourage it, I think that's covered.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Mon, Oct 6, 2014 at 9:29 AM, Anne van Kesteren ann...@annevk.nl 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 platform policy. And maybe also closed because
 of application calling .close(). Otherwise it doesn't seem like it
 meets Andrew's use case or the use case above.

 I added the service worker API now, but have not addressed this
 particular point yet. Does anyone have a good idea of what should be
 done here?

If we keep the close event, then I think adding a .reason property to
the event object, which can be set to user, platform or api
should work.

Though based on Andrew's latest comments, I don't know that anyone
strongly feels that we need to keep the event?

/ Jonas

Re: [whatwg] Adding a property to navigator for getting device model

[Jonas Sicking]

On Thu, Oct 2, 2014 at 9:24 PM, eberhard speer jr. ses...@ducis.net 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 need to do look up
device capabilities using UA-sniffing and DeviceMap? I.e. when can't
they use JS code and the APIs exposed through the DOM to detect what
capabilities are available, and instead they have to look up these
capabilities in DeviceMap?

For server-side UA sniffing these situations are much more clear since
the server has information to *much* less information. I.e. the server
only has access to the headers that the browser sent.

However JS code running in a browser has access to a much richer
amount of information. So when does it need to use DeviceMap?

/ Jonas

Re: [whatwg] Adding a property to navigator for getting device model

[Jonas Sicking]

On Fri, Oct 3, 2014 at 5:09 AM, eberhard speer jr. ses...@ducis.net 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.
 ses...@ducis.net 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 need to do look up
 device capabilities using UA-sniffing and DeviceMap? I.e. when
 can't they use JS code and the APIs exposed through the DOM to
 detect what capabilities are available, and instead they have to
 look up these capabilities in DeviceMap?

 For server-side UA sniffing these situations are much more clear
 since the server has information to *much* less information. I.e.
 the server only has access to the headers that the browser sent.

 However JS code running in a browser has access to a much richer
 amount of information. So when does it need to use DeviceMap?

 / Jonas

 Hi,

 I fear you greatly oversimplify matters.
 For starters, 'responsive design' is not the only use case and
 secondly it is not the case that the server is at a disadvantage
 information wise, as a matter of fact, once a device is linked to a
 known UA-profile the opposite is very much the case.
 I must say I'm somewhat taken aback by this dismissive attitude.

I fear that you must have somehow misread my email above.

I did intend to focus only on responsive design. In fact, I did not
mention responsive design at all. I instead tried to ask broadly for
use cases where people use DeviceMap since you graciously offered to
help with providing them.

It was also not my intent to be dismissive of anything. Neither
people, use cases, software stacks, requirements or opinions. I'm not
sure what it is that you feel that I was dismissive of but I apologize
and can only assure you that that was not my intent at all.

I did however want to specifically focus the discussion about client
side practices and use cases. The reason for this is not that I feel
like server side practices and use cases are not important, but rather
that the topic of this thread is whether to add a clicent-side
property specifically to make it easier for people that use things
like DeviceMap on the client side.

It still does seem to me that client side logic running in a browser
has access to a richer set of information about that browser than
server side logic which received a network request from that browser.
Simply because the client side logic has access to the same
information about the browser as the server side does. But in addition
it can use JS and the DOM to check for existence or non-existence of
hundreds of APIs, as well as use a handful of APIs that were
specifically designed to expose information about the browser.

However I could very well be wrong about that. But that is simply due
to being uninformed and had no origin in malice or uncaringness at
all. I could see for example that server side logic has much more
efficient access to databases such as DeviceMap. I had thought that
client side logic could access the same type of databases using
network requests, but perhaps that is often not practical due to
performance constraints. So I definitely imagine that I could be wrong
about which environment effectively has access to better information.
But I'd rather not guess at where I made an error in logic and would
instead appreciate if you point out where I'm making the wrong
assumptions.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Sep 30, 2014 1:26 AM, Andrew Wilson atwil...@google.com 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 
 notification is hidden, but agreed, it's a problem. It's frankly one of the 
 major flaws of the original spec that behavior like this isn't well 
 specified, because it really prevents applications from doing anything 
 particularly sophisticated around notification management, because you can't 
 keep notifications on-screen if the notification platform wants to close 
 them, and you can't easily differentiate between user-close and system-close.

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 all about using UI to get certain types of user
attention.

The fact that platform conventions, and browser conventions, for
notifications vary wildly is indeed a big problem.

One possible solutions to this is to go really high level and create
an API which caters to the lowest common denominator.

Another solution is to go super low level and expose lots of API which
is describe and expose platform behavior in detail, and then ask
application code to write logic to deal with the differences.

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
it though I might have done something wrong.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Wed, Oct 1, 2014 at 4:31 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo bever...@google.com wrote:
 * Life-time of existing notifications.

 Chrome currently treats Web Notifications as persistent ones. When the
 page goes away, the notification stays. Interaction with the notification is
 not going to trigger anything anymore. While I'm in favor of changing this,
 we have to be very cautious to not break user expectations of existing users
 of the Web Notification API, for example in calendar applications.

 I think from the perspective of the specification this does not change
 anything. If a platform wants to log all notifications that is fine.
 What we want to start calling persistent notifications are those for
 which a service worker will get notified and which can be retrieved
 using Notification.get(). Hopefully browsers and platforms evolve over
 time to distinguish the two more clearly.

As long as all implementations are willing to change |new
Notification| to be non-persistent then that's fine. Note that
non-persistent is different from doesn't fire a callback when
clicked. While JS running in the page can't tell a difference, the
user certainly can so it can still be perceived as a breaking change.

 * Dropping the close event.

 Synchronizing closing of the notification on all the user's devices is an
 interesting one, but opt-in would be sufficient for this.

 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 platform policy. And maybe also closed because
of application calling .close(). Otherwise it doesn't seem like it
meets Andrew's use case or the use case above.

 * Not using the constructor for persistent notifications.

 I have no strong feelings here either, and think it's fine to continue using
 the constructor with the serviceWorker property set. Both would still use
 the Notification statics. Having a promise would clean up the error handling
 a bit, which may occur in the no-permission case.

 It seems nicer to have the association with the registration be
 implicit by having a method on that object (reg.createNotification()).
 However, it's very much the factory pattern which is somewhat frowned
 upon. But hopefully it's not too bad here.

Note that I don't actually think that we need to even return a
Notification instance when a persistent notification is created.
There's no events being fired on such a Notification instance and it
doesn't provide any other functionality. It only contains the
information that was just passed to the createNotification call.

So it wouldn't even be a factory method if we simply don't return a
Notification.

 Combined with dropping the open event, I think I have enough to rework
 the current Notifications API. Is there anything I'm missing?

I think this covers the basic changes needed to enable proper support
for persistent vs. non-persistent notifications, which is a big
improvement.

But I think there's also a lot of additional features that are needed,
but that's probably better done separately. Especially since that has
less consensus I believe. I'm thinking of things like buttons,
progress bars, extra-persistent notifications, control over sound
and/or vibration, control over whether it turns on the screen, text
input, etc.

But at the very least these warrant separate threads.

/ Jonas

Re: [whatwg] Adding a property to navigator for getting device model

[Jonas Sicking]

On Thu, Oct 2, 2014 at 3:57 AM, Mounir Lamouri mou...@lamouri.fr wrote:
 On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote:
 On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote:
  On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote:
  On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr
  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
   property available?
 
  I know that the Cordova module for exposing this information is one of
  the most popular Cordova modules, so that's a pretty good indication.
  But I don't have data directly from websites.
 
  When you were pointing that websites currently do UA sniffing is it on
  the client side of the server side?

 I'd imagine UA sniffing happens more often on the server side, though
 I suspect it varies with the reason why people do it.

 But the Cordova API is client side, so there's definitely desire to
 have it there too.

 Isn't Cordova experience feedback a bit out of scope if usually
 developers do UA sniffing on the server side? It seems that such a
 feature would mostly benefit web sites that already entirely live on the
 client side and might be more inclined to do feature detection.

If feature detection covered all the use cases, then why would the
Cordova module be so popular?

/ Jonas

Re: [whatwg] Adding a property to navigator for getting device model

[Jonas Sicking]

On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote:
 On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote:
 On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr
 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
  property available?

 I know that the Cordova module for exposing this information is one of
 the most popular Cordova modules, so that's a pretty good indication.
 But I don't have data directly from websites.

 When you were pointing that websites currently do UA sniffing is it on
 the client side of the server side?

I'd imagine UA sniffing happens more often on the server side, though
I suspect it varies with the reason why people do it.

But the Cordova API is client side, so there's definitely desire to
have it there too.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Sep 30, 2014 12:48 AM, Andrew Wilson atwil...@google.com wrote:



 On Mon, Sep 29, 2014 at 9:14 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson atwil...@google.com
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 keeps its own queue of
pending
  notifications (so if several emails arrive at once, we don't display
seven
  notifications simultaneously, but instead we display one at a time,
cycling
  through them after 5-6 seconds). If the user closes a notification,
then we
  clear out our queue of pending notifications, because the expectation
is
  that the user doesn't want any more email notifications (the experience
  before we did that was really annoying).

 Ah, so the fact that the user close one notification is seen as an
 indicator that the user doesn't want more notifications right now.

 This definitely seems like the best use case for the close event so
 far. Though it doesn't seem like you'd actually want a service worker,
 or indeed the full app, to be started up in order to handle that
 event.

 For an app that wants to do something like this, but the app uses
 persistent notifications, I think using Notification.get() is the best
 solution. This way the application can catch closing of notifications
 whenever they happen, but the app still doesn't need to be woken up if
 it's not running when a notification is closed.

 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.

  2) When closing a chat notification, we tell the chat subsystem that
the
  notification has gone away so that it can clear its reference to the
  Notification. The chat subsystem keeps a reference to the notification
so it
  can close a chat notification if the user clicks on a chat frame, but
this
  might no longer be necessary if we implement Notification.get().
Anyhow, our
  reference to the chat subsystem is a reference to an object and that
object
  isn't structured-cloneable because it has a bunch of reference to DOM
  elements, etc.

 Interesting. Yeah, Notification.get() seems like it would help you
 solve this. Though potentially the API should also have a function
 like Notification.close(DOMString tag). Seems like a common use case
 of wanting to close a notification when the user engages with a piece
 of UI, and it seems silly to have to instantiate a Notification
 instance through .get() to do so.

  The other reason we handle the close event is that gmail has this idea
of a
  chat notification that the user hasn't seen yet - the chat frame has a
  visual highlight. But if the notification is dismissed by the user, we
can
  clear this highlight, under the assumption that the user has seen this
  notification. This functionality may be somewhat broken on platforms
that
  auto-close notifications though.

 Yeah, this is the case that Jake brought up. Though Tab pointed out
 that other chat systems generally does not treat close as an hint
 for user has read. Interesting to hear that gmail does.

 On what platforms do non-persistent notifications not close after a
timeout?

 My test on mac and linux chrome just showed that notifications never
close on those platforms.

I guess I don't know enough about the ins and outs of osx notifications.
But all my other osx apps remove notifications after a few seconds. But it
is of course chrome's choice what UI to display.

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?

/ Jonas

Re: [whatwg] Adding a property to navigator for getting device model

[Jonas Sicking]

On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr 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
 property available?

I know that the Cordova module for exposing this information is one of
the most popular Cordova modules, so that's a pretty good indication.
But I don't have data directly from websites.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Sun, Sep 28, 2014 at 11:15 PM, Andrew Wilson atwil...@google.com 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. There is the dismiss
 all button on most platforms, which definitely does not imply having read
 the message. It's actually an interesting privacy question as well, for
 example, if a user dismisses a Facebook notification in their notification
 center without actually starting the app, should the sender be informed
 about them having at least looked at their phone?

 Gmail tracks information internally about all open notifications so it knows
 what chat window, email, etc to display when the user clicks on one. It
 cleans up those data structures as notifications are closed, so if we stop
 generating close events, then gmail will leak even more memory than it
 currently does :)

Could this be solved by using the 'data' attribute when creating a Notification?

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Mon, Sep 29, 2014 at 3:10 AM, Andrew Wilson atwil...@google.com wrote:
 That only works if 'data' is a structured-cloneable data structure.

Per spec it is yes.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com 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 functions, etc.

 I'm aware that 'data' is structured-cloneable - I'm saying that's not
 sufficient for many uses.

But if the data that you want to associate with the notification isn't
structured clonable, how are you going to make that data survive a
page reload? Keep in mind that for persistent notifications, the
notification often outlives the page that created the notification.

It might help to have some concrete examples of what you're trying to do here.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Mon, Sep 29, 2014 at 4:55 AM, Andrew Wilson atwil...@google.com wrote:
 On Mon, Sep 29, 2014 at 1:40 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com
 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 functions, etc.
 
  I'm aware that 'data' is structured-cloneable - I'm saying that's not
  sufficient for many uses.

 But if the data that you want to associate with the notification isn't
 structured clonable, how are you going to make that data survive a
 page reload? Keep in mind that for persistent notifications, the
 notification often outlives the page that created the notification.

 OK, I get it - we're talking about different models. I'm talking about the
 current Gmail use case, where I don't want notifications to live forever (in
 fact, I close them all when you close the main Gmail pane).

 I understand that for persistent notifications, the uses are different. And
 again, apologies if I missed the context and the idea was to only remove the
 close event for persistent notifications - it's the danger of dropping into
 the middle of a thread :) Hopefully the plan is to continue enabling web
 properties that want to go the Gmail route to continue doing so, and for
 those pages, I think a 'close' event is useful.

I think we're talking about both. But I wanted to point out that the
code flow you were talking about didn't seem to work for persistent
notifications.

I'd rather keep persistent and non-persistent notifications as similar
as possible. Though as possible being key. I.e. I think it's ok for
them to be different when that makes sense.

I still don't understand the use case you are talking about though.
Could you perhaps provide an example of the features that gmail is
building and which needs these non-clonable data structures?

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson atwil...@google.com 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 keeps its own queue of pending
 notifications (so if several emails arrive at once, we don't display seven
 notifications simultaneously, but instead we display one at a time, cycling
 through them after 5-6 seconds). If the user closes a notification, then we
 clear out our queue of pending notifications, because the expectation is
 that the user doesn't want any more email notifications (the experience
 before we did that was really annoying).

Ah, so the fact that the user close one notification is seen as an
indicator that the user doesn't want more notifications right now.

This definitely seems like the best use case for the close event so
far. Though it doesn't seem like you'd actually want a service worker,
or indeed the full app, to be started up in order to handle that
event.

For an app that wants to do something like this, but the app uses
persistent notifications, I think using Notification.get() is the best
solution. This way the application can catch closing of notifications
whenever they happen, but the app still doesn't need to be woken up if
it's not running when a notification is closed.

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.

 2) When closing a chat notification, we tell the chat subsystem that the
 notification has gone away so that it can clear its reference to the
 Notification. The chat subsystem keeps a reference to the notification so it
 can close a chat notification if the user clicks on a chat frame, but this
 might no longer be necessary if we implement Notification.get(). Anyhow, our
 reference to the chat subsystem is a reference to an object and that object
 isn't structured-cloneable because it has a bunch of reference to DOM
 elements, etc.

Interesting. Yeah, Notification.get() seems like it would help you
solve this. Though potentially the API should also have a function
like Notification.close(DOMString tag). Seems like a common use case
of wanting to close a notification when the user engages with a piece
of UI, and it seems silly to have to instantiate a Notification
instance through .get() to do so.

 The other reason we handle the close event is that gmail has this idea of a
 chat notification that the user hasn't seen yet - the chat frame has a
 visual highlight. But if the notification is dismissed by the user, we can
 clear this highlight, under the assumption that the user has seen this
 notification. This functionality may be somewhat broken on platforms that
 auto-close notifications though.

Yeah, this is the case that Jake brought up. Though Tab pointed out
that other chat systems generally does not treat close as an hint
for user has read. Interesting to hear that gmail does.

On what platforms do non-persistent notifications not close after a timeout?

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com 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 functions, etc.

 I'm aware that 'data' is structured-cloneable - I'm saying that's not
 sufficient for many uses.

Based on your emails later in this thread, it sounds like gmail might
not be relying on being able to associate non-structured-clonable data
with non-persistent Notifications.

However I realized this morning that this actually is doable. You can
simply set expando properties, or use a WeakMap, to associate
arbitrary data with a Notification object instance.

So in case it's needed, or just beneficial, this is actually doable.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Mon, Sep 29, 2014 at 12:14 PM, Jonas Sicking jo...@sicking.cc 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.

Actually, I just realized that perhaps neither of these would work.

We've elsewhere in this thread talked about restricting
Notification.get() to only return persistent notifications.

And I think that on at least some platforms, possibly even most,
non-persistent notifications are closed after a timeout. So the
close event wouldn't indicate any user intent there.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking jo...@sicking.cc 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 will ever fire on it? Maybe we should have a function like

 promise = createPersistentNotification(...);
 promise.then(notificationWasShown, notificationWasRejected);

 Well presumably we still want to share an object of sorts as part of
 the event, so all the notification data is exposed somehow. A promise
 does not make much sense to me as a service worker can be killed at
 any point.

I'm not sure I understand what you are saying here. The above code is
the creation steps, not the notification steps.

I agree that the click event needs to expose the Notification
object. But the SW click event needs to be fired at the SW global,
and have as one of its properties the Notification object. Exactly
because the SW might have been killed previously and is just getting
spawned in order to fire the click event. Thus no other references
to the Notification object might exist.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Fri, Sep 26, 2014 at 6:40 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Fri, Sep 26, 2014 at 3:31 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
 promise = createPersistentNotification(...);
 promise.then(notificationWasShown, notificationWasRejected);

 Well presumably we still want to share an object of sorts as part of
 the event, so all the notification data is exposed somehow. A promise
 does not make much sense to me as a service worker can be killed at
 any point.

 I'm not sure I understand what you are saying here. The above code is
 the creation steps, not the notification steps.

 Oh, but shown implies it's displayed, which currently can happen
 later. But as per the other thread maybe we should get rid of that.
 Assuming we get rid of that, this seems to help a bit with error
 handling, but is otherwise mostly identical in approach to just
 keeping the constructor.

It's a good point that if the above call happens in a SW, then there's
no guarantee that it'll receive either of those callbacks.

So it comes down to if we need show, and I guess error, events.

One option that I could think of is that Windows that create a
notification could detect if the notification fails to be displayed,
and if so display in-page UI. Either to replace the notification, or
to indicate to the user that notifications currently don't work. In
this case the above API could work since a SW can't display such UI
anyway, and so it doesn't matter that it might not receive the promise
callbacks.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Fri, Sep 26, 2014 at 7:36 AM, Peter Beverloo bever...@google.com 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.)

 * Life-time of existing notifications.

 Chrome currently treats Web Notifications as persistent ones. When the
 page goes away, the notification stays. Interaction with the notification is
 not going to trigger anything anymore. While I'm in favor of changing this,
 we have to be very cautious to not break user expectations of existing users
 of the Web Notification API, for example in calendar applications.

The current situation feels pretty broken in that the API was designed
for, and only really works for, non-persistent notifications, however
all implementations implement persistent notifications, presumably
because that's what the most urgent need was.

I think we might need some form of transition period to transition to
whatever API we decide is the right one.

 * 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. There is the dismiss all
 button on most platforms, which definitely does not imply having read the
 message. It's actually an interesting privacy question as well, for example,
 if a user dismisses a Facebook notification in their notification center
 without actually starting the app, should the sender be informed about them
 having at least looked at their phone?

 Synchronizing closing of the notification on all the user's devices is an
 interesting one, but opt-in would be sufficient for this.

Ah, that's the best use case I've heard so far. Though, do you really
want to close a given notification on all devices just because the
user pressed clear all on one device?

Or is it better to close the notification on all devices once the user
engages with the relevant part of the app, for example by clicking the
notification.

 Given the cost of starting up a Service Worker, I'm interested in exploring
 opt-in. One potential optimization a UA could do is detect the events bound
 on a Service Worker's global when it starts, and check whether
 notificationclose is part of this for future invocations.

Yeah. Though I think interest in did this notification close will
vary with notification. Which means that if you are interested in
close events for one type of notifications in your app, suddenly you
pay the price for all of them.

 * Supporting non-persistent notifications in Service Workers.

 I'd prefer not to, especially if we would auto-close the notifications.
 There seems to be little point beyond indicating to the user that the
 Service Worker is running, which feels more like a UA thing if they choose
 to do so.

The main use case I can think of is if we enable playing audio from a
SW, in which case you might want to notify about change in songs.

But I'm fine with leaving this unsupported for now. As long as
whatever syntax we use doesn't preclude it from being added later
should the need arise.

 * Supporting non-persistent notifications in Shared and Dedicated Workers.

 As long as we continue to support non-persistent notifications, I see no
 reason not to do this. The globals of both kinds of workers have well
 defined lifetimes, making the notifications as reliable as in-page ones,
 most notably on desktop.

I'm a bit skeptical about tying even non-persistent notifications to
the lifetime of a global of any sort. Either window or worker.

If the use case of non-persistent notifications is to give
background apps some temporary screen real estate where they can
inform the user about a change, then shouldn't that generally
disappear after a short timeout?

I believe (but am not sure) that Android and iOS have the concept of
non-persistent notifications that are displayed at the top of the
screen for a few seconds. These do not go into the notification
center.

OSX is somewhat different in that it displays an on-screen
non-persistent notification. But it also adds the notification to a
notification center. Though this notification center is more of a
log than stuff that happened since you last looked at your device.
I.e. stuff on this list doesn't go away when you click it, and
applications don't remove items from here when you interact with the
app.

Most importantly, I don't know of any types of notifications on any
platform that go away when you close the app.

While I agree that we generally should leave UI up to UAs, we need to
have some model of what type of interaction authors can expect when
using various APIs. Leaving UI too undefined is part of what has
gotten us into the current somewhat messy state (though the lack of SW
certainly didn't help).

So all that said, I'm fine with allowing 

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Thu, Sep 25, 2014 at 3:02 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, Sep 25, 2014 at 2:28 AM, Jonas Sicking jo...@sicking.cc wrote:
 On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren ann...@annevk.nl wrote:
 Strawman: We classify existing notifications as non-persistent
 notifications. Only notifications associated with a service worker are
 persistent.

 This is a little bit implicit for my taste. But I don't feel very strongly.

 I think it makes a lot of sense if we require service workers for
 persistent notifications. I figured we could rename the field from
 serviceWorker to something more explicit, but I can't really think of
 a good name.


I was thinking of something more along the lines of using different
constructors for persistent vs. non-persistent notifications. But like
I said, I don't feel strongly.

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 will ever fire on it? Maybe we should have a function like

promise = createPersistentNotification(...);
promise.then(notificationWasShown, notificationWasRejected);

 That means we should tie normal non-persistent notifications to the
 lifetime of the global. I take it we still want to allow those within
 workers, right?

If we tie non-persistent notifications to the lifetime of a global,
then I don't know that it makes sense to allow them to be created from
a worker.

But maybe a better model is to define that non-persistent
notifications are shown for a small period of time. That's how they
seem to be implemented on existing OSs. OSX shows notifications for a
few seconds, then they go away.

 But maybe they are rare enough that by default we only fire click
 events. For persistent notifications we fire them at the SW, for
 non-persistent at the Notification object.

 If we in the future find actual use cases for close/show we can
 add ways to opt in to receiving those. And if we find use cases for
 *not* receiving click (in particular to SW) we can add ways to opt
 out of those.

 This strategy makes sense to me. If Jake and Peter (and everyone else
 who feels inclined :-)) could comment on this revised proposal that'd
 be great.

Having thought about this some more, I think it would create a very
messy API if we end up with

new Notification(Hello world, {
  body: ...,
  dontFireClick: true,
  requestExtraEvents: [show, close]
});

Generally speaking, starting a SW is a fairly expensive operation. So
I think it's good if APIs that hook into SW allow the author to be
explicit about what events they care about receiving.

OTOH, if we really can't think of any use cases for show/close events,
then it seems silly to require that every single caller specifies that
it wants to receive click and nothing else.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Thu, Sep 25, 2014 at 3:25 AM, Jake Archibald jaffathec...@gmail.com wrote:
 On 24 September 2014 01:21, Jonas Sicking jo...@sicking.cc 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 applications whose window is covered by other
 windows, call attention to themselves.

 I agree with Tab regarding track change. But more than that, we shouldn't be
 making a platform distinction here, that may not hold true in a few years.

Agreed.

 * I'm uncertain about if non-persistent notifications are important
 enough to target at this point. But I'm heavily biased from having
 worked mainly on mobile web lately.

 Not sure what you mean here. Aren't non-persistent notifications fully
 shipped and supported?

Do implementations really treat them as non-persistent? In FirefoxOS
we treat them as persistent. In Firefox for Android we put them in the
Android notification tray, where generally only persistent
notifications go I thought. And indeed we don't have any code to
automatically remove them.

But I don't know what other implementations do?

 * Alternatively, maybe we could simply get rid of the close event
 entirely. Does it have a use-case?

 Yeah:

 * User gets new chat message
 * Push message
 * Notification
 * User reads chat message but doesn't need to respond, dismisses
 notification
 * Close event
 * Message sent to the server to make message as read
 * Notifications auto-dismissed on other devices the user has

Hmm.. is close really a decent proxy for read? I personally often
read notifications without clearing them, since I read the temporary
on-screen notification. And on occasion when my notification tray
overflow, I clear notifications without reading them.

But I hate using my own usage patterns in design. Do we have any data
on what native applications do with similar callbacks? Assuming they
exist in other notification platforms...

  But maybe they are rare enough that by default we only fire click
  events. For persistent notifications we fire them at the SW, for
  non-persistent at the Notification object.
 
  If we in the future find actual use cases for close/show we can
  add ways to opt in to receiving those. And if we find use cases for
  *not* receiving click (in particular to SW) we can add ways to opt
  out of those.

 This strategy makes sense to me. If Jake and Peter (and everyone else
 who feels inclined :-)) could comment on this revised proposal that'd
 be great.

 I don't have a use-case for show right now, but I think we need to keep
 close for the use-case above. An events property could take an array to
 restrict the events a notification will fire (defaulting to all).

I'd really not want to use all as a default. That will result in us
starting service workers much more often than we need, which at best
is a battery drain, at worst is a performance issue.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Thu, Sep 25, 2014 at 4:42 PM, Tab Atkins Jr. jackalm...@gmail.com 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 whatever), which when pressed also cancels
 navigation in the app.  This seems like a specialized function of the
 app itself, using some future form of rich notifications, though, and
 not something we can or should generalize to other apps.  It's
 definitely not an example we should generalize to generic clearing
 out all my notifications behaviors, because it explicitly resists
 such things and requires an affirmative and purposeful action on the
 part of the user to dismiss it.

FWIW, I think there is a need for extra persistent notifications.
Which I think mainly mean that they don't get removed if the user
presses the clear all button in a notification tray. Or that the
notification wouldn't go away when simply clicked.

This type of notification can be useful for ongoing activities. Such
as navigational apps, or download progress.

API-wise this could be supported by simply adding an additional flag
to NotificationOptions, like resistClear: true or noclear: true.
This flag would be ignored for non-persistent notifications.

It might still be good for UAs to allow removing this type of
notification, but I think if and how to enable that is a UA decision.

/ Jonas

Re: [whatwg] Adding a property to navigator for getting device model

[Jonas Sicking]

On Sep 24, 2014 3:40 AM, James Graham ja...@hoppipolla.co.uk 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 in the UA string. That would at least help with the parsing
  problem.
 
  And if means that we could more quickly move the device model out of
  the UA string, then it also helps with the UA-string keying thing.

 It's not entirely clear this won't just leave us with the device string
 in two places, and unable to remove either of them. Do we have any
 evidence that the sites using UA detection will all change their code in
 relatively short order, or become unimportant enough that we are able to
 break them?

If we do, is that any worse than having the string in one place? If we are
stuck with having this information exposed to the web (which currently is
looking more likely than not), then I'd rather that authors had an easy
time doing so.

/ Jonas

Re: [whatwg] Adding a property to navigator for getting device model

[Jonas Sicking]

On Sep 24, 2014 3:51 AM, Silvia Pfeiffer silviapfeiff...@gmail.com
wrote:

 On 24 Sep 2014 20:40, James Graham ja...@hoppipolla.co.uk 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 in the UA string. That would at least help with the parsing
   problem.
  
   And if means that we could more quickly move the device model out of
   the UA string, then it also helps with the UA-string keying thing.
 
  It's not entirely clear this won't just leave us with the device string
  in two places, and unable to remove either of them. Do we have any
  evidence that the sites using UA detection will all change their code in
  relatively short order, or become unimportant enough that we are able to
  break them?

 Why don't we provide a better structure and not just a random string. For
 example: deviceID, browserID, renderingEngineVersion ... Not sure what
else
 would be useful to group actions that the developer needs to take. Haven't
 looked in detail.

I'm supportive of exposing any information that we are already exposing
through the UA string.

But most of it already is. Through various other properties on the
navigator object.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Sep 24, 2014 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
 * We should consider the case of persistent notifications separate
 from notifications that automatically close when a page goes away.

 Strawman: We classify existing notifications as non-persistent
 notifications. Only notifications associated with a service worker are
 persistent.

This is a little bit implicit for my taste. But I don't feel very strongly.

 That would also allow us to remove the complexity of
 exposing a single non-persistent notification as multiple Notification
 objects.

Yeah, no matter what syntax we use for creating
persistent/non-persistent notifications, I agree that .get() should
only return persistent notifications.

 * Right now the spec requires that whenever a user interacts with a
 persistent notification, the application that created the notification
 is immediately started so that we can send the appropriate
 click/close/future-button-press event to it's service worker. This can
 be quite expensive. At the very least applications need to be able to
 indicate that they don't need to be told about the close event.
 * Even better would likely be content could indicate which events they
 want fired at the service worker when creating a Notification. Other
 events would be dropped. This list vary by-notification, not by-app.
 * Alternatively, maybe we could simply get rid of the close event
 entirely. Does it have a use-case?

 Is this only about the close event? We could opt not to support for
 persistent notifications as a start if we follow my strawman above.
 I'm not a 100% sure why it's there either at this point. I suspect not
 supporting it would not necessarily break anything. Probably mostly
 there for symmetry with the close() method.

Actually, it might also be the show event.

But see also my sub-thread with Tab. It *might* be useful to not
receive a click event for persistent notifications. I don't know of
any use cases, but my gut feeling is that they are there.

But maybe they are rare enough that by default we only fire click
events. For persistent notifications we fire them at the SW, for
non-persistent at the Notification object.

If we in the future find actual use cases for close/show we can
add ways to opt in to receiving those. And if we find use cases for
*not* receiving click (in particular to SW) we can add ways to opt
out of those.

/ Jonas

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

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 not seem useful
on mobile, but could be useful on desktop to enable minimized
applications, or applications whose window is covered by other
windows, call attention to themselves.
* Persistent vs. non-persistent doesn't seem like a platform
difference, but rather two different types of notifications that
content could want to create.
* For persistent notifications, in cases where the application cares
about the user clicking on the notification (as opposed to
fire-and-forget notifications), we should always send a notification
to the service worker. In this scenario it never seems useful to fire
an event on the Notification instance since that will just mean
multiple codepaths trying to handle the same click. At best that would
be wasted performance, at worst it could mean broken UI or application
logic.
* Same applies to close in addition to click.
* For non-persistent notifications, it seems good to not require that
a service worker is used.
* I'm uncertain about if non-persistent notifications are important
enough to target at this point. But I'm heavily biased from having
worked mainly on mobile web lately.
* Right now the spec requires that whenever a user interacts with a
persistent notification, the application that created the notification
is immediately started so that we can send the appropriate
click/close/future-button-press event to it's service worker. This can
be quite expensive. At the very least applications need to be able to
indicate that they don't need to be told about the close event.
* Even better would likely be content could indicate which events they
want fired at the service worker when creating a Notification. Other
events would be dropped. This list vary by-notification, not by-app.
* Alternatively, maybe we could simply get rid of the close event
entirely. Does it have a use-case?

/ Jonas





On Tue, Sep 23, 2014 at 6:31 AM, Anne van Kesteren ann...@annevk.nl wrote:
 Peter and Jake made a proposal for notifications and service workers,
 but I believe Jonas wanted something without events. I'll outline the
 proposal from Peter and Jake below. Hopefully we can then discuss on
 how to move this forward.

 We add serviceWorker to Notification and NotificationOptions. When a
 Notification is constructed within a service worker it is set
 automatically, in other environments it needs to be set to a
 ServiceWorkerRegistration object (allowing it to be overridden inside
 a service worker is probably okay). (If there's an issue with the
 ServiceWorkerRegistration object we throw.)

 If this succeeds, the underlying notification is associated with a
 service worker.

 If a notification is associated with a service worker, events are
 dispatched to the service worker, rather than to Notification objects
 associated with the notification. These events also expose a new
 Notification object (cloning is cheap).


 Suggestions I remember:
 * Expose promises on Notification objects to see whether a
 notification has been clicked or closed. (And keep track of such state
 somewhere.)
 * Dispatch events to Notification objects as well even if the
 notification has an associated service worker. Requiring message
 channel roundtrips for this is cumbersome.


 This is also tracked on GitHub:
 https://github.com/whatwg/notifications/issues/19


 --
 https://annevankesteren.nl/

Re: [whatwg] Notifications and service workers

[Jonas Sicking]

On Tue, Sep 23, 2014 at 5:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Tue, Sep 23, 2014 at 5:21 PM, Jonas Sicking jo...@sicking.cc wrote:
 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 not seem useful
 on mobile, but could be useful on desktop to enable minimized
 applications, or applications whose window is covered by other
 windows, call attention to themselves.

 Can you provide an example use-case for a persistent notification that
 goes away when the page does?

I'm saying that there are two types of notifications:
* Persistent notifications that stick around even after the user
closes the app/webpage.
* Non-persistent (aka transient) notifications which are not.

I'm currently not attaching any particular UX to either. I.e. I'm
leaving out *where* these notifications are displayed.

 I can think of transient notifications,
 and persistent ones that stick around until dismissal, but I can't
 come up with this in-between case with a few minutes thought.

I agree.

 * Persistent vs. non-persistent doesn't seem like a platform
 difference, but rather two different types of notifications that
 content could want to create.

 Yes.  Pandora temporarily spawning a notification showing the song
 title/artist that's playing whenever a new song starts seems useful as
 a non-persistent notification on any platform.  I definitely wouldn't
 want that sort of thing to stack up on a mobile device.

Interesting. It's not something I've actually seen myself, but I don't
tend to listen to music on my mobile.

But it does fit with the general idea that non-persistent
notifications solve the use case of allowing background applications
to call attention to themselves.

 * For persistent notifications, in cases where the application cares
 about the user clicking on the notification (as opposed to
 fire-and-forget notifications), we should always send a notification
 to the service worker. In this scenario it never seems useful to fire
 an event on the Notification instance since that will just mean
 multiple codepaths trying to handle the same click. At best that would
 be wasted performance, at worst it could mean broken UI or application
 logic.
 * Same applies to close in addition to click.
 * For non-persistent notifications, it seems good to not require that
 a service worker is used.

 I'm not sure persistent vs non-persistent is quite the line to draw
 this on. Fire-and-forget vs responsive seems more correct.  Most
 (all?) persistent notifications are responsive, yes, but transient
 notifications might or might not be.  I think it's appropriate and
 useful for a fire-and-forget notification to be fireable from a normal
 page, without a service worker.

I think we are mainly using different vocabulary. I think my non
persistent notification is your transient notification.

I guess one question is if it's ever useful to have a persistent
notification which is fire and forget. I.e. where the application
does not want to run code or display UX when the user clicks the
notification.

My gut instinct is that there's likely some such use cases.

/ Jonas

[whatwg] Adding a property to navigator for getting device model

[Jonas Sicking]

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 problem this is).
* Lots of websites key various things off of UA string, even when they
don't care about device models. These will not recognize the UA if
it's even slightly off from what they know which can cause them to
fall back to a generic HTML4 (or even WAP) version of the website.
* Parsing just the device model identifier from the UA string is error prone.
* Encourages websites to do feature detection through UA detection,
rather than through, well, feature detection.

In some cases websites uses the UA strings for bad reasons (this is
how we've always done it), in other cases because it's literally the
best way for them to create a good user experience for their users.

I've tried for a while to try to figure out features that we can add
to the web platform to try to slowly move away the industry from this
practice. But it's a very slow process. And actually getting websites
to stop using the UA string in this manner is going to be even slower
as it's very entrenched in the mobile industry.

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 in the UA string. That would at least help with the parsing
problem.

And if means that we could more quickly move the device model out of
the UA string, then it also helps with the UA-string keying thing.

Obviously I'm not suggesting that UAs be required to set this
property. At least Mozilla would not set this property in
distributions where we are not currently sending a device model in the
UA string.

I'm just suggesting that on platforms where various browsers are
*already* exposing a device model through the UA string. That we
expose the same information in a more easy-to-consume property in the
DOM.

My suggested name would be navigator.deviceModel

Thoughts?

/ Jonas

Re: [whatwg] Canonical Image and Color

[Jonas Sicking]

On Tue, Sep 9, 2014 at 5:13 PM, Marcos Caceres mar...@marcosc.com 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 applications
updating their icons as part of an update. So in our manifest
implementation, we check for updates of the manifest on a daily basis
and if the manifest has been updated to point to a new icon, we use
that new icon.

Applications do on a fairly regular basis release visual updates,
and as part of that it's critical that they also update the
application icon.

We do however not allow applications to change their names. For the
reason that you mention.

I agree there's still a risk that just changing the icon means that
the user won't notice that the name doesn't match, however I don't
think disallowing icons to be updated is an option. Even forbidding
names to be changed has been a major headache and something we're
looking to enable somehow.

/ Jonas

Re: [whatwg] Canonical Image and Color

[Jonas Sicking]

On Tue, Sep 9, 2014 at 6:21 PM, Marcos Caceres mar...@marcosc.com 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?
 
  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 applications
 updating their icons as part of an update. So in our manifest
 implementation, we check for updates of the manifest on a daily basis
 and if the manifest has been updated to point to a new icon, we use
 that new icon.

 I don't know if it makes any difference, but the process of updating 
 installed apps unusually involves notifying the user that updates are 
 available and the user taking explicit action to update the apps. Where 
 updates happen automatically, there is usually some kind of notification 
 and/or indicator that makes the user aware of what has changed.

That will long term not be the case in FirefoxOS. I can't speak for
other platforms, but I'll note that Chrome has always updated with no
notification to the user, Firefox has over time gotten fewer and fewer
notifications, and platforms like Android, iOS and Windows have been
moving towards more and more automatic updates with fewer and fewer
notifications.

So my assumption is that we'll end up with updates being completely
transparent on many platforms. At least as default behavior.

 What I'm concerned about is the application updating the icon while the 
 application is running. Although it works fine for calendar, that seems 
 confusing to me.

What is your concern?

 Applications do on a fairly regular basis release visual updates,
 and as part of that it's critical that they also update the
 application icon.

 Yes, that makes total sense. My concern is more about a sneaky attack where 
 the app icon changes as the user switches from one app to another and then 
 back.

Why is the changing back part more concerning than the initial
change? Or am I misunderstanding you?

 We do however not allow applications to change their names. For the
 reason that you mention.

 Oddly, I don't see a problem with updating the name of an application in an 
 update. I don't have proof, but I would imagine most people look of icons and 
 take little notice of the name of apps on the home screen. Names are only 
 really relevant for searching.

I agree. However I've found forbidding updating icons a no-go. Not to
mention that since we support different icon files for different
render sizes and pixel densities, it's probably possible for an
attacker to hide a bank icon somewhere even without updates.

The reason we've locked down name and not icon was because that's all
that we could do. Not because it was safer from a security
perspective.

 I agree there's still a risk that just changing the icon means that
 the user won't notice that the name doesn't match, however I don't
 think disallowing icons to be updated is an option.

 Remember, we are talking about changing it in real time VS changing it from 
 an update while the application is (maybe?) shut down.

I'm more concerned about an app changing icon when it's *not* running
than when it is running. My concern is that the user launches an app
that they think is another app, either from the homescreen or from an
activity picker.

/ Jonas

Re: [whatwg] Notifications: the ability to specify notifications behavior

[Jonas Sicking]

On Fri, Aug 29, 2014 at 9:18 AM, Robert Bindar robertbin...@gmail.com 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 default lights and vibration to false.
And I still have concerns that exposing vibration as a boolean could
mean that a notification goes completely silent, even though neither
the user or the application intended for that.

Also, how is disrupting intended to work? As I understand it, the
current spec already defines that if you create a notification using a
tag of an already-existing notification, that it just updates that
notification without otherwise notifying the user.

So how are you envisioning that disrupting would alter that behavior?

/ Jonas

Re: [whatwg] Notification's click event should be cancelable

[Jonas Sicking]

On Tue, Aug 26, 2014 at 12:15 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Mon, Aug 25, 2014 at 6:42 PM, Jonas Sicking jo...@sicking.cc 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 the website.

 Fair, but maybe those copy objects should not get events.

I don't see a problem with firing events on all Notification
instances, and only changing focus if none of the events were
cancelled.

After all, we do something very similar when firing events on a Node.
Then too multiple EventTargets have their event handlers called, and
only if none of the event handlers, on any of the EventTargets, cancel
the event do we take the default action.

Granted, in those cases we use the same Event instance, and it's part
of a single event dispatch. But that difference is pretty small from
the webpage point of view. The main difference is that
.defaultPrevented reflect cancellation, but worst come to worst we
could make that work here too.

 We could
 make a division between notification records and notification objects.
 And we could even go as far as only offer notification records for
 notifications associated with a service worker.

I don't really understand this.

/ Jonas

Re: [whatwg] Notification's click event should be cancelable

[Jonas Sicking]

On Tue, Aug 26, 2014 at 2:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, Aug 26, 2014 at 11:06 AM, Jonas Sicking jo...@sicking.cc 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.

 It's a somewhat complex design compared to what we probably need long
 term, if long term is service workers.

I'm not convinced that even with SW, the proper design is to tell
websites to always funnel click notifications through a SW.

Alternatively we don't use events here at all. Instead we could use a
.clicked property which returns a promise. This is a typical one
shot notification where Promises are better suited than DOM Events.

However I don't actually think that firing events on multiple
EventTargets is that complex.

/ Jonas

Re: [whatwg] Canonical Image and Color

[Jonas Sicking]

On Tue, Aug 26, 2014 at 10:36 AM, Domenic Denicola
dome...@domenicdenicola.com 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 from notifications. For example a
badge could show how many unread emails are in the inbox of a webmail
client, but you woudn't want to create a notification for every one of
them.

/ Jonas

/ Jonas

Re: [whatwg] Notification's click event should be cancelable

[Jonas Sicking]

On Mon, Aug 25, 2014 at 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Sun, Aug 24, 2014 at 11:18 AM, Olli Pettay o...@pettay.fi 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 somehow, if possible)
 ...cancelling any of the events should cancel the default action.

 We could also make it so that each notification has exactly one
 Notification object. And only service workers get a Notification.get()
 API and multiple objects per notification, with the tradeoff that
 those objects are not event targets as the events go to the service
 worker directly. That might simplify things a bit.

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 the website.

/ Jonas

Re: [whatwg] Web Bluetooth API

[Jonas Sicking]

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 jyass...@chromium.org wrote:

 We have a draft API for Bluetooth device access at
 https://webbluetoothcg.github.io/web-bluetooth/, for which I'm planning to
 send a Blink Intent to Implement email soon. The spec isn't really up to
 web standard quality yet: we're planning to refine it as we get feedback
 from implementation and experimental use. However, we'd still appreciate
 any feedback this group has on the current draft.

 Feedback as issues at
 https://github.com/WebBluetoothCG/web-bluetooth/issues
 will be easiest to incorporate. Feedback as replies to this email is still
 welcome. Participation at
 http://lists.w3.org/Archives/Public/public-web-bluetooth/ is even more
 welcome. :)

 Thanks,
 Jeffrey Yasskin

 P.S. I'll ping Monday so this doesn't get lost over the weekend, but want
 to give anyone a chance to comment early if you want.

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Tue, Aug 19, 2014 at 1:29 PM, Marcos Caceres w...@marcosc.com wrote:
 interface WakeLock : EventTarget {
Promisevoid request();
Promisevoid 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 implementation strategy will need to keep some specific
state, and that state affects the behavior of the API, then eventually
someone will come up with a use case for exposing it. And that
exposing it is really easy anyway.

However I think what we'd need is something like

  readonly attribute boolean held;
  attribute EventHandler onheldchange;

FWIW, the web platform sorely needs a construct for readonly state
variable + event whenever the state changes. I.e. some form of
observable which remembers the last produced value. I had hoped the
Streams would get us closer to that, but the current definition seems
to be too different.

/ Jonas

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Wed, Aug 20, 2014 at 1:33 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc wrote:
 FWIW, the web platform sorely needs a construct for readonly state
 variable + event whenever the state changes. I.e. some form of
 observable which remembers the last produced value. I had hoped the
 Streams would get us closer to that, but the current definition seems
 to be too different.

 Isn't that Object.observe() with custom records produced by the
 specific object you are defining for the property you want to enable
 this for (in this case held, it seems like)?

That's a good question. It'd be awesome if Object.observe() solved
this problem for us.

One thing that I'd worry about is that it'll be hard for authors to
know which properties are observable, and which ones aren't. But maybe
that's something we can live with.

/ Jonas

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr 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()ed, then the lock is held indefinitely (until the
 user leaves the page of course).

 I.e. an unbalanced request() and release() in both the currently
 proposed API, and in the API that I propose behave the same, the lock
 is held indefinitely. Any objects getting GCed does not change this.

 I overlooked that aspect, my apologies. It sounds good. I am not sure if
 that would be safer than global methods in the sense that developers
 will still be able to shoot themselves in the foot by not calling
 .release() or might assume that .release() will be called upon object
 destruction.

Indeed. I can't think of a way to fix that without also breaking some
use cases. I.e. we could forcefully release all locks after a timeout,
but that'll definitely break some use cases such as long videos, or
heavy background processing.

 How would you handle feature detection with this design?

This is a good question. I don't have a better solution than adding
separate DisplayWakeLock() and SystemWakeLock() classes.

/ Jonas

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Mon, Aug 18, 2014 at 2:04 AM, Mounir Lamouri mou...@lamouri.fr 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.

 The problem arises when you have several semi-independent pieces of
 code within a single page. Given that request() and release() is
 likely going to happen in response to very different UI events or IO
 events, it makes it fairly easy to accidentally have unbalanced calls.

 Consider for example a lock which is released either when a video
 reaches its end, when the user presses the pause button, or when the
 user close the dialog in which the video is rendered. It seems quite
 easy to end up with a race where if the user close the dialog right
 when the video ends, that release() would get called twice. Or if the
 user pause the video first and then close the dialog that release()
 would get called twice.

 If there's only one subsystem of the page that uses a display lock,
 then this is not a big deal. The extra call to release() would cause
 an rejection, but hopefully that won't break the page.

 It is possible that the API might behave differently and the first
 release() will release the lock even if lock() was called multiple
 times. I guess the scope of the lock could be the browsing context so a
 website will not end up conflicting with iframes. However, if a websites
 embeds libraries that use this API, it will need to coordinate.

I'd rather have request() and release() work as they are defined now.
Otherwise coordinating becomes even harder as the specification does
not provide a coordination mechanism.

 However if there are multiple subsystems that all use a display lock,
 it would mean that those subsystems might stomp on each other's
 attempts at holding a display lock. The effect would be that the
 display lock is released too early.

 I don't care strongly about this though. It's pretty easy for pages to
 write a wrapper around the currently proposed API to implement the API
 that I'm proposing.

 I understand the problem and I agree that an object-based approach would
 be nicer in theory because the scope of the lock would be well defined.
 However, it's a very uncommon pattern as far as Web APIs are concerned
 and I would worry that developers would end up  doing things wrong and
 depend on the GC behaviour without even being aware of it.

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()ed, then the lock is held indefinitely (until the
user leaves the page of course).

I.e. an unbalanced request() and release() in both the currently
proposed API, and in the API that I propose behave the same, the lock
is held indefinitely. Any objects getting GCed does not change this.

Again, I don't feel terribly strongly about this as it's easy to shim
in either direction.

/ Jonas

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Mon, Aug 18, 2014 at 4:37 PM, Marcos Caceres w...@marcosc.com 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 happens async once the system acknowledges that the 
 release has been granted. I'm not sure if there is a use case for that 
 behavior - it's just what is currently/sorta roughly proposed in the spec.

I don't think the sync part was the important aspect here. You could
easily rewrite that as an async loop.

The point is that it's easy for developers to end up trying to work
around bugs in their own code by simply doing extra releases. Or end
up with bugs where they accidentally release too many times and so
stomp on other components.

 Therefore, if WakeLock needs to be purely JS API, I strongly prefer having 
 WakeLock available only as an object instance, but without exposing GC 
 behavior--if it's lost, it's like a missing release call.

 If devtools ever get monitoring of unhanded errors in Promise objects, they 
 could also warn against lost WakeLock objects--it's the same type of problem 
 dependent on GC.

 I'm assuming that release would work only once on each lock object:

 var lock = new WakeLock(screen);
 lock.release();
 lock.release(); // ignored, so it doesn't unlock any other component's lock

 This makes coordination easier: each page component can easily create their 
 own lock independently (without needing to create an iframe to get their own 
 lock), and can't release any other component's lock.

 Personally, I don't know if I agree that it makes coordination easier. Seems 
 that having a centralized place to check what is currently being held makes 
 life a lot easier, because it allows scripts to check if they actually need 
 to request a lock or not.

Why does the ability to check if a lock is held make coordination
easier? Checking if they need to request a lock or if someone else is
already doing it seems like a very bad code pattern which actually
makes coordination harder. It makes it very easy to get confused and
try to rely on party X to hold a lock, but then it turns out that in
reality it was Y holding the lock, but Y releases the lock much sooner
and now end up holding a lock for a shorter time than intended.

Am I missing something?

 If you have some objects requesting and others releasing, then it makes a 
 huge mess because you need to track down which object screwed up the lock.

This is not what the proposal is. The proposal is that if a WakeLock
instance x is used to grab a lock, then the lock will be held until
x.release() is called. Any calls on other WakeLock instances will not
cause the lock to be released. Only one all WakeLock instances that
have had request() called on them also gets a call to release(), does
the lock get released.

Losing track of the instance that you called request() on, then that
is equivalent to losing track of how many time you have called
wakeLock.request(x). There is no way to get correctly out of that
situation.

 And if GC also then works to release the locks, then there is no certainty as 
 to what is actually releasing the lock or when.

Can we please stop talking about GC. I don't think anyone has made a
serious proposal where GC releases a lock, or where GC is otherwise
exposed.

/ Jonas

Re: [whatwg] Feature-detectable WakeLocks

[Jonas Sicking]

On Mon, Aug 18, 2014 at 5:37 PM, Marcos Caceres w...@marcosc.com 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 TypeError or by a DOMException whose name is NotSupportedError.

We've made this mistake before. See

http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html

/ Jonas

Re: [whatwg] Preventing wake lock leaks with DOM nodes

[Jonas Sicking]

On Mon, Aug 18, 2014 at 5:35 PM, Marcos Caceres w...@marcosc.com 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 the problem with adding more attributes in the future?

That said, I do think that a timeout for screen locks make sense, so
a boolean wouldn't work. Though not as a timeout for when to release
the lock, but rather as a minimum time I'd like to keep the screen
awake as described at

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297423.html

/ Jonas

Re: [whatwg] meta referrer as always-origin

[Jonas Sicking]

On Fri, Aug 15, 2014 at 11:12 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Sat, Aug 16, 2014 at 8:09 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Fri, Aug 15, 2014 at 11:28 PM, Jonas Sicking jo...@sicking.cc wrote:
 Could we introduce a always-origin value for meta referrer which
 combines the origin and always policies?

 That is called Origin Only:
 http://w3c.github.io/webappsec/specs/referrer-policy/#referrer-policy-states
 It does not seem exposed as a value for meta name=referrer at this
 point.

 Actually, it seems that is the origin value, my bad. Why did you
 think that was behaving differently?

Because the description for always contains the text Note: This
might cause https referrers to be sent over the network as part of
unencrypted HTTP requests., but the description for origin does
not.

/ Jonas

Re: [whatwg] Notifications: the ability to specify notifications behavior

[Jonas Sicking]

On Aug 15, 2014 1:57 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, Aug 15, 2014 at 1:37 AM, Robert Bindar robertbin...@gmail.com
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.

 Well, if we introduce new dictionary members they will default to
 false. So I guess what Jonas was asking for is that we should think of
 names that make sense given that. Of course, they will just be hints
 anyway due to platform conventions and user overrides.

That's not necessarily true. Dictionary members default to absent if they
don't have a default value. So we could treat default as different from
both true and false.

But it tends to make for a confusing API to treat optional boolean
arguments as different from false.

/ Jonas

[whatwg] meta referrer as always-origin

[Jonas Sicking]

Hi All,

Right now the meta referrer 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 you currently can't combine the two. I.e. if you want to
override UA policies, you are forced to send the whole URL string.
This seems counter intuitive since that's when you might really want
to just send the origin.

Could we introduce a always-origin value for meta referrer which
combines the origin and always policies?

/ Jonas

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr 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 have to make sure that they don't stomp on each
 other's locks. Simply counting request() calls vs. release() calls
 helps, but doesn't fully solve the problem. It's very easy to
 accidentally call release too many times, in response to some UI
 action for example.

 An alternative design would be something like

 x = new WakeLock(display);
 x.request();
 x.release();

 Extra calls of either request() or release() are ignored, but pages
 can create any number of WakeLocks of the same type.

 It seems that we already discussed using an object and this solution was
 dismissed because of this model being error-prone.

Where was this discussed? Why was it considered more error prone? Was
it related to the patterns discussed at

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html

 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.

The problem arises when you have several semi-independent pieces of
code within a single page. Given that request() and release() is
likely going to happen in response to very different UI events or IO
events, it makes it fairly easy to accidentally have unbalanced calls.

Consider for example a lock which is released either when a video
reaches its end, when the user presses the pause button, or when the
user close the dialog in which the video is rendered. It seems quite
easy to end up with a race where if the user close the dialog right
when the video ends, that release() would get called twice. Or if the
user pause the video first and then close the dialog that release()
would get called twice.

If there's only one subsystem of the page that uses a display lock,
then this is not a big deal. The extra call to release() would cause
an rejection, but hopefully that won't break the page.

However if there are multiple subsystems that all use a display lock,
it would mean that those subsystems might stomp on each other's
attempts at holding a display lock. The effect would be that the
display lock is released too early.

I don't care strongly about this though. It's pretty easy for pages to
write a wrapper around the currently proposed API to implement the API
that I'm proposing.

/ Jonas

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Wed, Aug 13, 2014 at 9:46 PM, Biju bijumaill...@gmail.com wrote:

 On 13 August 2014 21:00, Jonas Sicking jo...@sicking.cc wrote:

 An alternative design would be something like

 x = new WakeLock(display);
 x.request();
 x.release();

 Extra calls of either request() or release() are ignored, but pages
 can create any number of WakeLocks of the same type.

 If application made a x.request() then x got garbage collected
 system should automatically do x.release();

No. We don't want authors to come to rely on GC to have their locks
released. That would cause very erratic behavior where sometimes the
lock would be held for 2 seconds after the last reference to 'x' was
removed, and sometimes the lock would be held for 30 minutes past that
point.

In other words, it would make GC observable. Not always observable by
the page, but by the user which can be just as bad.

/ Jonas

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Thu, Aug 14, 2014 at 4:44 AM, Biju bijumaill...@gmail.com 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_something_1();

 x = new WakeLock(display);
 x.request();

 do_something_2();

throw some runtime error occurred;

 do_something_3();

 x.release();

 do_something_4();
 }

Same thing as


function xyz(){

do_something_1();

navigator.wakeLock.request(display)

do_something_2();

   throw some runtime error occurred;

do_something_3();

navigator.wakeLock.release(display)

do_something_4();
}

I.e. the lock is held forever.

/ Jonas

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Thu, Aug 14, 2014 at 6:33 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net 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 are largely invisible (and unactionable) to the
user. This is of course independent of what API syntax we use.

One solution that I think we'd use in FirefoxOS is to bring up a
dialog when the system lock is used. Unless the user has installed
the page by using bookmark to homepage or something similar. And for
things that have been bookmarked to homepage we'd track their battry
usage and inform the user how much battery each bookmarked website
uses.

/ Jonas

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Thu, Aug 14, 2014 at 9:55 AM, Jesper Kristensen
m...@jesperkristensen.dk wrote:
 Hi

 Would it make sense to tie the system lock to a notification?

 For example:

 new Notification(Processing..., {tag: abc, progressBar: 0.8, wakeLock:
 system});

 There are many myths and rumors about how to conserve battery on mobile
 devices. A small improvement could be to require apps to show some kind of
 UI whenever they are allowed to consume resources in the background.

The main use case for system locks in my mind is for applications that
need to do some short but important processing. For example a camera
app wanting to do some HDR processing of an image before saving it to
disk. It seems like it would be very annoying if a notification was
shown any time the user took a picture.

I still think it's a very interesting 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 w...@marcosc.com 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 different interaction queues
 (touch
 events, mouse events, focus events, orientation-change events, etc.) in
 order to release the lock at the right time.



 Do you have specific UC? The basic UC I have in mind (reading a book,
 watching a video, playing a game) would not use a timeout.



 Yes, Google Play Books will wait five minutes from the last interaction
 to turn off the screen. This is nice if you fall a sleep while reading and
 long enough for a user to read a page without having the screen dim.

 See:
 http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books

 I was trying to model that problem with the API.

 Question remains if there are other kinds of locks that we might need.
 For example, Firefox OS has wifi as a lock type. I'm assuming that
 their model keeps the cpu on, but the device can still shut down the
 radios on a device. In the proposal, we lump wifi and cpu into
 system.


 Why not breaking these in different sub-systems? I can definitely
 imagine my phone having the CPU kept at 100% while the screen is off if
 it requires to do a heavy computation. Forcing the screen to stay on
 while doing that would be a waste of battery.


 Sorry, I was trying to say exactly what you said above. No need to keep
 the screen on when using system, obviously.

 Ideally, we could do something like:

 display = keep display on + system/cpu + network
 network (wifi/cell) = system/cpu + network (screen off)
 system = just cpu, turn off screen and radio.

 Hopefully, something like that means you don't need to pick an choose
 amongst numerous options.


 I think the locks are fairly orthogonal.

 Holding the display lock just prevents the normal turn off device
 because user hasn't interacted with it for X minutes timer from
 firing. I.e. while the display lock is held, the screen won't
 automatically time out and put the device to sleep.

 However if the user presses the power button the screen would still
 turn off and the device would still go to sleep.

 Holding the system lock however wouldn't prevent the screen from
 turning off. But it would prevent the CPU from going to sleep even if
 the screen times out or if the user presses the power button.

 Holding both display and system means that the screen won't time
 out. If the user presses the power button the screen would turn off
 but the CPU would still not be put to sleep.

 So I think it makes sense to expose an array of which locks the page
 holds since all combinations of the system and display locks yield
 different behavior.

 I am however more worried about that only having a request() and a
 release() function means that pages that contain multiple independent
 subsystems will have to make sure that they don't stomp on each
 other's locks. Simply counting request() calls vs. release() calls
 helps, but doesn't fully solve the problem. It's very easy to
 accidentally call release too many times, in response to some UI
 action for example.

 An alternative design would be something like

 x = new WakeLock(display);
 x.request();
 x.release();

 Extra calls of either request() or release() are ignored, but pages
 can create any number of WakeLocks of the same type.


 Regarding timeouts, the use case that I've come across many times is
 pages that contain a lot of text, or some form of puzzle. In those
 cases you don't want to completely disable the screen timeout. But you
 might want to set it to some larger large value, say 15 minutes.

 It's somewhat hard to work around the lack of a timeout. What you
 could do is to release the lock after 15 minutes, but then that means
 that the normal screen timer kicks in, which adds an unknown number of
 minutes of the screen being on.

 If you instead were able to create a display lock

Re: [whatwg] Notifications: the ability to specify notifications behavior

[Jonas Sicking]

On Wed, Aug 13, 2014 at 2:12 PM, Robert Bindar robertbin...@gmail.com 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 notification pertaining to a new message. Or in the mobile web, an app
 may want to avoid waking the screen on every notification to save battery
 life. Web content could have a way to suggest these behaviors to the user
 agent.

Agreed. We've run into similar shortcomings when writing mobile webapps.


 new Notification('title', {
 tag: 'tag',
 behavior: {
 vibration: true,
 silent: true,
 lights: false,
 list: true,
 noclear: true,
 squash: true,
 }
 });

It might be good to structure these such that the default is always
'false'. That way it's more intuitive what behavior you get if you
leave out a property.

 * vibration - vibrate the device
 * silent - true means do not play a sound when firing the
 notification(the sound
 is enabled by default in firefox for OSX, not available
 in Linux and Windows)

The tricky thing with these is how to deal with situations when the
user has turned of audio or turned off vibration for notifications.

If the user has turned off audio for notifications, and the page
specifies vibration: false, does that mean that this notification is
entirely silent? I suspect that's not what the user expected when
turning off audio.

 * lights - turn the screen on

Agreed on this one.

 * list - add a new entry to the notification list

I don't understand this one.

 * noclear - this notification shouldn't be closed when pressing the
 ClearAll button

This one is interesting. I could see the value for notifications that
deliver progress notifications about an ongoing event to the user.
Though I hate the idea of users not being in control of their
notifications area. Perhaps it's ok that the notification doesn't get
cleared if a 'clear all' button is pressed, but that the user can
somehow explicitly clear that certain notification.

 * squash - every time you'll find a notification with the same tag, do
 not disrupt the
  user, just update the existing notification

This is the main purpose of using tags. When would you not want this behavior?

 Again, the `behaviors` object is just a package of suggestions for how a
 notification should behave,
 but it is up to the user-agent to determine whether it wants to honor these
 behaviors
 (based on platform support, user settings, or even general user experience).

I don't think it makes much difference to say this is just a
suggestion. UAs won't magically know what's right and what's wrong.
If we can't on this list think of good heuristics to use, then I don't
think we should expect UAs to do either.

/ Jonas

Re: [whatwg] Proposal: Wake Lock API

[Jonas Sicking]

On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres w...@marcosc.com 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 different interaction queues (touch
  events, mouse events, focus events, orientation-change events, etc.) in
  order to release the lock at the right time.


 Do you have specific UC? The basic UC I have in mind (reading a book,
 watching a video, playing a game) would not use a timeout.


 Yes, Google Play Books will wait five minutes from the last interaction to 
 turn off the screen. This is nice if you fall a sleep while reading and long 
 enough for a user to read a page without having the screen dim.

 See:
 http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books

 I was trying to model that problem with the API.

  Question remains if there are other kinds of locks that we might need.
  For example, Firefox OS has wifi as a lock type. I'm assuming that
  their model keeps the cpu on, but the device can still shut down the
  radios on a device. In the proposal, we lump wifi and cpu into
  system.

 Why not breaking these in different sub-systems? I can definitely
 imagine my phone having the CPU kept at 100% while the screen is off if
 it requires to do a heavy computation. Forcing the screen to stay on
 while doing that would be a waste of battery.

 Sorry, I was trying to say exactly what you said above. No need to keep the 
 screen on when using system, obviously.

 Ideally, we could do something like:

 display = keep display on + system/cpu + network
 network (wifi/cell) = system/cpu + network (screen off)
 system = just cpu, turn off screen and radio.

 Hopefully, something like that means you don't need to pick an choose amongst 
 numerous options.

I think the locks are fairly orthogonal.

Holding the display lock just prevents the normal turn off device
because user hasn't interacted with it for X minutes timer from
firing. I.e. while the display lock is held, the screen won't
automatically time out and put the device to sleep.

However if the user presses the power button the screen would still
turn off and the device would still go to sleep.

Holding the system lock however wouldn't prevent the screen from
turning off. But it would prevent the CPU from going to sleep even if
the screen times out or if the user presses the power button.

Holding both display and system means that the screen won't time
out. If the user presses the power button the screen would turn off
but the CPU would still not be put to sleep.

So I think it makes sense to expose an array of which locks the page
holds since all combinations of the system and display locks yield
different behavior.

I am however more worried about that only having a request() and a
release() function means that pages that contain multiple independent
subsystems will have to make sure that they don't stomp on each
other's locks. Simply counting request() calls vs. release() calls
helps, but doesn't fully solve the problem. It's very easy to
accidentally call release too many times, in response to some UI
action for example.

An alternative design would be something like

x = new WakeLock(display);
x.request();
x.release();

Extra calls of either request() or release() are ignored, but pages
can create any number of WakeLocks of the same type.


Regarding timeouts, the use case that I've come across many times is
pages that contain a lot of text, or some form of puzzle. In those
cases you don't want to completely disable the screen timeout. But you
might want to set it to some larger large value, say 15 minutes.

It's somewhat hard to work around the lack of a timeout. What you
could do is to release the lock after 15 minutes, but then that means
that the normal screen timer kicks in, which adds an unknown number of
minutes of the screen being on.

If you instead were able to create a display lock with a 15 minute
timeout, the platform could use the longest value of 15 minutes and
the platform screen timeout.

And note that you in normal use cases *do* want the normal screen
timeout to kick in when a display lock is released. I've seen the
lack of this many times and it's really annoying. What happens is that
after you're done watching a 30 minute movie, the application releases
the lock and the screen immediately shuts off. Attempting to work
around this by holding the lock for a few minutes past the movie ends
means that the application has to guess how long timeout the user has
configured his device to.

I don't however know of any use cases for having a timeout for
system locks. So I propose they are not supported there.

I haven't thought about network locks enough to know if timeouts
makes sense there (or if network locks in general are needed).

/ Jonas

Re: [whatwg] Notifications improvements

[Jonas Sicking]

On Aug 11, 2014 8:38 AM, Peter Beverloo bever...@google.com wrote:
 On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson atwil...@google.com wrote:
 You raise an interesting question. Given the following notification:

 var notification = new Notification('Title', {
 body: 'Hello, world!',
 icon: '/my-icon.png',
 items: [
 { title: 'Message 1', body: 'Contents of message 1' },
 { title: 'Message 2', body: 'Contents of message 2' },
 { title: 'Message 3', body: 'Contents of message 3' }
 ],
 buttons: [
 'Reply',
 'Reply to all',
 'Forward'
 ],
 date: new Date('2014-08-11T16:35:00'),
 progress: 40
 });

 What do we expect to be displayed?

I agree, this is a very interesting question. My thinking had been
that this should be supported. But I hadn't thought of that not all
platforms that can render a progress bar can render one at the same
time as a bullet list, or a set of buttons.

And then there's of course the question how the above would be
rendered, I.e. does the progress bar go above or below the list? Or is
that UA defined.

Suggestions for how to deal with this is definitely welcome.

I think we can expect that the date is simply displayed next to the
notification. Just like the icon is. That's how every notification
system I can find do it. Dates really are more about adjusting UI
which is already there, rather than adding new UI. So I would expect
that to mix fine with all other types of data.

Buttons, progressbar and lists are indeed a problem though. Does
anyone know what limitations we have as far as platforms go?

At a first glance, it seems like we might be able to get away with
defining that buttons are always at the bottom, and progress bars are
just above buttons but below everything else. But quite possibly
things aren't that simple.

Lists are trickier. They even seem tricky on their own. Do they go
before or after the text body? It seems like you might even want to
have a list in with text both before and after. Or should we say that
you can't have lists at the same time as a text body?

/ Jonas

Re: [whatwg] Notifications improvements

[Jonas Sicking]

On Fri, Aug 8, 2014 at 5:48 AM, Peter Beverloo bever...@google.com 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. As long as advanced features, especially more compatible
 ones (say, buttons or timestamps) can be feature detected by developers so
 that they can provide a fallback when they're not available, I would be in
 favor of extending the future set with Jonas' declarative proposals.

Cool! I had not though about the need to feature detect. At least for
progress/list/timestamp. My thinking had been to require that the UA
provide a textual fallback on platforms that can't render those
widgets natively.

However I think you are right that we'll need feature detection here.
We might even need two types of it.

First of all not all UAs are going to implement all of these features
right away. So obviously they won't provide any fallback rendering
either. Detecting this seems important.

Second, it might be good to enable pages to detect platforms where a
progress bar is rendered as a native progress bar, rather than as text
fallback. This way the page can choose not to use a progress bar and
instead create its own fallback.

An important point here is for pages that don't choose to test for the
latter, will still get a useful rendering of the notification.

/ Jonas

Re: [whatwg] Notifications improvements

[Jonas Sicking]

On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson atwil...@google.com wrote:

 On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson atwil...@google.com
 wrote:
 
  On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc wrote:
 
  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
  * Date (for things like event will happen in 10 minutes)
 
 
  So, many of these cases were what the original HTMLNotification API was
  supposed to address. This was eventually shot down for a number of
  (good)
  reasons: too much complexity on the implementation side, and more
  importantly, the fact that these more complex notifications aren't
  compatible with various platform notification frameworks and so this
  would
  be a source of platform/UA incompatibility. It's not clear to me that
  re-adding support for these use cases one at a time as distinct
  notification
  types is really a good path forward, or that it's necessarily
  low-hanging
  fruit unless we have a good idea for how to deal with the
  platform-compatibility issue.

 Actually, given that the UA has a very high degree of semantic
 understanding of these properties, I think it should be doable to
 implement on top of all existing platform notification systems. In all
 of the above cases you can come up with a reasonable string to add to
 the end to render the content. This is what pages have to do right now
 anyway.


 I had assumed from the examples you gave that the goal of these new
 notification types was to have dynamically updating notifications (progress
 bar, timestamps that update with a countdown to an event, etc), which it
 wasn't clear could be cleanly implemented across all platform notification
 systems without significant jank.

For dates the idea is definitely to enable the notifications to be
dynamically updated by the platform.

For progress bars my expectation was not that it would be
automatically updated. Instead it would be updated using the exact
same mechanism that we have for notifications today, i.e. using the
tag mechanism. So the jank would be the same whether OS
notifications supports rendering progress bars or if they are just
able to render text.

For lists the idea is not to update them any more or less than for
plain text content. Just like with text content pages will likely want
to update them occasionally, but that's not a core aspect of the
feature.


 The intent for things like progress bars
 would be that they have greater visibility than your typical 5 seconds and
 then hidden email notification, which also may not be doable with many
 notification frameworks.

This is a quite interesting idea. I hadn't thought of that.

 I'm slightly dubious about adding
 new semantic notification types (I'd still rather give app developers the
 tools to build their own richer notifications instead of giving them a
 canned set), but it's definitely worth discussing further.

I'm not sure I understand this argument. If you are concerned about
having poor fallback on platforms that can't render the UI components
discussed above, then surely that concern is even greater if we enable
pages to build their own rich notifications?

My goal has been two-fold:
* Don't limit the web to the lowest common denominator of the
platforms on which it runs.
* Don't encourage pages that simply don't work unless you use the right OS.

The pre canned capabilities enable us to on OSs that have advanced
capabilities enable web developers to take advantage of those for the
most commonly requested notification content. While still enabling
users on OSs that don't have such capabilities to still get a useful
experience.

/ Jonas

Re: [whatwg] Notifications improvements

[Jonas Sicking]

On Tue, Aug 5, 2014 at 7:09 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc 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

 Tracked here: https://github.com/whatwg/notifications/issues/17

Sweet!

 * Lists of title/body pairs

 What exactly is this for?

The place that this has come up in FirefoxOS is when notifying about
incoming emails. We would like to display the sender and the subject
for each newly arrived email.

At first this seemed like a pretty unusual edge case, but after
looking at chrome-apps notification API they had this exact feature.
So it seemed like this has come up elsewhere too.

 * Date (for things like event will happen in 10 minutes)

 Should this be part of a generic alarm API?

The goal of the Alarm API is to enable a website to do some processing
(and possibly open full UI) at a particular wallclock time. An alarm
clock application is a primary example of this.

The goal of a Date field for notifications is quite different. It's to
enable a notification that's associated with an event that happend, or
is going to happen, at a different time than when the notification API
JS call happened.

For example a calendar application might want to create a
notification. The notification should be created and displayed to the
user 10 minutes before the event is about to happen, but the timestamp
shown next to the notification should at first say in 10 minutes. As
time passes the timestamp should change to in 9 minutes ... in 5
minutes ... now ... 1 minute ago ...etc.

The only way you could do that right now is to 10 minutes before the
event happens create a notification which says CoolMeeting in 10
minutes, then after a minute replace that with CoolMeeting in 9
minutes etc. This both has the problem that the application needs to
constantly be running and replace the notification. It would also mean
that the notification would render the platform provided timestamp.
This might look something like CoolMeeting in 10 minutes. Just now.

Another use case is when creating notifications for text messages (or
other messaging systems). A text message carries the time when it was
created, which might be very different from when the message was
received by the user's device. It would here be nice to immediately
create a notification which says Message from Anne, 6 minutes ago
without that again creating the double timestamp like Message from
Anne, 6 minutes ago. 2 minutes ago.

 We also need to keep state on the Notification object if the user has
 clicked the notification or not.

 Why is that?

Relying on the application to track this perfectly has two problems.

First off it means that applications has to register a ServiceWorker
handler for all notification objects and run any logic related to
handling a click right away. Rather than simply handle it next time
the application is started, which would save on both CPU and battery.

Second, it's much more error prone to track this in application space
given potential for bugs, crashes and IO errors.

/ Jonas

Re: [whatwg] apple-touch-icon

[Jonas Sicking]

I'd really like to avoid sticking this in specs. We already have 3
ways of adding icons, /favicon.ico, link rel=icon and link
rel=manifest. 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 that both Blink and Gecko is adding support reluctantly and is
planning to remove support, adding it to the spec will make this
deprecation harder. At the very least, if it's added to the spec, add
very clear language about it being deprecated.

/ Jonas

On Sun, Jul 27, 2014 at 5:13 AM, Anne van Kesteren ann...@annevk.nl wrote:
 For link rel=icon we already define the /favicon.ico fallback. If a
 page lacks link rel=icon sizes we should probably also look at
 Apple's proprietary extension here given that it's quite widely
 adopted. Chrome supports it and there is some work going on in Firefox
 as well: https://bugzilla.mozilla.org/show_bug.cgi?id=921014


 --
 http://annevankesteren.nl/

Re: [whatwg] Fetch Objects and scripts/stylesheets

[Jonas Sicking]

On Jul 21, 2014 9:55 AM, Ben Maurer ben.mau...@gmail.com 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 examples of how I could see this working:

 (1) Allowing the user to specify parameters to Fetch. For example, a user
 could say:

 script src=/my.js params={'headers':{'myheader':'value'}}
 id=myscript /

 This would allow the user to make any type of request customization that
 they could for a direct call to Fetch.

This would indeed be cool. Though one downside is that sending custom
headers cross-origin requires the use of CORS and preflight requests. This
isn't to say that we shouldn't do it, but it will expose the author to more
complexity.

 (2) Allowing the user to access the in progress fetch object. For example,
 a user could say:

 $(myscript).fetch.then(function(resp) { console.log(resp.status); })

 Over time, the fetch object might add new functionality that would be
 useful to the application developer. For example, I could imagine the
fetch
 object gaining a way to change HTTP/2 priorities mid-request. Developers
 could take advantage of these functions for browser-initiated fetches.

As long as we can do this without requiring that the UA holds on to the
unprocessed byte stream forever. I.e. after the UA has parsed the script,
both the undecided byte stream and the decoded text stream should be
possible to throw away.

 (3) Allowing the user to construct a script or stylesheet from a fetch.
 Complex sites often want precise control over when scripts and stylesheets
 are loaded and inserted into the DOM. For example, today inserting a
 stylesheet blocks the execution of inline script tags. Some sites may know
 that this dependency is not needed. If one could construct stylesheets and
 scripts directly from a fetch, the author could separate the act of
 fetching the stylesheet from inserting into the DOM:

 var myfetch = window.fetch(...);
 myfetch.then(function(resp) {
   document.body.appendChild(resp.body.asStyleSheet());
 });

 By calling asStyleSheet, the user could preserve the devtools experience
 that exists today while still having complete control over the fetching of
 their content.

I like the general idea, but I don't really love the syntax.

/ Jonas

Re: [whatwg] Notifications improvements

[Jonas Sicking]

On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson atwil...@google.com wrote:

 On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc wrote:

 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
 * Date (for things like event will happen in 10 minutes)


 So, many of these cases were what the original HTMLNotification API was
 supposed to address. This was eventually shot down for a number of (good)
 reasons: too much complexity on the implementation side, and more
 importantly, the fact that these more complex notifications aren't
 compatible with various platform notification frameworks and so this would
 be a source of platform/UA incompatibility. It's not clear to me that
 re-adding support for these use cases one at a time as distinct notification
 types is really a good path forward, or that it's necessarily low-hanging
 fruit unless we have a good idea for how to deal with the
 platform-compatibility issue.

Actually, given that the UA has a very high degree of semantic
understanding of these properties, I think it should be doable to
implement on top of all existing platform notification systems. In all
of the above cases you can come up with a reasonable string to add to
the end to render the content. This is what pages have to do right now
anyway.

This is different from generic HTML-text conversion I think, since
HTML is very rich and there's a bigger risk of generating unuseful
text.

One thing that we *could* do is to add API for detecting which of
these properties will be rendered natively, and which ones will use
some form of UA-provided fallback. This way an advanced page could
compensate for lacking capabilities in more advanced ways, whereas
less advanced authors would get reasonably good automatic fallback.

 Second, we really need to figure out the story around handling user
 clicking notifications after the user has closed the original page.

 At the very least we need the ability to send a message to a
 ServiceWorker when the user clicks a notification. This way the SW can
 decide if UI should be shown, and if so if an existing window can be
 reused or not.

 SW integration will require some other changes too.

 We need to change the GC behavior. Right now it seems like if a
 Notification object is created, but no event listeners are attached,
 because the page is expecting to use the SW event to listen for
 clicks, the notification won't be kept alive and so the SW can't get
 to any of its data.

 We also need to keep state on the Notification object if the user has
 clicked the notification or not.

 We should also consider enabling passing a URL to the Notification
 constructor which is opened when the user clicks the notification.
 Probably this should attempt to reuse an existing tab with said URL if
 one is open.


 Third, we should look at enabling minimal user input through the
 Notification. It's very common for notifications to support having one
 or more buttons that the user can click. It would also be good to
 enable putting a simple text-input in the notification. This area is
 definitely more complex though so happy to put this last.

 I think if we want to address the more complex data type use cases above,
 then this needs to be part of that proposal - for example, I'm not sure how
 valuable having something like a Date/Event notification would be without
 a Snooze button.

I'm not sure that's true. Notifying that an event is going to happen
in 10 minutes would still be useful even if the user can't snooze
that notification.

/ Jonas

Re: [whatwg] Notifications improvements

[Jonas Sicking]

On Thu, Jul 10, 2014 at 8:01 AM, Peter Beverloo bever...@google.com wrote:

 On Thu, Jul 10, 2014 at 4:44 AM, Jonas Sicking jo...@sicking.cc 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,
 because the page is expecting to use the SW event to listen for
 clicks, the notification won't be kept alive and so the SW can't get
 to any of its data.

 We also need to keep state on the Notification object if the user has
 clicked the notification or not.

 We should also consider enabling passing a URL to the Notification
 constructor which is opened when the user clicks the notification.
 Probably this should attempt to reuse an existing tab with said URL if
 one is open.


 Notifications should just be serialized and re-created on demand, since they
 can outlive both pages and workers.

 If a page creates a notification, events for which should be delivered to a
 Service Worker, then won't be able to re-use the existing object anyway. We
 can't rely on a SW to stay alive between [creating a notification,
 interacting with the notification] either. Since the |data| property exists,
 developers can use that (or the notification's title) instead of using the
 equality operator.

 I believe we had some discussion about a launch URL earlier on. There are
 various race conditions: what if the user presses twice on the notification
 in quick succession - will we open the page twice? What is a page with that
 URL has already been opened? What if there are two? Deferring to a Service
 Workers solves these. The |notificationclick| event could be allowed to open
 windows, too.

I completely agree. The spec needs to separate the notion of a
UI-visible notification, from the Notification object instance.

/ Jonas

Re: [whatwg] Stricter data URL policy

[Jonas Sicking]

On Thu, Jul 3, 2014 at 10:00 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, Jun 3, 2014 at 12:21 AM, Jonas Sicking jo...@sicking.cc 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.
 However whenever you use the feature you (should) know that it's
 running code in your own context and with your own principal. So
 hopefully pages will make sure to not pass untrusted 3rd party code to
 neither srcdoc nor eval().

 We've seen this happen internally in Gecko where chrome code will get
 XSSed by being tricked to load data URLs. And I've been trying to move
 us towards only allowing data: to run with a chrome principal if
 chrome code explicitly opts in to that.

 I don't see why websites wouldn't face the same challenges and why the
 same solution wouldn't work there.

 What about:

   iframe src=javascript:alert(top.document.title)/iframe

 It seems that has the same issue.

Yes, it has the same issue.

But javascript: is sort of screwed no matter what. A javascript URL
inheritely will run javascript, and it always does so in the origin of
whoever set the url. So pages will have to look for javascript:
anytime they are handling URLs.

But it's better if pages only have to look for javascript: when
handling URLs. Rather than having to look for javascript:, data:,
blob: and nextbigthing:.

I'd love to simply deprecate javascript:. It doesn't seem like the use
cases are worth the complexity for both implementations and authors.
But I think it's too commonly used these days to get rid of. At least
for quite some time. About 100x the usage of sync XHR if [1] means
that I guess it means.

[1] 
http://www.chromestatus.com/metrics/feature/popularity#ReplaceDocumentViaJavaScriptURL

/ Jonas

[whatwg] Notifications improvements

[Jonas Sicking]

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
* Date (for things like event will happen in 10 minutes)


Second, we really need to figure out the story around handling user
clicking notifications after the user has closed the original page.

At the very least we need the ability to send a message to a
ServiceWorker when the user clicks a notification. This way the SW can
decide if UI should be shown, and if so if an existing window can be
reused or not.

SW integration will require some other changes too.

We need to change the GC behavior. Right now it seems like if a
Notification object is created, but no event listeners are attached,
because the page is expecting to use the SW event to listen for
clicks, the notification won't be kept alive and so the SW can't get
to any of its data.

We also need to keep state on the Notification object if the user has
clicked the notification or not.

We should also consider enabling passing a URL to the Notification
constructor which is opened when the user clicks the notification.
Probably this should attempt to reuse an existing tab with said URL if
one is open.


Third, we should look at enabling minimal user input through the
Notification. It's very common for notifications to support having one
or more buttons that the user can click. It would also be good to
enable putting a simple text-input in the notification. This area is
definitely more complex though so happy to put this last.

/ Jonas

Re: [whatwg] Fetch API: asHTML

[Jonas Sicking]

On Mon, Jun 23, 2014 at 8:46 AM, Domenic Denicola
dome...@domenicdenicola.com 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 if my networking module dragged in an entire HTML 
 implementation.

 This is a great point. From this perspective, JSON is fine since it's part of 
 the JS language. Encoding is a bit on the edge; it's a judgement call based 
 on whether your networking module wants to recognize the fact that networks 
 often transport text, or whether it should stay purely on the bytes level. 
 The convenience argument pushes me toward saying encoding is OK, especially 
 since that's a unidirectional dependency. But HTML is definitely out.

Note that you can't do JSON decoding without first doing binary-text
decoding. So by having a asJSON function we are automatically
pulling in charset conversion.

I think I was one of the original proponents of adding json as a
native type to XHR. I'm not sure that this was a good idea. Especially
not now given that we are so close to having a real Stream primitive,
and that we will surely need an API for piping a Stream into a JSON
parser.

That said, I don't care particularly strongly either way.

/ Jonas

Re: [whatwg] Fetch: use separate methods instead of one `to` method in FetchBodyStream

[Jonas Sicking]

On Mon, Jun 16, 2014 at 6:57 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:

 var doesFetchSupportJson = function () {
 return fetch(data:application/json;base64,e30=).then(function
 (response) {
 return response.body.to(json);
 }).then(function () {
 return true;
 }).catch(function () {
 return false;
 });
 };

I agree with this. We're told time and again that feature detection is
important, as is the ability to polyfill. It seems like the current
API fails both these tests.

The above code shows that it can be worked around, but only asynchronously.

What is the advantage of the current design? The number of functions
is very indicative of complexity, so I don't see a reason to avoid
having separate functions rather than string arguments here.

/ Jonas

Re: [whatwg] Stricter data URL policy

[Jonas Sicking]

On Mon, Jun 2, 2014 at 6:03 AM, Boris Zbarsky bzbar...@mit.edu 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(). Yes, it's definitely a tool that enables you to
run 3rd party code in your own context and with your own principal.
However whenever you use the feature you (should) know that it's
running code in your own context and with your own principal. So
hopefully pages will make sure to not pass untrusted 3rd party code to
neither srcdoc nor eval().

We've seen this happen internally in Gecko where chrome code will get
XSSed by being tricked to load data URLs. And I've been trying to move
us towards only allowing data: to run with a chrome principal if
chrome code explicitly opts in to that.

I don't see why websites wouldn't face the same challenges and why the
same solution wouldn't work there.

/ Jonas

Re: [whatwg] BroadcastChannel memory leak

[Jonas Sicking]

On Fri, May 23, 2014 at 5:23 PM, Adam Barth w...@adambarth.com 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 create a new BroadcastChannel
 instance at any time, the |message| event of the object might fire any
 time its responsible document is fully active.  For web application
 that have long-lived documents, the BroadcastChannel might not be
 eligible for garbage collection for a long time.

 Proposal: Add a |close| method to the BroadcastChannel interface
 similar to the |close| method on MessagePort.  The |close| method
 would just neuter the instance of the channel and prevent it from
 receiving further messages.

Sounds good to me.

/ Jonas