Bug 76214 - WebKit supports more of DOM 3 Events than DOMImplementation.hasFeature claims to
Summary: WebKit supports more of DOM 3 Events than DOMImplementation.hasFeature claims to
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: WebExposed
Depends on: 76104 76124 76212 76216
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-12 14:26 PST by Eric Seidel (no email)
Modified: 2013-01-25 11:02 PST (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2012-01-12 14:26:55 PST
WebKit supports more of DOM 3 Events than DOMImplementation.hasFeature claims to

This isn't particularly important, since hasFeature detection is *super* error prone.  But we should make some minimal effort to have our hasFeature results match reality.

I was most entertained by the fact that DOM 3 Events has a long discussion about why hasFeature detection is broken, and then goes on to say how they've slapped some lipstick on the pig, and now it's perfect:
http://www.w3.org/TR/DOM-Level-3-Events/#feature-detection
Comment 1 Eric Seidel (no email) 2012-01-12 14:28:03 PST
Oh, and we also don't support the new lipstick (extended feature strings) yet.  Although should be simple to do so.
Comment 3 Ojan Vafai 2012-01-13 12:25:55 PST
I don't think we should extend this further. See http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0073.html.
Comment 4 Adam Barth 2012-01-13 12:29:26 PST
> I don't think we should extend this further. See http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0073.html.

Those seem to be instructions for authors.  Does DOM4 have advice for implementors?  Are these requirements going to be removed from DOM3 events?
Comment 5 Ms2ger (he/him; ⌚ UTC+1/+2) 2012-01-13 12:30:36 PST
(In reply to comment #4)
> > I don't think we should extend this further. See http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0073.html.
> 
> Those seem to be instructions for authors.  Does DOM4 have advice for implementors?  Are these requirements going to be removed from DOM3 events?

AIUI, at the last F2F, the WebApps WG agreed to address my objections, and the presence of these requirements was one of them.
Comment 6 Adam Barth 2012-01-13 12:37:12 PST
> AIUI, at the last F2F, the WebApps WG agreed to address my objections, and the presence of these requirements was one of them.

Great!
Comment 7 Ojan Vafai 2012-01-13 12:42:19 PST
(In reply to comment #4)
> > I don't think we should extend this further. See http://lists.w3.org/Archives/Public/www-dom/2011JanMar/0073.html.
> 
> Those seem to be instructions for authors.  Does DOM4 have advice for implementors?  Are these requirements going to be removed from DOM3 events?

My point was more that there's an unresolved conflict between DOM4 and DOM3 events.

From DOM4: "Specifications may define which DOM features a user agent is to support, as well as an associated list of one or more case-sensitive strings representing version numbers, and under which circumstances, when necessary for compatibility (i.e. because of historical use). Specifications must not introduce new DOM features or new versions for existing features."

I agree with this for WebKit. We should only add things here as required by web compat.
Comment 8 Adam Barth 2012-01-13 12:43:49 PST
> I agree with this for WebKit. We should only add things here as required by web compat.

Maybe we should add a comment to this code to that effect so that folks don't fall into this trap in the future?
Comment 9 Eric Seidel (no email) 2012-01-13 14:14:49 PST
I'm not sure "trap" is the right word. :)  I'm fully aware that hasFeature is a bad idea.  I think if we can get it killed, that's the best.  But if it's going to continue to limp along, we should consider making our less completely out of touch.
Comment 10 Ojan Vafai 2012-01-13 14:17:34 PST
(In reply to comment #9)
> I'm not sure "trap" is the right word. :)  I'm fully aware that hasFeature is a bad idea.  I think if we can get it killed, that's the best.  But if it's going to continue to limp along, we should consider making our less completely out of touch.

Out of touch with what? I'm not sure we can completely kill the feature, but we can stop expanding it and let it be one of the warts that we're stuck with.
Comment 11 Eric Seidel (no email) 2012-01-13 14:32:27 PST
(In reply to comment #10)
> (In reply to comment #9)
> > I'm not sure "trap" is the right word. :)  I'm fully aware that hasFeature is a bad idea.  I think if we can get it killed, that's the best.  But if it's going to continue to limp along, we should consider making our less completely out of touch.
> 
> Out of touch with what? I'm not sure we can completely kill the feature, but we can stop expanding it and let it be one of the warts that we're stuck with.

The results that hasFeature returns are different from what specs tell us they should, as well as different from FF and IE.

One approach would be simply to make our hasFeature responses exactly match FF or IE, regardless of how they correlate to reality.

Another might be to make our hasFeature always return false.

Another might be to come up with (ask a spec to come up with) the limited set of strings for which we should return "true" and otherwise return false. :)

What I'm saying is this won't be the last time we touch hasFeature.  I'm not seeking to encourage perfect matching of the specs.  (Since we've decided that is a non-goal.) But since perfect matching of the specs is not the goal, we should figure out what the goal is, besides just keeping the code exactly as it happens to be today. :)
Comment 12 Ojan Vafai 2012-01-13 14:38:22 PST
(In reply to comment #11)
> The results that hasFeature returns are different from what specs tell us they should,

The specs disagree.

> as well as different from FF and IE.

To make an informed decision, it would be helpful to see what FF and IE support. I'd also like to see what IE8 supports since modern IE will almost certainly just implement what's in the current spec.

> Another might be to make our hasFeature always return false.

If we could do that without hurting web compat, I'd support it. I have no idea if we can or not.

> Another might be to come up with (ask a spec to come up with) the limited set of strings for which we should return "true" and otherwise return false. :)

This is the most promising approach. I think the discussion at TPAC leaned towards DOM4 hard-coding this list. I don't know if there was a resolution though.
Comment 13 Adam Barth 2012-01-13 15:24:13 PST
In the specific case of this bug, though, we don't want to add the strings from DOM3 events because it looks likely that DOM3 events will be changed to not have those strings.
Comment 14 Ms2ger (he/him; ⌚ UTC+1/+2) 2012-01-14 00:14:56 PST
(In reply to comment #12)
> (In reply to comment #11)
> > Another might be to come up with (ask a spec to come up with) the limited set of strings for which we should return "true" and otherwise return false. :)
> 
> This is the most promising approach. I think the discussion at TPAC leaned towards DOM4 hard-coding this list. I don't know if there was a resolution though.

Hmm, I thought we did that already; apparently DOM4 only has Core and XML at this point. I've filed <https://www.w3.org/Bugs/Public/show_bug.cgi?id=15555>.
Comment 16 Eric Seidel (no email) 2012-01-14 01:20:15 PST
Great!  I'm happy to remove all the other strings...