Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

2016-02-26 Thread Ryosuke Niwa

> On Feb 26, 2016, at 3:36 PM, Elliott Sprehn  wrote:
> 
> 
> 
> On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa  wrote:
>> 
>> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn  wrote:
>> >
>> >
>> >
>> > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa  wrote:
>> >>
>> >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn  
>> >> > wrote:
>> >> >
>> >> > Can you give a code example of how this happens?
>> >>
>> >> For example, execCommand('Delete') would result in sequentially deleting 
>> >> nodes as needed.
>> >> During this compound operation, unload events may fire on iframes that 
>> >> got deleted by this operation.
>> >>
>> >> I would like components to be notified that they got removed/disconnected 
>> >> from the document
>> >> before such an event is getting fired.
>> >>
>> >
>> > I'd rather not do that, all the sync script inside editing operations is a 
>> > bug, and you shouldn't depend on the state of the world around you in 
>> > there anyway since all browsers disagree (ex. not all of them fire the 
>> > event sync).
>> 
>> I don't think that's a bug given Safari, Chrome, and Gecko all fires unload 
>> event before finishing the delete operation.  It's an interoperable 
>> behavior, which should be spec'ed.
> 
> Firefox's behavior of when to fire unload definitely doesn't match Chrome or 
> Safari, but maybe it does in this one instance. I don't think it's worth 
> trying to get consistency there though, unload is largely a bug, we should 
> add a new event and get people to stop using it.

I strongly disagree with the assessment and oppose to adding a new event.

>> Anyway, this was just an easy example I could come up with.  There are many 
>> other examples that involve DOM mutation events if you'd prefer seeing those 
>> instead.
> 
> I'm not interested in making using mutation events easier.

And I'm not interested in pushing your agenda to deprecate mutation events 
either.

>> The fact of matter is that we don't live in the future, and it's better for 
>> API to be consistent in this imperfect world than for it to have weird edge 
>> cases.  As a matter of fact, if you end up being able to kill those sync 
>> events in the future, this will become non-issue since end-of-nano-task as 
>> you (Google) proposed will happen before dispatching of any event.
>> 
>> As things stand, however, we should dispatch lifecycle callbacks before 
>> dispatching these (legacy but compat mandating) events.
> 
> I disagree. Mutation events are poorly speced and not interoperably 
> implemented across browsers. I don't think we should run nanotasks down there.

It doesn't matter how poorly things are spec'ed.  The reality is that unload 
events and DOM mutation events are required for Web compatibility, and as such, 
should be considered when designing new API.

Anyhow, I'm going to invoke lifecycle callbacks before dispatching events in 
WebKit for now since we can't seem to come to consensus on this matter.

- R. Niwa




Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

2016-02-26 Thread Elliott Sprehn
On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa  wrote:

>
> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn 
> wrote:
> >
> >
> >
> > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa  wrote:
> >>
> >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn 
> wrote:
> >> >
> >> > Can you give a code example of how this happens?
> >>
> >> For example, execCommand('Delete') would result in sequentially
> deleting nodes as needed.
> >> During this compound operation, unload events may fire on iframes that
> got deleted by this operation.
> >>
> >> I would like components to be notified that they got
> removed/disconnected from the document
> >> before such an event is getting fired.
> >>
> >
> > I'd rather not do that, all the sync script inside editing operations is
> a bug, and you shouldn't depend on the state of the world around you in
> there anyway since all browsers disagree (ex. not all of them fire the
> event sync).
>
> I don't think that's a bug given Safari, Chrome, and Gecko all fires
> unload event before finishing the delete operation.  It's an interoperable
> behavior, which should be spec'ed.
>

Firefox's behavior of when to fire unload definitely doesn't match Chrome
or Safari, but maybe it does in this one instance. I don't think it's worth
trying to get consistency there though, unload is largely a bug, we should
add a new event and get people to stop using it.


>
> Anyway, this was just an easy example I could come up with.  There are
> many other examples that involve DOM mutation events if you'd prefer seeing
> those instead.
>

I'm not interested in making using mutation events easier.


>
> The fact of matter is that we don't live in the future, and it's better
> for API to be consistent in this imperfect world than for it to have weird
> edge cases.  As a matter of fact, if you end up being able to kill those
> sync events in the future, this will become non-issue since
> end-of-nano-task as you (Google) proposed will happen before dispatching of
> any event.
>
> As things stand, however, we should dispatch lifecycle callbacks before
> dispatching these (legacy but compat mandating) events.
>

I disagree. Mutation events are poorly speced and not interoperably
implemented across browsers. I don't think we should run nanotasks down
there.

- E


Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

2016-02-26 Thread Ryosuke Niwa

> On Feb 26, 2016, at 3:22 PM, Elliott Sprehn  wrote:
> 
> 
> 
> On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa  wrote:
>> 
>> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn  wrote:
>> >
>> > Can you give a code example of how this happens?
>> 
>> For example, execCommand('Delete') would result in sequentially deleting 
>> nodes as needed.
>> During this compound operation, unload events may fire on iframes that got 
>> deleted by this operation.
>> 
>> I would like components to be notified that they got removed/disconnected 
>> from the document
>> before such an event is getting fired.
>> 
> 
> I'd rather not do that, all the sync script inside editing operations is a 
> bug, and you shouldn't depend on the state of the world around you in there 
> anyway since all browsers disagree (ex. not all of them fire the event sync).

I don't think that's a bug given Safari, Chrome, and Gecko all fires unload 
event before finishing the delete operation.  It's an interoperable behavior, 
which should be spec'ed.

Anyway, this was just an easy example I could come up with.  There are many 
other examples that involve DOM mutation events if you'd prefer seeing those 
instead.

The fact of matter is that we don't live in the future, and it's better for API 
to be consistent in this imperfect world than for it to have weird edge cases.  
As a matter of fact, if you end up being able to kill those sync events in the 
future, this will become non-issue since end-of-nano-task as you (Google) 
proposed will happen before dispatching of any event.

As things stand, however, we should dispatch lifecycle callbacks before 
dispatching these (legacy but compat mandating) events.

- R. Niwa




Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

2016-02-26 Thread Elliott Sprehn
On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa  wrote:

>
> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn 
> wrote:
> >
> > Can you give a code example of how this happens?
>
> For example, execCommand('Delete') would result in sequentially deleting
> nodes as needed.
> During this compound operation, unload events may fire on iframes that got
> deleted by this operation.
>
> I would like components to be notified that they got removed/disconnected
> from the document
> before such an event is getting fired.
>
>
I'd rather not do that, all the sync script inside editing operations is a
bug, and you shouldn't depend on the state of the world around you in there
anyway since all browsers disagree (ex. not all of them fire the event
sync).

- E


Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts

2016-02-26 Thread Ryosuke Niwa

> On Feb 24, 2016, at 9:06 PM, Elliott Sprehn  wrote:
> 
> Can you give a code example of how this happens?

For example, execCommand('Delete') would result in sequentially deleting nodes 
as needed.
During this compound operation, unload events may fire on iframes that got 
deleted by this operation.

I would like components to be notified that they got removed/disconnected from 
the document
before such an event is getting fired.

```html


ElementWithInDocumentFlag extends HTMLElement {
  constructor(...args) {
 super(...args);
 this.inDocument = false;
  }

  connectedWithDocument() {
 this.inDocument = true;
  }

  disconnectedWithDocument() {
 this.inDocument = false;
  }
}

document.defineElement('hello-world', ElementWithInDocumentFlag);



  
  
  sucks



var helloWorld = document.querySelector('hello-world');
var container = document.getElementById('editor');

setTimeout(function () {
  document.querySelector('iframe').contentWindow.onunload = function () {
console.log(container.innerHTML); // This does not contain hello-world
console.assert(!helloWorld.inDocument); // This should be false!
  }
  container.focus();
  getSelection().selectAllChildren(container);
  setTimeout(function () {
document.execCommand('Delete');
  }, 500);
}, 500);


```

- R. Niwa




[Bug 28841] Incorporate changes suggested by Mixed Content

2016-02-26 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28841

Domenic Denicola  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|MOVED   |---

--- Comment #2 from Domenic Denicola  ---
Turns out this is part of a larger problem and can't be solved with a simple
HTML pull request; see https://github.com/whatwg/html/pull/222 discussion.

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


[Bug 29506] Support for a system-wide configuration file to specify permissions for web-applications

2016-02-26 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29506

Anne  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Anne  ---
That is intentional. Please study the web's security model.

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


[Bug 29506] Support for a system-wide configuration file to specify permissions for web-applications

2016-02-26 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29506

sworddrag...@aol.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--- Comment #2 from sworddrag...@aol.com ---
It is not only about XMLHttpRequest (there was just no suitable component so I
have choosen XHR from the list). This feature is about to make web applications
more competitive to native applications as currently they are very limited. For
example it is not possible to do network requests to fetch any data (and CORS
does not solve this problem as it gives the control to the service provider).

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


[Bug 29506] Support for a system-wide configuration file to specify permissions for web-applications

2016-02-26 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29506

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Anne  ---
We won't be adding new features to XMLHttpRequest. Certainly none that complex.
Sorry.

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