Bug 70469 - Document.cpp shouldn't need to know about every event for every feature
Summary: Document.cpp shouldn't need to know about every event for every feature
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adam Barth
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-19 20:12 PDT by Adam Barth
Modified: 2011-10-19 22:04 PDT (History)
2 users (show)

See Also:

Attachments
Patch (28.79 KB, patch)
2011-10-19 20:13 PDT, Adam Barth 		eric: review+
Details | Formatted Diff | Diff
The generated file (6.24 KB, text/plain)
2011-10-19 20:14 PDT, Adam Barth 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 2011-10-19 20:12:39 PDT 
Document.cpp shouldn't need to know about every event for every feature
Comment 1 Adam Barth 2011-10-19 20:13:56 PDT 
Created attachment 111714 [details]
Patch
Comment 2 Adam Barth 2011-10-19 20:14:47 PDT 
Created attachment 111715 [details]
The generated file
Comment 3 Eric Seidel (no email) 2011-10-19 20:17:49 PDT 
Comment on attachment 111714 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=111714&action=review

LGTM.

> Source/WebCore/WebCore.gyp/scripts/action_makenames.py:120
> +        if inputBasename == 'make_names.pl' \
> +            or inputBasename == 'make_event_factory.pl':

Really?

> Source/WebCore/dom/EventFactory.h:38
> +    static PassRefPtr<Event> create(const String& eventType);

AtomicString?
Comment 4 Adam Barth 2011-10-19 21:02:20 PDT 
Yeah, I would have thought atomic string too, but that's not how the old code worked.
Comment 5 Adam Barth 2011-10-19 21:49:12 PDT 
Committed r97933: <http://trac.webkit.org/changeset/97933>
Comment 6 Sam Weinig 2011-10-19 22:00:30 PDT 
Looks like this probably changed the behavior for the TouchEvent interface when the RuntimeSwitch was off.  Was that intentional?  Do we care?
Comment 7 Adam Barth 2011-10-19 22:01:47 PDT 
Yeah, I decided I didn't care.  None of the other features work that way.
Comment 8 Adam Barth 2011-10-19 22:01:55 PDT 
I should have noted that in the ChangeLog.
Comment 9 Sam Weinig 2011-10-19 22:04:41 PDT 
(In reply to comment #8)
> I should have noted that in the ChangeLog.

Ok, just making sure.