Re: UIEvents should provide relatedTarget property

@Doug Schepers:

Excellent! Great work.


@Garrett Smith:

>How do you propose handling issue WRT security? Say user focuses
>element in a frame on a different domain?

I would believe that relatedTarget should be null in these cases.

I suppose that relatedTarget only returns null if user privileges / same 
origin policy prevent to access the "other" element from within the event 
handler. There are specifications under development (e.g. 
https://wiki.mozilla.org/Security/CSP/Spec) allowing to access foreign code 
under certain circumstances. In that case relatedTarget should return a 
valid reference to the counter-element.

Referring to comments from Olli Pettay:

5.2.2
- I think we want relatedTarget to be null when it would point to
   an element outside the current document.

Agreed. But only in case of an access violation. Otherwise it might be an 
enterprise application trying to interact with distinct parts of the 
software.

- In many events it is specified that target and relatedTarget point to
   the same object. Could the relatedTarget be just null in those cases.

I would prefer if the relatedTarget attribute would equal the target 
attribute in these cases. Otherwise it would be impossible to distinguish 
between an access violation and the event of an element yielding focus to 
itself. (Although I can't possibly think of a case where this should occur.)


Cheers,
Axel Dahmen
www.axeldahmen.de



--------------------------------
"Doug Schepers" <schepers@w3.org> schrieb im Newsbeitrag 
news:4BBD3442.5040007@w3.org...
> Hi, Axel-
>
> Thanks for your comment.  We have introduced a new FocusEvent interface 
> for just this purpose:
>
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-focusevent
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>
>
> Axel Dahmen wrote (on 4/7/10 8:04 PM):
>> There are scenarios when it's important to know which element is gaining
>> focus. Currently it's impossible to find out which element is going to
>> get the focus within a blur() or focusout() event handler.
>>
>> Thus, I suggest to add a "EventTarget relatedTarget" property to the
>> UIEvent class...
>>
>> a) pointing to the element which gains focus within blur() and
>> focusout() events,
>>
>> b) pointing to the element which has lost focus within focus() and
>> focusin() events.
>>
>>
>>
>> Moreover, an event sequence policy should be defined, stating the
>> focus() will immediately follow blur() and focusin() will immediately
>> follow focusout().
>>
>> Currently, Google Chrome and Apple Safari enqueue focusin() *after*
>> focusout() has returned. This causes other events to intercept these two
>> events (e.g. a call to setTimeout(..., 0). This should not be possible.
>>
>>
>> Calling element.focus() within a blur() event handler should update the
>> target for the enqueued focus() event but not re-enqueue the focus()
>> event. Same for focusin()/focusout().
>>
>>
>> Axel Dahmen
>> www.axeldahmen.de
>>
>>
>>
>
>
>
>

Received on Thursday, 8 April 2010 18:08:30 UTC