Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

Hi, Yosi–

On 10/6/15 9:30 PM, Yoshifumi Inoue wrote:

It's exciting!


Thanks!



For Shadow DOM, current Blink implementation traverses composed tree
rather than DOM tree. We introduced a concept position in composed
tree and ephemeral range in composed tree; "ephemeral" means range in
composed tree isn't live. Ephemeral range objects aren't update at
DOM mutation.

A continuation position, e.g. highlight find result, is specified by
composed tree position but implemented in collapsed range, since
positions in composed tree can be represented by DOM node position.


Makes sense.



From implementation, FindText.cursor is very expensive, UA needs to
serialize DOM nodes to plain text to get DOM node and offset. Note:
Blink has an implementation for this called PlainTextRange for IME
API.

I would like to proposed FindText API to be defined top on Text
Iteration API or Plain Text Serialization API, both of them aren't
specified yet, instead of Node.textContent. These API can define
HTMLElement.innerText, not standard but most of UA have it and
causes interoperability issue, and plain text format of clipboard.


Sure, I definitely want to do this in the most efficient way possible.

I'm happy to help define a Text Iteration API or Plain Text 
Serialization API; I'm no expert in that, but I can help with the 
editing work. Do you have any more information about those?




Just FYI: Here is a presentation from Yandex presented on last November
on Blink On conference:
*
https://docs.google.com/presentation/d/18UHSNEqkFW2toj7Qfo5CcuTuQsFLOibbAMq2VSWoE4I/edit?usp=sharing
*
https://docs.google.com/document/d/1HlPDpwXzzuKp0n5qkKaIL9mYkjtlQHD37OF5pHQuXtE/edit?usp=sharing


Cool, thanks for sharing that! Looks like Konstantin and Andrey from 
Yandex would be good people to get in on this discussion. I'll point 
them to this thread.


Regards–
–Doug



2015年10月7日(水) 7:55 Doug Schepers >:

Hi, Tab–

Thanks for the correction. I assumed that Houdini would expose more of
the underpinnings of the ::selection pseudo-element [1] and its ilk.
Maybe that hasn't surfaced (and maybe it won't). It does seem to be more
magic, though, which I'd thought we were trying to demystify.

But if there's no good story in Shadow DOM for things that explicitly
deal with Range, I think that needs a solution.


FWIW, JavaScript source-maps can comfortably deal with a similar
problem, with minified/cached versions of multiple source documents
(though I guess not multiple instantiations of the same source
document). Still, I'd expect there's a non-terrible solution for
serializing and expanding Shadow DOMs and pinpointing specific
instantiations.

(This makes me wonder how Shadow DOM is dealing with accessibility APIs;
I'm assuming there's a good story there, and maybe something we can draw
upon.)

[1] https://drafts.csswg.org/css-pseudo-4/#highlight-selectors

Regards–
–Doug

On 10/6/15 6:38 PM, Tab Atkins Jr. wrote:
 > On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers > wrote:
 >> Hi, Eliott–
 >>
 >> Good question.
 >>
 >> I don't have a great answer yet, but this is something that will
need to be
 >> worked out with Shadow DOM, not just for this spec, but for
Selection API
 >> and others, as well as to CSS, which has some Range-like styling.
 >
 > CSS doesn't care about this, because it doesn't expose its selections
 > to the wider DOM; it can freely style whatever it wants, including
 > ranges that span into shadows.
 >
 > This is indeed equivalent to the problem that the generic Selection
 > API has with Shadow DOM, tho.
 >
 > ~TJ
 >

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Elliott Sprehn]

How does this work with shadow dom? Range is not very friendly to that.
On Oct 6, 2015 4:35 PM, "Frederick Hirsch"  wrote:

> This is a call for consensus (CfC) to publish a First Public Working Draft
> (FPWD) of FindText API; deadline 14 October (1 week)
>
> This FindText API is joint deliverable of the WebApps WG and Web
> Annotation WG (listed as "Robust Anchoring" in the charters [1], [2]).
>
> This is a Call for Consensus (CfC) to publish a FPWD of the FindText API,
> using the following Editor's Draft as the basis:
>
>  http://w3c.github.io/findtext/
>
> "This specification describes an API for finding ranges of text in a
> document or part of a document, using a variety of selection criteria."
>
> This API was presented to the WebApps WG last TPAC under a different name,
> and with a fairly different design; it was modified to fit the feedback
> from that meeting and from others, including narrowing of scope, the
> introduction of Promises, and exposing low-level functionality in the
> spirit of the Extensible Web.
>
> The specification is largely based on the Annotator JavaScript library's
> "robust anchoring" code, and a standalone polyfill is under development.
> Feedback from possible implementers is especially welcome.
>
> This CfC satisfies the group's requirement to "record the groups' decision
> to request advancement".
>
> By publishing this FPWD, the group sends a signal to the community to
> begin reviewing the document. The FPWD reflects where the groups are on
> this spec at the time of publication; it does _not_ necessarily mean there
> is consensus on the spec's contents and the specification may be updated.
>
> If you have any comments or concerns about this CfC, please reply to this
> e-mail by 14 October at the latest. Positive response is preferred and
> encouraged, even a +1 will do  Silence will be considered as agreement with
> the proposal.
>
> regards, Frederick & Rob
>
> Frederick Hirsch, Rob Sanderson
>
> Co-Chairs, W3C Web Annotation WG
>
> www.fjhirsch.com
> @fjhirsch
>
> [1] http://www.w3.org/2014/06/webapps-charter.html#deliverables
>
> [2] http://www.w3.org/annotation/charter/#scope
>
>
>
>
>
>
>

Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Frederick Hirsch]

This is a call for consensus (CfC) to publish a First Public Working Draft 
(FPWD) of FindText API; deadline 14 October (1 week)

This FindText API is joint deliverable of the WebApps WG and Web Annotation WG 
(listed as "Robust Anchoring" in the charters [1], [2]).

This is a Call for Consensus (CfC) to publish a FPWD of the FindText API, using 
the following Editor's Draft as the basis:

 http://w3c.github.io/findtext/

"This specification describes an API for finding ranges of text in a document 
or part of a document, using a variety of selection criteria."

This API was presented to the WebApps WG last TPAC under a different name, and 
with a fairly different design; it was modified to fit the feedback from that 
meeting and from others, including narrowing of scope, the introduction of 
Promises, and exposing low-level functionality in the spirit of the Extensible 
Web.

The specification is largely based on the Annotator JavaScript library's 
"robust anchoring" code, and a standalone polyfill is under development. 
Feedback from possible implementers is especially welcome.

This CfC satisfies the group's requirement to "record the groups' decision to 
request advancement".

By publishing this FPWD, the group sends a signal to the community to begin 
reviewing the document. The FPWD reflects where the groups are on this spec at 
the time of publication; it does _not_ necessarily mean there is consensus on 
the spec's contents and the specification may be updated.

If you have any comments or concerns about this CfC, please reply to this 
e-mail by 14 October at the latest. Positive response is preferred and 
encouraged, even a +1 will do  Silence will be considered as agreement with the 
proposal.

regards, Frederick & Rob

Frederick Hirsch, Rob Sanderson

Co-Chairs, W3C Web Annotation WG

www.fjhirsch.com
@fjhirsch

[1] http://www.w3.org/2014/06/webapps-charter.html#deliverables

[2] http://www.w3.org/annotation/charter/#scope

[Bug 19771] Need way to determine what keys are supported on device.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19771

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Gary Kacmarcik  ---
Tracking as github issue: https://github.com/w3c/uievents/issues/8

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 26813] Removing parent of element that's full screen

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26813

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ann...@annevk.nl
 Resolution|--- |MOVED

--- Comment #13 from Anne  ---
https://github.com/whatwg/html/pull/230

-- 
You are receiving this mail because:
You are on the CC list for the bug.

ISSUE-187: Https://github.com/w3c/uievents/issues/20

[Web Applications Working Group Issue Tracker]

ISSUE-187: Https://github.com/w3c/uievents/issues/20

http://www.w3.org/2008/webapps/track/issues/187

Raised by: 
On product: 

RE: ISSUE-187: Https://github.com/w3c/uievents/issues/20

[Travis Leithead]

I closed this--it was opened by accident.

-Original Message-
From: Web Applications Working Group Issue Tracker 
[mailto:sysbot+trac...@w3.org] 
Sent: Tuesday, October 6, 2015 5:26 PM
To: public-webapps@w3.org
Subject: ISSUE-187: Https://github.com/w3c/uievents/issues/20

ISSUE-187: Https://github.com/w3c/uievents/issues/20

http://www.w3.org/2008/webapps/track/issues/187

Raised by: 
On product: 

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Yoshifumi Inoue]

It's exciting!

For Shadow DOM, current Blink implementation traverses composed tree rather
than DOM tree.
We introduced a concept position in composed tree and ephemeral range in
composed tree;
"ephemeral" means range in composed tree isn't live. Ephemeral range
objects aren't update at
DOM mutation.

A continuation position, e.g. highlight find result, is specified by
composed tree position but
implemented in collapsed range, since positions in composed tree can be
represented by DOM
node position.

>From implementation, FindText.cursor is very expensive, UA needs to
serialize DOM nodes to
plain text to get DOM node and offset. Note: Blink has an implementation
for this called
PlainTextRange for IME API.

I would like to proposed FindText API to be defined top on Text Iteration
API or Plain Text Serialization
API, both of them aren't specified yet, instead of Node.textContent. These
API can define
HTMLElement.innerText, not standard but most of UA have it and causes
interoperability issue,
and plain text format of clipboard.

-yosi

Just FYI: Here is a presentation from Yandex presented on last November on
Blink On conference:
*
https://docs.google.com/presentation/d/18UHSNEqkFW2toj7Qfo5CcuTuQsFLOibbAMq2VSWoE4I/edit?usp=sharing
*
https://docs.google.com/document/d/1HlPDpwXzzuKp0n5qkKaIL9mYkjtlQHD37OF5pHQuXtE/edit?usp=sharing







2015年10月7日(水) 7:55 Doug Schepers :

> Hi, Tab–
>
> Thanks for the correction. I assumed that Houdini would expose more of
> the underpinnings of the ::selection pseudo-element [1] and its ilk.
> Maybe that hasn't surfaced (and maybe it won't). It does seem to be more
> magic, though, which I'd thought we were trying to demystify.
>
> But if there's no good story in Shadow DOM for things that explicitly
> deal with Range, I think that needs a solution.
>
>
> FWIW, JavaScript source-maps can comfortably deal with a similar
> problem, with minified/cached versions of multiple source documents
> (though I guess not multiple instantiations of the same source
> document). Still, I'd expect there's a non-terrible solution for
> serializing and expanding Shadow DOMs and pinpointing specific
> instantiations.
>
> (This makes me wonder how Shadow DOM is dealing with accessibility APIs;
> I'm assuming there's a good story there, and maybe something we can draw
> upon.)
>
> [1] https://drafts.csswg.org/css-pseudo-4/#highlight-selectors
>
> Regards–
> –Doug
>
> On 10/6/15 6:38 PM, Tab Atkins Jr. wrote:
> > On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers  wrote:
> >> Hi, Eliott–
> >>
> >> Good question.
> >>
> >> I don't have a great answer yet, but this is something that will need
> to be
> >> worked out with Shadow DOM, not just for this spec, but for Selection
> API
> >> and others, as well as to CSS, which has some Range-like styling.
> >
> > CSS doesn't care about this, because it doesn't expose its selections
> > to the wider DOM; it can freely style whatever it wants, including
> > ranges that span into shadows.
> >
> > This is indeed equivalent to the problem that the generic Selection
> > API has with Shadow DOM, tho.
> >
> > ~TJ
> >
>
>

[Bug 21083] Proposal key names for Android

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #9 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/9

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

Hi, Eliott–

Good question.

I don't have a great answer yet, but this is something that will need to 
be worked out with Shadow DOM, not just for this spec, but for Selection 
API and others, as well as to CSS, which has some Range-like styling.


I don't know if this means a change to Shadow DOM, to Range, or to 
FindText and other specs.


If there were a better way of representing non-element document segments 
than ranges, one that's more friendly to Shadow DOM, I'd be open to that 
as a return / representation type. I just don't know what that would be; 
if someone has a suggestion, please let me know.


In the meantime, could you raise that as an issue [1]? Or I can do it by 
proxy.


[1] https://github.com/w3c/findtext/

Regards–
–Doug

On 10/6/15 4:49 PM, Elliott Sprehn wrote:

How does this work with shadow dom? Range is not very friendly to that.

On Oct 6, 2015 4:35 PM, "Frederick Hirsch" > wrote:

This is a call for consensus (CfC) to publish a First Public Working
Draft (FPWD) of FindText API; deadline 14 October (1 week)

This FindText API is joint deliverable of the WebApps WG and Web
Annotation WG (listed as "Robust Anchoring" in the charters [1], [2]).

This is a Call for Consensus (CfC) to publish a FPWD of the FindText
API, using the following Editor's Draft as the basis:

http://w3c.github.io/findtext/

"This specification describes an API for finding ranges of text in a
document or part of a document, using a variety of selection criteria."

This API was presented to the WebApps WG last TPAC under a different
name, and with a fairly different design; it was modified to fit the
feedback from that meeting and from others, including narrowing of
scope, the introduction of Promises, and exposing low-level
functionality in the spirit of the Extensible Web.

The specification is largely based on the Annotator JavaScript
library's "robust anchoring" code, and a standalone polyfill is
under development. Feedback from possible implementers is especially
welcome.

This CfC satisfies the group's requirement to "record the groups'
decision to request advancement".

By publishing this FPWD, the group sends a signal to the community
to begin reviewing the document. The FPWD reflects where the groups
are on this spec at the time of publication; it does _not_
necessarily mean there is consensus on the spec's contents and the
specification may be updated.

If you have any comments or concerns about this CfC, please reply to
this e-mail by 14 October at the latest. Positive response is
preferred and encouraged, even a +1 will do  Silence will be
considered as agreement with the proposal.

regards, Frederick & Rob

Frederick Hirsch, Rob Sanderson

Co-Chairs, W3C Web Annotation WG

www.fjhirsch.com 
@fjhirsch

[1] http://www.w3.org/2014/06/webapps-charter.html#deliverables

[2] http://www.w3.org/annotation/charter/#scope

[Bug 21121] Define mobile phone related keys

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21121

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/11

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 21083] Proposal key names for Android

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083
Bug 21083 depends on bug 21121, which changed state.

Bug 21121 Summary: Define mobile phone related keys
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21121

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 21083] Proposal key names for Android

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083
Bug 21083 depends on bug 21137, which changed state.

Bug 21137 Summary: Define key names for game controller of Android
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21137

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 22569] MouseEvent should have DOMString pseudoElement property like TransitionEvent

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22569

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #5 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/15

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 22891] Mechanism to differentiate pointer input from multiple users/devices missing

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22891

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/16

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 23259] Expose ticks in wheel events

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23259

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/17

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 25485] D3E and corelation with DOM4(W3C)/DOM(WHATWAG) and DOM3 Core

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25485

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||gary...@google.com
 Resolution|--- |MOVED

--- Comment #7 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/19

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 21120] Define TV or A/V remote controller's keys

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21120

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #6 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/10

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 21083] Proposal key names for Android

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083
Bug 21083 depends on bug 21120, which changed state.

Bug 21120 Summary: Define TV or A/V remote controller's keys
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21120

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 21136] Define Home key and Back key of Android smartphone

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21136

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/12

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 21083] Proposal key names for Android

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21083
Bug 21083 depends on bug 21136, which changed state.

Bug 21136 Summary: Define Home key and Back key of Android smartphone
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21136

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Tab Atkins Jr.]

On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers  wrote:
> Hi, Eliott–
>
> Good question.
>
> I don't have a great answer yet, but this is something that will need to be
> worked out with Shadow DOM, not just for this spec, but for Selection API
> and others, as well as to CSS, which has some Range-like styling.

CSS doesn't care about this, because it doesn't expose its selections
to the wider DOM; it can freely style whatever it wants, including
ranges that span into shadows.

This is indeed equivalent to the problem that the generic Selection
API has with Shadow DOM, tho.

~TJ

[Bug 21137] Define key names for game controller of Android

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21137

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #10 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/13

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 21830] KeyboardEvent.locale is too general.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21830

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #5 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/14

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Call for Consensus: Publish First Public Working Draft of FindText API, respond by 14 October

[Doug Schepers]

Hi, Tab–

Thanks for the correction. I assumed that Houdini would expose more of 
the underpinnings of the ::selection pseudo-element [1] and its ilk. 
Maybe that hasn't surfaced (and maybe it won't). It does seem to be more 
magic, though, which I'd thought we were trying to demystify.


But if there's no good story in Shadow DOM for things that explicitly 
deal with Range, I think that needs a solution.



FWIW, JavaScript source-maps can comfortably deal with a similar 
problem, with minified/cached versions of multiple source documents 
(though I guess not multiple instantiations of the same source 
document). Still, I'd expect there's a non-terrible solution for 
serializing and expanding Shadow DOMs and pinpointing specific 
instantiations.


(This makes me wonder how Shadow DOM is dealing with accessibility APIs; 
I'm assuming there's a good story there, and maybe something we can draw 
upon.)


[1] https://drafts.csswg.org/css-pseudo-4/#highlight-selectors

Regards–
–Doug

On 10/6/15 6:38 PM, Tab Atkins Jr. wrote:

On Tue, Oct 6, 2015 at 3:34 PM, Doug Schepers  wrote:

Hi, Eliott–

Good question.

I don't have a great answer yet, but this is something that will need to be
worked out with Shadow DOM, not just for this spec, but for Selection API
and others, as well as to CSS, which has some Range-like styling.


CSS doesn't care about this, because it doesn't expose its selections
to the wider DOM; it can freely style whatever it wants, including
ranges that span into shadows.

This is indeed equivalent to the problem that the generic Selection
API has with Shadow DOM, tho.

~TJ

[Bug 23907] How do web apps distinguish if a keydown event causes text input?

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23907

Gary Kacmarcik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Gary Kacmarcik  ---
Now tracking as: https://github.com/w3c/uievents/issues/18

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 23575] The paragraph about patent policy is duplicated.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23575

Arthur Barstow  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||art.bars...@gmail.com
 Resolution|--- |FIXED

--- Comment #4 from Arthur Barstow  ---
This is fixed via
https://github.com/w3c/websockets/commit/8ca812f5f28694e1c148e46062b3a74c3beb4be4

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Indexed DB + Promises

[Jake Archibald]

On Mon, 5 Oct 2015 at 23:31 Joshua Bell  wrote:

> Yeah - "When control is returned to the event loop" isn't precise enough.
> It's an open issue in the 2nd Ed. and I welcome suggestions for tightening
> it up. Note that Jake Archibald, at least, was happy with the Blink
> behavior, after chewing on it for a bit. But it still seems far too subtle
> to me, and someone who writes blog posts explaining tasks vs. microtasks is
> probably not the average consumer of the API. :)
>

Step 8 of https://w3c.github.io/IndexedDB/#dom-idbdatabase-transaction can
queue a microtask to unset the active flag. It would mean:

var tx = db.transaction(…);

Promise.resolve().then(_ => {
  // transaction is now closed
});

…but if you want to keep the transaction open longer, that's what waitUntil
is for.

As for https://w3c.github.io/IndexedDB/#fire-a-success-event - this seems
fine as long as microtasks fire before step 4, which they should.

[Bug 27108] Push API should be allowed without dependency on service worker

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27108

Arthur Barstow  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #6 from Arthur Barstow  ---
This bug has been moved to a Github issue
.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 14214] missing definition of Transferable

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14214

Arthur Barstow  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Arthur Barstow  ---
The 24-Sept-2015 WD of Web Workers
 has two references to the
Transferable object as defined in HTML5
. Given
this, I think we can consider this bug as fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.