Re: Cross-page locking mechanism for indexedDB/web storage/FileHandle ?

[duanyao]

I'm glad to hear that somebody has been working on this issue!

After read your proposal and previous dicussion, I realized that such 
locking mechanism doesn't have to be tied to specific storage mechanism, 
and a promise-based API

is more general than a synchronous API.


在 2015年07月16日 01:12, Joshua Bell 写道:
Based on similar feedback, I've been noodling on this too. Here are my 
current thoughts:


https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191

Feedback welcome - I was planning to send this around shortly anyway.

On Wed, Jul 15, 2015 at 3:07 AM, 段垚 > wrote:


Hi all,

I'm developing an web-based editor which can edit HTML documents
locally (stored in indexedDB).
An issue I encountered is that there is no reliable way to ensure
that at most one editor instance (an instance is a web page) can
open a document at the same time.

* An editor instance may create a flag entry in indexedDB or
localStorage for each opened document to indicate "this document
is locked", and remove this flag when the document is closed.
However, if the editor is closed forcibly, this flag won't be
removed, and the document can't be opened any more!

* An editor instance may use storage event of localStorage to ask
"is this document has been opened by any other editor instance".
If there is no response for a while, it can open the document.
However, storage event is async so we are not sure about how long
the editor has to wait before opening the document.

* IndexedDB and FileHandle do have locks, but such locks can only
live for a short time, so can't lock an object during the entire
lifetime of an editor instance.

In a native editor application, it may use file locking
(https://en.wikipedia.org/wiki/File_locking) to achieve this purpose.
So maybe it is valuable to add similar locking mechanism to
indexedDB/web storage/FileHandle?

I propose a locking API of web storage:

  try {
localStorage.lock('file1.html');
myEditor.open('file1.html'); // open and edit the document
  } catch (e) {
alert('file1.html is already opened by another editor');
  }

Storage.lock() lock an entry if it has not been locked, and throw
if it has been locked by another page.
The locked entry is unlocked automatically after the page holding
the lock is unloaded. It can also be unlocked by calling
Storage.unlock().

What do you think?

Regards,
Duan Yao

Re: The key custom elements question: custom constructors?

[Jonas Sicking]

On Thu, Jul 16, 2015 at 12:16 PM, Domenic Denicola  wrote:
> From: Jonas Sicking [mailto:jo...@sicking.cc]
>
>> Like Anne says, if it was better defined when the callbacks should happen,
>> and that it was defined that they all happen after all internal 
>> datastructures
>> had been updated, but before the API call returns, then that would have
>> been much easier to implement.
>
> Right, but that's not actually possible with custom constructors. In 
> particular, you need to insert the elements into the tree *after* calling out 
> to author code that constructs them. What you mention is more like the 
> currently-specced custom elements lifecycle callback approach.
>
> Or am I misunderstanding?

No, that is a good point. The constructor callback does indeed need to
happen between an element is created and the element is inserted.

I think though that in this case it might be possible that we depend
on very little mutable state between the callbacks. I.e. that none of
the state that we depend on while the algorithm is running can be
mutated by the page.

In essence the only state we need to keep is the pointers to the
elements, and the parents that the elements should be inserted into.
And since pages can't delete any objects, those pointers will remain
valid throughout.

The only thing that I could think of might be tricky is around tables,
where sometimes we don't insert elements last in the childlist of
their parent. In that case we'll also carry state about where to
insert a given child. That state might get outdated since the page can
mess around with the DOM.

>> This is a problem inherent with synchronous callbacks and I can't think of a
>> way to improve specifications or implementations to help here. It's entirely
>> the responsibility of web authors to deal with this complexity.
>
> Well, specifications could just not allow synchronous callbacks of this sort, 
> which is kind of what we're discussing in this thread.

Agreed. What I meant was that if we're specifying synchronous
callbacks, there's nothing we can do in the specification to help with
this type of problem.

> That would help avoid the horrors of
>
> class XFoo extends HTMLElement {
>   constructor(stuff) {
> super();
>
> // Set up some default content that happens to use another custom element
> this.innerHTML = `${stuff}`;
>
> // All foos should also appear in a list off on the side!
> // Let's take care of that automatically for any consumers!
> document.querySelector("#list-of-foos").appendChild(this.cloneNode(true));
>   }
> }
>
> which seems like a well-meaning thing that authors could do, without knowing 
> what they've unleashed.

Exactly.

/ Jonas

RE: The key custom elements question: custom constructors?

[Domenic Denicola]

I have a related question: what happens if the constructor throws? Example:



"use strict";

window.throwingMode = true;

class XFoo extends HTMLElement {
constructor() {
if (window.throwingMode) {
throw new Error("uh-oh!");
}
}
}

document.registerElement("x-foo", XFoo);





"use strict";

// What does the DOM tree look like here? Is an x-foo present in some form?
// HTMLUnknownElement maybe? Just removed from existence?

// This will presumably throw:
document.body.innerHTML = "";
// But will it wipe out body first?

// What about
document.body.innerHTML = "[512 KiB of normal HTML] ";
// ? does the HTML make it in, or does the operation fail atomically, or 
something else?


// Now let's try something weirder.
// Assume  / XBar is a well-behaved custom element.

window.throwingMode = false;
const el = document.createElement("div");
el.innerHTML = "
a
b
b
";

window.throwingMode = true;
el.cloneNode(true); // this will throw, presumably...
// ... but does the XBar constructor run or not?
// ... if so, how many times?


> -Original Message-
> From: Domenic Denicola [mailto:d...@domenic.me]
> Sent: Wednesday, July 15, 2015 20:45
> To: public-webapps
> Subject: The key custom elements question: custom constructors?
> 
> Hi all,
> 
> Ahead of next week's F2F, I'm trying to pull together some clarifying and
> stage-setting materials, proposals, lists of open issues, etc. In the end, 
> they
> all get blocked on one key question:
> 
> **Is it OK to run author code during parsing/cloning/editing/printing (in
> Gecko)/etc.?**
> 
> If we allow custom elements to have custom constructors, then those must
> run in order to create properly-allocated instances of those elements; there
> is simply no other way to create those objects. You can shuffle the timing
> around a bit: e.g., while cloning a tree, you could either run the 
> constructors
> at the normal times, or try to do something like almost-synchronous
> constructors [1] where you run them after constructing a skeleton of the
> cloned tree, but before inserting them into the tree. But the fact remains
> that if custom elements have custom constructors, those custom
> constructors must run in the middle of all those operations.
> 
> We've danced around this question many times. But I think we need a clear
> answer from the various implementers involved before we can continue. In
> particular, I'm not interested in whether the implementers think it's
> technically feasible. I'd like to know whether they think it's something we
> should standardize.
> 
> I'm hoping we can settle this on-list over the next day or two so that we all
> come to the meeting with a clear starting point. Thanks very much, and
> looking forward to your replies,
> 
> -Domenic
> 
> [1]: https://lists.w3.org/Archives/Public/public-
> webapps/2014JanMar/0098.html

RE: The key custom elements question: custom constructors?

[Domenic Denicola]

From: Jonas Sicking [mailto:jo...@sicking.cc]

> Like Anne says, if it was better defined when the callbacks should happen,
> and that it was defined that they all happen after all internal datastructures
> had been updated, but before the API call returns, then that would have
> been much easier to implement.

Right, but that's not actually possible with custom constructors. In 
particular, you need to insert the elements into the tree *after* calling out 
to author code that constructs them. What you mention is more like the 
currently-specced custom elements lifecycle callback approach.

Or am I misunderstanding? 

> This is a problem inherent with synchronous callbacks and I can't think of a
> way to improve specifications or implementations to help here. It's entirely
> the responsibility of web authors to deal with this complexity.

Well, specifications could just not allow synchronous callbacks of this sort, 
which is kind of what we're discussing in this thread. That would help avoid 
the horrors of

class XFoo extends HTMLElement {
  constructor(stuff) {
super();

// Set up some default content that happens to use another custom element
this.innerHTML = `${stuff}`;

// All foos should also appear in a list off on the side!
// Let's take care of that automatically for any consumers!
document.querySelector("#list-of-foos").appendChild(this.cloneNode(true));
  }
}

which seems like a well-meaning thing that authors could do, without knowing 
what they've unleashed.

Re: The key custom elements question: custom constructors?

[Jonas Sicking]

On Thu, Jul 16, 2015 at 9:49 AM, Domenic Denicola  wrote:
> From: Anne van Kesteren [mailto:ann...@annevk.nl]
>
>> I think the problem is that nobody has yet tried to figure out what 
>> invariants
>> that would break and how we could solve them. I'm not too worried about
>> the parser as it already has script synchronization, but cloneNode(), ranges,
>> and editing, do seem problematic. If there is a clear processing model,
>> Mozilla might be fine with running JavaScript during those operations.
>
> Even if it can be specced/implemented, should it? I.e., why would this be OK 
> where MutationEvents are not?

I think there were two big problems with MutationEvents.

>From an implementation point of view, the big problem was that we
couldn't use an implementation strategy like:

1. Perform requested task
2. Get all internal datastructures and invariants updated.
3. Fire MutationEvents callback.
4. Return to JS.

Since step 4 can run arbitrary webpage logic, it's fine that step 3,
which is run right before, does as well. I.e. we could essentially
treat step 3 and 4 as the same.

This was particularly a problem for DOMNodeRemoved since it was
required to run *before* the required task was supposed to be done.
But it was also somewhat a problem for DOMNodeInserted since it could
be interpreted as something that should be done interweaved with other
operations, for example when a single DOM API call caused multiple
nodes to be inserted.

Like Anne says, if it was better defined when the callbacks should
happen, and that it was defined that they all happen after all
internal datastructures had been updated, but before the API call
returns, then that would have been much easier to implement.


The second problem is that it causes webpages to have to deal with
reentrancy issues. Synchronous callbacks are arguably just as big of a
problem for webpages as it is for browser engines. It meant that the
callback which is synchronously called when a node is inserted might
remove that node. Or might remove some other node, or do a ton of
other changes.

Callbacks which are called synchronously have a huge responsibility to
not do "crazy things". This gets quite complex as code bases grow. A
synchronous callback might do something that seems safe in and of
itself, but that in turn triggers a couple of other synchronous
callbacks, which trigger yet more callbacks, which reenters something
unexpected.

The only way to deal with this is for webpages to do the absolute
minium thing they can in the synchronous callback, and do anything
else asynchronously. That is what implementations tries to do. The
code that's run during element construction tries to only touch a
minimal number of things in the rest of the outside world, ideally
nothing.

This is a problem inherent with synchronous callbacks and I can't
think of a way to improve specifications or implementations to help
here. It's entirely the responsibility of web authors to deal with
this complexity.

/ Jonas

Re: [WebIDL] T[] migration

[Jonas Sicking]

On Thu, Jul 16, 2015 at 8:45 AM, Travis Leithead
 wrote:
> Recommendations:
> ·HTML5
> ·Web Messaging
>
> Other references:
> ·CSS OM
> ·Web Sockets
> ·WebRTC

Note that in practice I would think that most implementations return
objects which have a .item() function on them. So replacing with just
a plain FrozenArray likely would not be web compatible :(

We likely need to introduce something like FrozenArrayWithItem
which returns a subclass of Array that has a .item function.

Or we need to add Array.prototype.item, but that would require
convincing TC39 that that's a good idea, and would need testing for
web compatibility.

/ Jonas

Re: [WebIDL] T[] migration

[Martin Thomson]

On 16 July 2015 at 09:36, Domenic Denicola  wrote:
> - https://w3c.github.io/webrtc-pc/

Specifically:
https://w3c.github.io/webrtc-pc/#rtctrackevent - should be OK

https://github.com/w3c/webrtc-pc/issues/251

Re: The key custom elements question: custom constructors?

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 6:49 PM, Domenic Denicola  wrote:
> Even if it can be specced/implemented, should it? I.e., why would this be OK 
> where MutationEvents are not?

Apart from the verbosity and performance issues with mutation events,
I think the main problem with mutation events has been the lack of a
clear processing model (and that is true to this day), causing crashes
in user agents:
https://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html

In other words, the specification authors invented something, but
didn't do the due diligence of writing down how that invention would
actually impact the overall model. (This is a problem to this day.
E.g., UI events.)

So the main problem with custom constructors seems to be the
processing model, combined with the work of actually implementing and
vetting that.


-- 
https://annevankesteren.nl/

RE: The key custom elements question: custom constructors?

[Domenic Denicola]

From: Anne van Kesteren [mailto:ann...@annevk.nl]

> I think the problem is that nobody has yet tried to figure out what invariants
> that would break and how we could solve them. I'm not too worried about
> the parser as it already has script synchronization, but cloneNode(), ranges,
> and editing, do seem problematic. If there is a clear processing model,
> Mozilla might be fine with running JavaScript during those operations.

Even if it can be specced/implemented, should it? I.e., why would this be OK 
where MutationEvents are not?

RE: [WebIDL] T[] migration

[Domenic Denicola]

So in terms of concrete updates, we'd need to fix

- https://html.spec.whatwg.org/
- https://w3c.github.io/webrtc-pc/
- http://dev.w3.org/csswg/cssom/ (sigh, still no https?)

The other documents mentioned are either obsolete or forks of (sections of) the 
first. Once the LS/EDs are fixed, then we can let The Process take over and 
worry about the copy-and-pasting/errata/etc., but getting the LS/EDs right is 
the important part for implementers.

Note that FrozenArray is not a drop-in replacement for T[]. In particular, 
T[] is read-only by authors but mutable by UAs, whereas FrozenArray is 
immutable. This might make things trickier.

---

From: Travis Leithead [mailto:travis.leith...@microsoft.com] 
Sent: Thursday, July 16, 2015 11:45
To: public-webapps; Ian Hickson
Subject: [WebIDL] T[] migration

Hey folks, 

Now that WebIDL has added FrozenArray<> and dropped T[], it’s time to switch 
over! On the other hand, there are a number of specs that have already gone to 
Rec that used the old syntax.

Recommendations:
• HTML5
• Web Messaging

Other references:
• CSS OM
• Web Sockets
• WebRTC

Legacy/Deprecated references:
• TypedArrays (replaced by ES2015)
• Web Intents

Thoughts on what to do about this? Should we consider keeping T[] in WebIDL, 
but having it map to FrozenArray<>? Should we issue errata to those Recs?

Re: [WebIDL] T[] migration

[Boris Zbarsky]

On 7/16/15 12:02 PM, cha...@yandex-team.ru wrote:

But would just abandoning T[] break anything elsewhere?


It's hard to break something that never worked.  No browser ever 
implemented anything for T[] to my knowledge.


-Boris

Re: The key custom elements question: custom constructors?

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 6:03 PM, Domenic Denicola  wrote:
> Ah OK, thanks. Is there any way to get a consensus from Mozilla as a whole, 
> preferably ahead of the F2F?

I think the problem is that nobody has yet tried to figure out what
invariants that would break and how we could solve them. I'm not too
worried about the parser as it already has script synchronization, but
cloneNode(), ranges, and editing, do seem problematic. If there is a
clear processing model, Mozilla might be fine with running JavaScript
during those operations.

I've been a bit too occupied with Fetch et al to put in the hours
myself ahead of the meeting.


-- 
https://annevankesteren.nl/

Re: [WebIDL] T[] migration

[Boris Zbarsky]

On 7/16/15 11:45 AM, Travis Leithead wrote:

Now that WebIDL has added FrozenArray<> and dropped T[], it’s time to
switch over! On the other hand, there are a number of specs that have
already gone to Rec that used the old syntax.


Note that since the old syntax was never supported by any UA in any 
meaningful way I'm aware of, those are basically problems in those specs 
that should technically have prevented them from going to REC (due to 
lack of two interoperable implementations).


Looking at the uses of IDL arrays in the relevant specs (links would 
have helped!):



Recommendations:
·HTML5


Assuming we're talking about 
, I don't 
see any uses of IDL arrays in this specification.  Am I missing something?



·Web Messaging


I'm not sure which specification this is referring to...


Other references:

·CSS OM


Presumably this is Document.styleSheetSets?  In practice, I believe no 
one except Gecko implements this and I therefore don't expect it to make 
it to REC... Updating this draft to use FrozenArray<> would be possible, 
of course.



·Web Sockets


I assume we're talking about 
.  This is just buggy 
and needs to be fixed as should 
; 
it's using an IDL array as an argument, which is pretty much never 
what's desired even back in the world where IDL arrays existed. 
Certainly it's not desired here.  What Gecko ships is a sequence 
argument instead.  I just checked, and so does Blink.  So does WebKit. 
What do Trident and Edge do?


Note that this is tracked by 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28102 at least.



·WebRTC


Are we talking about ?  I 
don't see usage of IDL arrays here.



Legacy/Deprecated references:

·TypedArrays (replaced by ES2015)


This has no bearing on reality; we should just mark it so somehow and 
move on.  IDL arrays are hardly the only problem in this document...



·Web Intents


This could use some mix of FrozenArray and sequence.  But does anyone 
care about this document?


-Boris

Re: [WebIDL] T[] migration

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 6:02 PM,   wrote:
> But would just abandoning T[] break anything elsewhere? Is there any value in 
> having it mapped and deprecated?

If specifications were written by a team the size of a browser that
might be reasonable, but it really seems like more trouble than it's
worth.


-- 
https://annevankesteren.nl/

RE: The key custom elements question: custom constructors?

[Domenic Denicola]

From: Olli Pettay [mailto:o...@pettay.fi]

> That is too strongly said, at least if you refer to my email (where I 
> expressed
> my opinions, but as usually, others from Mozilla may have different opinions).
> I said "I'd prefer if we could avoid that [Running author code during
> cloneNode(true)]."
> 
> And my worry is largely in the spec level.
> It would be also a bit sad to reintroduce some of the issues MutationEvents
> have to the platform, now that we're finally getting rid of those events

Ah OK, thanks. Is there any way to get a consensus from Mozilla as a whole, 
preferably ahead of the F2F?

Re: [WebIDL] T[] migration

[chaals]

16.07.2015, 17:59, "Anne van Kesteren" :
> On Thu, Jul 16, 2015 at 5:45 PM, Travis Leithead
>  wrote:
>>  Should we consider keeping T[] in WebIDL, but having it map to 
>> FrozenArray<>?
>
> We should just update the relevant specifications.

That seems a rational approach in any event.

But would just abandoning T[] break anything elsewhere? Is there any value in 
having it mapped and deprecated?

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: [WebIDL] T[] migration

[Anne van Kesteren]

On Thu, Jul 16, 2015 at 5:45 PM, Travis Leithead
 wrote:
> Should we consider keeping T[] in WebIDL, but having it map to FrozenArray<>?

We should just update the relevant specifications. We'll continue to
hit this as IDL still needs to evolve quite a bit.


-- 
https://annevankesteren.nl/

[WebIDL] T[] migration

[Travis Leithead]

Hey folks,

Now that WebIDL has added FrozenArray<> and dropped T[], it's time to switch 
over! On the other hand, there are a number of specs that have already gone to 
Rec that used the old syntax.

Recommendations:

*HTML5

*Web Messaging

Other references:

*CSS OM

*Web Sockets

*WebRTC

Legacy/Deprecated references:

*TypedArrays (replaced by ES2015)

*Web Intents

Thoughts on what to do about this? Should we consider keeping T[] in WebIDL, 
but having it map to FrozenArray<>? Should we issue errata to those Recs?

RfC: LCWD of Tracking Compliance and Scope; deadline October 7

[Arthur Barstow]

WebApps has been asked to review the Tracking Protection group's July 14 
Last Call Working Draft of T/racking Compliance and Scope/:


  

If anyone in WebApps wants to propose an official group response, please 
do so ASAP, in reply to this e-mail so the group can discuss it.


Comments should be sent to public-tracking-comments @ w3.org (archive 
[1]) by October 7. Presumably, the group also welcomes "silent review" 
feedback such as "I reviewed section N.N and have no comments".


-Thanks, ArtB

[1] 


On 7/14/15 9:01 PM, Justin Brookman wrote:
The Tracking Protection Working Group published today (14 July 2015) a 
Last Call Working Draft of the Tracking Compliance and Scope 
specification, and we would like to ask for review comments from the 
following groups: Privacy Interest Group, WAI Protocols and Formats 
Working Group, Web Applications WG, Internationalization Working 
Group, and Device APIs WG. Of course, we welcome and encourage other 
reviews.


The draft is available here:
http://www.w3.org/TR/2015/WD-tracking-compliance-20150714/

Abstract:
This specification defines a set of practices for compliance with a 
user's Do Not Track (DNT) tracking preference to which a server may 
claim adherence.
Comments will be most useful in identifying particular problems with 
the specification that might inhibit adoption, where this 
specification fails to further goals of user privacy and user control, 
and whether this specification creates or does not otherwise resolve 
dependencies with other technical standards, practices, or processes.


The Last Call period ends 7 October 2015. Please send comments to the 
publicly-archived public-tracking-comme...@w3.org 
 mailing list.


Thanks,
Carl Cargill, Justin Brookman, Matthias Schunter
Co-Chairs of the Tracking Protection WG

* Announcement of Last Call publication decision: 
https://lists.w3.org/Archives/Public/public-tracking/2015Jul/.html
* Last Call comment issues will be listed in a specific Tracker 
product: https://www.w3.org/2011/tracking-protection/track/products/8
* Patent disclosure information is available: 
http://www.w3.org/2004/01/pp-impl/49311/status

Re: The key custom elements question: custom constructors?

[Olli Pettay]

On 07/16/2015 08:30 AM, Domenic Denicola wrote:

From: Travis Leithead [mailto:travis.leith...@microsoft.com]


I've discussed this issue with some of Edge's key parser developers.


Awesome; thank you for doing that!


I believe to be the most straightforward approach that most closely matches how 
the platform itself works


Thanks, it's helpful to get this non-implementation-focused reasoning out in 
the open.

What are your responses to Olli's concerns about how this is hard to spec properly? 
I.e. "no one ever managed to spec MutationEvents properly, and
running author code during cloneNode(true) is at least as hard problem to 
solve." Are you concerned about interop? It sounds like it's technically
feasible for you, but do you think it will be technically feasible in a way 
that is interoperable? (I realize that's a hard question to answer.)


For example, in parsing, I would expect that the callout happens after initial 
instance creation, but before the target node is attached to the
DOM tree by the parser.


Can you expand on this more? In particular I am confused on how "initial instance 
creation" can happen without calling the constructor.


I am sympathetic to this concern, but have my own reservations about the 
proto-swizzle technique.


I think this is not the correct positioning for this question. There are two 
independent questions: is it OK to run author code during parsing and
cloning? And separately, is there utility to be gained from proto-swizzling? 
You can imagine (at least) four solutions for this 2x2 grid of yes/no
responses. In this particular thread I really want to focus on the former 
question since it is foundational.

---

It sounds like so far we have:

- Mozilla against running author code during these times

That is too strongly said, at least if you refer to my email
(where I expressed my opinions, but as usually, others from Mozilla may have 
different opinions).
I said "I'd prefer if we could avoid that [Running author code during 
cloneNode(true)]."

And my worry is largely in the spec level.
It would be also a bit sad to reintroduce some of the issues MutationEvents 
have to the platform, now that we're
finally getting rid of those events




- Microsoft for running author code during these times, but sympathetic to 
concerns in the
opposite direction

Is this correct so far?

I suppose I should also note

- Google against running author code during these times, based on investigation by 
Dominic (with an "i") into the complexity it would add to the
platform/event loop/etc. (I believe the exact phrase "MutationEvents all over 
again" was used.)