On 04/25/2012 12:16 AM, Anne van Kesteren wrote:
On Tue, 24 Apr 2012 23:02:22 +0200, Boris Zbarsky wrote:
(DOM3's language
about "default actions" confuses this; I suggest reading DOM4's event
section to get a good picture of how this actually works.)
Or rather how the DOM4 editor is choosing
On 04/24/2012 10:38 PM, Glenn Maynard wrote:
On Tue, Apr 24, 2012 at 2:23 PM, Olli Pettay mailto:olli.pet...@helsinki.fi>> wrote:
Yes. It should be possible to re-dispatch events. But if a script
running on a web page dispatches event, the event must become
untrusted.
What's the po
[mailto:olli.pet...@helsinki.fi]
>Sent: Tuesday, April 24, 2012 12:23 PM
>To: Travis Leithead
>Cc: public-weba...@w3c.org; Anne van Kesteren (ann...@opera.com); Jacob
>Rossi
>Subject: Re: [DOM3 Events/DOM4] re-dispatching trusted events with
>initEvent
>
>On 04/24/2012 09:43 PM, Travi
On 4/24/12 5:16 PM, Anne van Kesteren wrote:
On Tue, 24 Apr 2012 23:02:22 +0200, Boris Zbarsky wrote:
(DOM3's language
about "default actions" confuses this; I suggest reading DOM4's event
section to get a good picture of how this actually works.)
Or rather how the DOM4 editor is choosing to
On Tue, Apr 24, 2012 at 4:02 PM, Boris Zbarsky wrote:
> Actually, no. The way events work, at least in Gecko, is more like this
> (conceptually; the actual implementation is somewhat different):
>
> browse_button.**addEventListenerInSystemEventG**roup("click",
>
(Let's avoid "click" in example
On Tue, 24 Apr 2012 23:02:22 +0200, Boris Zbarsky wrote:
(DOM3's language
about "default actions" confuses this; I suggest reading DOM4's event
section to get a good picture of how this actually works.)
Or rather how the DOM4 editor is choosing to conceptualize it, which may
not have much be
On 4/24/12 5:08 PM, Tobie Langel wrote:
On 4/24/12 11:04 PM, "Boris Zbarsky" wrote:
On 4/24/12 5:02 PM, Boris Zbarsky wrote:
Oh, and that's before we get into default actions implemented by
extensions.
And one more thing: extensions _definitely_ want to know whether events
are trusted or no
On 4/24/12 11:04 PM, "Boris Zbarsky" wrote:
>On 4/24/12 5:02 PM, Boris Zbarsky wrote:
>> Oh, and that's before we get into default actions implemented by
>> extensions.
>
>And one more thing: extensions _definitely_ want to know whether events
>are trusted or not. This doesn't necessitate a web-
On 4/24/12 5:02 PM, Boris Zbarsky wrote:
Oh, and that's before we get into default actions implemented by
extensions.
And one more thing: extensions _definitely_ want to know whether events
are trusted or not. This doesn't necessitate a web-exposed API,
obviously; the property could only be
On 4/24/12 4:34 PM, Glenn Maynard wrote:
This is a common misconception of how events work. If you're a browser,
default events do not--except for one or two web-compat exceptions--look
like this:
browse_button.addEventListener("click", function(e) { if(e.isTrusted)
openFilePicker(); }, false);
On Tue, 24 Apr 2012 22:00:24 +0200, Glenn Maynard wrote:
On Tue, Apr 24, 2012 at 2:54 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
Glenn, isTrusted is the indicator that helps the web developer
distinguish between an event fired by the UA, or one fired by JavaScript
(e.g., dispat
(Sorry, forgot to merge drafts.)
On Tue, Apr 24, 2012 at 3:02 PM, Tobie Langel wrote:
> See http://www.w3.org/TR/DOM-Level-3-Events/#events-event-type-isTrusted
>
Please don't link people to TR specs; that text is almost a year out of
date, which invites pain and confusion. Always use editor's
On Tue, Apr 24, 2012 at 3:06 PM, Tobie Langel wrote:
> Are you asking about the purpose of exposing the property or the purpose
> of trusted events?
>
I'm asking about the property. The flag underneath it exists only to
implement the property.
The latter's obvious: prevent visited content from
On 4/24/12 10:00 PM, "Glenn Maynard" wrote:
>On Tue, Apr 24, 2012 at 2:54 PM, Travis Leithead
> wrote:
>
>Glenn, isTrusted is the indicator that helps the web developer
>distinguish between an event fired by the UA, or one fired by JavaScript
>(e.g., dispatchEvent).
>
>I know what it does; I'm as
On 4/24/12 9:54 PM, "Travis Leithead"
wrote:
>Glenn, isTrusted is the indicator that helps the web developer
>distinguish between an event fired by the UA, or one fired by JavaScript
>(e.g., dispatchEvent).
>
>
>From: Glenn Maynard [mailto:gl...@zewt.org]
>
>
>What's the point of isTrusted, any
On Tue, Apr 24, 2012 at 2:54 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> Glenn, isTrusted is the indicator that helps the web developer
> distinguish between an event fired by the UA, or one fired by JavaScript
> (e.g., dispatchEvent).
>
I know what it does; I'm asking what its
...@w3c.org; Anne van Kesteren
(ann...@opera.com); Jacob Rossi
Subject: Re: [DOM3 Events/DOM4] re-dispatching trusted events with initEvent
On Tue, Apr 24, 2012 at 2:23 PM, Olli Pettay
mailto:olli.pet...@helsinki.fi>> wrote:
Yes. It should be possible to re-dispatch events. But if a script
r
On Tue, Apr 24, 2012 at 2:23 PM, Olli Pettay wrote:
>
> Yes. It should be possible to re-dispatch events. But if a script
> running on a web page dispatches event, the event must become
> untrusted.
What's the point of isTrusted, anyway? You have to trust other scripts
running in the same page a
On 04/24/2012 09:43 PM, Travis Leithead wrote:
Based on my reading of DOM4, initEvent makes it possible to transform
a trusted event into a non-trusted event and dispatch it. Is that
intentional?
AFAIK, yes
It is only currently supported in Firefox and Opera. In
IE, Chrome and Safari, the ini
19 matches
Mail list logo
