This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25358 - "Context info: UIEvent.view" sometimes only has defaultView
Summary: "Context info: UIEvent.view" sometimes only has defaultView
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-15 22:54 UTC by Gary Kacmarcik
Modified: 2014-04-29 00:16 UTC (History)
3 users (show)

See Also:


Attachments

Description Gary Kacmarcik 2014-04-15 22:54:10 UTC
(originally from 25295)

In the table that defines the types of events, rows "Context info: UIEvent.view" somtimes have only defaultView, but there is also defaultView, null. These are the correct values? Look:
blur UIEvent.view: defaultView
focus, focusin, focusout UIEvent.view: defaultView, null
Any explanation why they have different values​​?

Te same situtation:
load, unload, abort, error, select UIEvent.view: defaultView, null
resize, scroll UIEvent.view: defaultView
Comment 1 Gary Kacmarcik 2014-04-16 00:28:41 UTC
Window attributes should always allow null.

Although if the event is trusted, the Window should not be null.
Comment 2 Arkadiusz Michalski (Spirit) 2014-04-16 13:17:45 UTC
I think null should be add to all event based on UIEvent (for all UIEvent.view in all tables). This value is un-initialized value for UIEvent.view. Wen we make untrusted events we don't need to change it so it will always fit. This applies to both constructors and init*Methods.
Comment 3 Travis Leithead [MSFT] 2014-04-23 01:03:26 UTC
Fairly straightforward change.
Comment 4 Arkadiusz Michalski (Spirit) 2014-04-24 09:53:48 UTC
In accordance with
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25357

please don't add null everywhere. Untrusted cases we can deduce directly from IDL definition. These tables should present only trusted cases, which would be very helpful. So, if it is possible to obtain a null value for a trusted event, this value should appear in the table.
Comment 5 Gary Kacmarcik 2014-04-28 23:10:49 UTC
I agree that having information for valid values for trusted events would be useful, but:

(1) That is apparently not what these tables contain (the tables don't claim to include info for trusted events)

(2) It is out of scope to include that in the spec now. Getting that information for all browsers would be a lot of work to ensure that it was correct and would significantly delay D3E.

OTOH, if you know of a source where this information (for all browsers) exists, I would love to update these tables to include that info (and make it clear that the tables described trusted events only).
Comment 6 Gary Kacmarcik 2014-04-28 23:24:48 UTC
Argh!  I just noticed that the table in 5.1.1 does say "Trusted event target types" at the top of the column.

Reopening this so that I can remove null from events that don't allow it for trusted events.
Comment 7 Arkadiusz Michalski (Spirit) 2014-04-28 23:48:22 UTC
(In reply to Gary Kacmarcik from comment #5)

> OTOH, if you know of a source where this information (for all browsers)
> exists, I would love to update these tables to include that info (and make
> it clear that the tables described trusted events only).

I don't have that info. At now we have a lot of events and hard to verify, because HTML5 very flattens some of them, and of course there are other specifications that use these events (with inaccurate descriptions too).

Just only inform that now this tables are not consistent with either the trusted or untrusted of cases. Taking into account the untrusted cases unnecessarily obscured this tables, we can read IDL def and see whats going on, but trusted cases is not so obvious and requires more effort, which I think is worth to bear to make it right.

In free time I can collect all the weird cases in one place (that caught my attention), but in reality it would require more work. Something can be add, something remove, but perhaps it would be better than the current state of these tables.

(In reply to Gary Kacmarcik from comment #6)

>Argh!  I just noticed that the table in 5.1.1 does say "Trusted event target types" at the top of the column.

That is why I proposed to take into account only trusted cases (Comment 2).
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25357#c2
Comment 8 Gary Kacmarcik 2014-04-29 00:16:22 UTC
https://dvcs.w3.org/hg/dom3events/rev/40019b0b87c3

(In reply to spiritRKS1910 from comment #7)
> (In reply to Gary Kacmarcik from comment #5)
> 
> In free time I can collect all the weird cases in one place (that caught my
> attention), but in reality it would require more work. Something can be add,
> something remove, but perhaps it would be better than the current state of
> these tables.

Travis and I went through these and compared them with HTML5 and updated these tables. The target types and UIEvent.view context should reflect the trusted events and should also be consistent between the summary table and the event tables.

We also updated the tables to be more explicit that they are describing trusted events (and trusted event context).

If you have a chance to review the information there, that would be great.  We still have to do a bit more cleanup in other parts of the table to make it consistent and complete.

> (In reply to Gary Kacmarcik from comment #6)
> 
> >Argh!  I just noticed that the table in 5.1.1 does say "Trusted event target types" at the top of the column.
> 
> That is why I proposed to take into account only trusted cases (Comment 2).
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25357#c2

I missed that the first time I was looking at the table. Thanks for bringing that to my attention.