WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
58503
Make more functions static local in EventHandlers.cpp
https://bugs.webkit.org/show_bug.cgi?id=58503
Summary
Make more functions static local in EventHandlers.cpp
Ryosuke Niwa
Reported
2011-04-13 18:47:15 PDT
Some functions in EventHandler.cpp do not need to be member functions. Since EventHandler is implemented in two files for each port, we should localize functions as much as possible to reduce the dependencies between the two.
Attachments
cleanup
(15.74 KB, patch)
2011-04-13 18:54 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
Fixed Windows build
(15.78 KB, patch)
2011-04-13 20:25 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
cleanup
(14.15 KB, patch)
2011-04-14 09:52 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
Fixed per comments
(13.57 KB, patch)
2011-05-01 13:47 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
Fixed a regression
(13.85 KB, patch)
2011-05-01 14:09 PDT
,
Ryosuke Niwa
eric
: review+
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2011-04-13 18:54:02 PDT
Created
attachment 89514
[details]
cleanup
Build Bot
Comment 2
2011-04-13 19:27:52 PDT
Attachment 89514
[details]
did not build on win: Build output:
http://queues.webkit.org/results/8404480
Ryosuke Niwa
Comment 3
2011-04-13 20:25:31 PDT
Created
attachment 89520
[details]
Fixed Windows build
Build Bot
Comment 4
2011-04-13 20:55:42 PDT
Attachment 89520
[details]
did not build on win: Build output:
http://queues.webkit.org/results/8400552
Ryosuke Niwa
Comment 5
2011-04-14 09:52:58 PDT
Created
attachment 89598
[details]
cleanup
Hajime Morrita
Comment 6
2011-04-14 15:38:32 PDT
Comment on
attachment 89598
[details]
cleanup View in context:
https://bugs.webkit.org/attachment.cgi?id=89598&action=review
> Source/WebCore/page/EventHandler.cpp:-1726 > - bool canHandle = false;
"accepted" should be always assigned. (as original did.)
> Source/WebCore/page/EventHandler.cpp:1822 > + bool accepted;
Always assigning the initial value is good idea in general, Especially the argument is not pointer At a glance, it is not clear if this code is correct because readers don't know "accept" is an output variable or not.
> Source/WebCore/page/EventHandler.cpp:2544 > + SelectionDirection direction = DirectionForward;
It might be possible to extract following switch statement into a conversion function like as focusDirectionForKey().
> Source/WebCore/page/EventHandler.cpp:2568 > +
This code always calls modify(), which looks different from original. Is it intentional?
Nate Chapin
Comment 7
2011-04-26 15:40:58 PDT
Comment on
attachment 89598
[details]
cleanup View in context:
https://bugs.webkit.org/attachment.cgi?id=89598&action=review
r- based mostly on the previous comments
> Source/WebCore/page/EventHandler.cpp:2519 > + DEFINE_STATIC_LOCAL(AtomicString, Down, ("Down")); > + DEFINE_STATIC_LOCAL(AtomicString, Up, ("Up")); > + DEFINE_STATIC_LOCAL(AtomicString, Left, ("Left")); > + DEFINE_STATIC_LOCAL(AtomicString, Right, ("Right"));
I know you're just moving this code, but these variable names should be lowercase. Also, is it worth putting these in a map?
Ryosuke Niwa
Comment 8
2011-04-26 19:56:04 PDT
(In reply to
comment #7
)
> Also, is it worth putting these in a map?
No.
Ryosuke Niwa
Comment 9
2011-05-01 12:29:34 PDT
Comment on
attachment 89598
[details]
cleanup View in context:
https://bugs.webkit.org/attachment.cgi?id=89598&action=review
>> Source/WebCore/page/EventHandler.cpp:1822
> > Always assigning the initial value is good idea in general, Especially the argument is not pointer > At a glance, it is not clear if this code is correct because readers don't know "accept" is an output variable or not.
Okay but compiler will give you a warning if I didn't initialize a variable and passed it into a function by value.
>> Source/WebCore/page/EventHandler.cpp:2568 >> + > > This code always calls modify(), which looks different from original. Is it intentional?
There's no behavioral change.
Ryosuke Niwa
Comment 10
2011-05-01 13:47:00 PDT
Created
attachment 91839
[details]
Fixed per comments
Ryosuke Niwa
Comment 11
2011-05-01 14:09:28 PDT
Created
attachment 91842
[details]
Fixed a regression
Eric Seidel (no email)
Comment 12
2011-05-01 14:41:41 PDT
Comment on
attachment 91842
[details]
Fixed a regression View in context:
https://bugs.webkit.org/attachment.cgi?id=91842&action=review
> Source/WebCore/page/EventHandler.cpp:1783 > + if (targetIsFrame(newTarget, targetFrame)) { > + if (targetFrame)
The case where targetIsFrame returns true and yet targetFrame is 0 seems odd. Do we test that case?
Ryosuke Niwa
Comment 13
2011-05-01 19:07:47 PDT
Comment on
attachment 91842
[details]
Fixed a regression View in context:
https://bugs.webkit.org/attachment.cgi?id=91842&action=review
>> Source/WebCore/page/EventHandler.cpp:1783 >> + if (targetFrame) > > The case where targetIsFrame returns true and yet targetFrame is 0 seems odd. Do we test that case?
How about when iframe doesn't have src attribute? I'm certain this will occur based on the code in HTMLFrameElementBase and the original code here.
Ryosuke Niwa
Comment 14
2011-05-02 12:45:48 PDT
(In reply to
comment #13
)
> How about when iframe doesn't have src attribute? I'm certain this will occur based on the code in HTMLFrameElementBase and the original code here.
This still creates the content frame. The only case I can think of is when a frame is in construction or destruction but it's extremely hard to test this.
Ryosuke Niwa
Comment 15
2011-05-02 13:08:50 PDT
Comment on
attachment 91842
[details]
Fixed a regression View in context:
https://bugs.webkit.org/attachment.cgi?id=91842&action=review
>>> Source/WebCore/page/EventHandler.cpp:1783 >>> + if (targetFrame) >> >> The case where targetIsFrame returns true and yet targetFrame is 0 seems odd. Do we test that case? > > How about when iframe doesn't have src attribute? I'm certain this will occur based on the code in HTMLFrameElementBase and the original code here.
editing/pasteboard/drag-drop-dead-frame.html crashes without this if statement.
Luiz Agostini
Comment 16
2011-05-02 16:56:36 PDT
Comment on
attachment 91842
[details]
Fixed a regression View in context:
https://bugs.webkit.org/attachment.cgi?id=91842&action=review
LGTM.
> Source/WebCore/ChangeLog:17 > + Removed canHandleDragAndDropForTarget and made focusDirectionForKey local to EventHandler.cpp. > + > + * page/EventHandler.cpp: > + (WebCore::targetIsFrame): Extracted from canHandleDragAndDropForTarget. > + (WebCore::EventHandler::updateDragAndDrop): Calls contentFrameForTarget instead of canHandleDragAndDropForTarget. > + (WebCore::EventHandler::cancelDragAndDrop): Ditto. > + (WebCore::EventHandler::performDragAndDrop): Ditto. > + (WebCore::focusDirectionForKey): No longer a member function of EventHandler class. > + (WebCore::EventHandler::handleKeyboardSelectionMovement): Calls focusDirectionForKey instead of manually comparing > + strings.
You did not mention in the change log that handleKeyboardSelectionMovement was made local to EventHandler.cpp and is no longer a member of class EventHandler.
Ryosuke Niwa
Comment 17
2011-05-02 16:58:45 PDT
(In reply to
comment #16
)
> (From update of
attachment 91842
[details]
) > You did not mention in the change log that handleKeyboardSelectionMovement was made local to EventHandler.cpp and is no longer a member of class EventHandler.
Oh, that's a good point. Will fix it before landing.
Luiz Agostini
Comment 18
2011-05-06 18:50:42 PDT
(In reply to
comment #17
)
> (In reply to
comment #16
) > > (From update of
attachment 91842
[details]
[details]) > > You did not mention in the change log that handleKeyboardSelectionMovement was made local to EventHandler.cpp and is no longer a member of class EventHandler. > > Oh, that's a good point. Will fix it before landing.
Well, I am not an official reviewer. I should have mentioned it in my last comment. I hope I have not disturbed too much. :)
Brent Fulgham
Comment 19
2011-05-31 20:23:25 PDT
Comment on
attachment 91842
[details]
Fixed a regression View in context:
https://bugs.webkit.org/attachment.cgi?id=91842&action=review
> Source/WebCore/page/EventHandler.cpp:1745 > +static bool targetIsFrame(Node* target, Frame*& frame)
What if 'targetIsFrame' returned a Frame*? Then the test for "isFrame" and null could be one and the same. Do we ever have a case where the target is NOT a frame, and yet we get a valid Frame*? Then calls like: if (targetIsFrame(newTarget, targetFrame)) if (targetFrame) { // ... do stuff ... Would become: Frame* frame = targetIsFrame(newTarget); if (frame) { // ... do stuff ...
Eric Seidel (no email)
Comment 20
2011-06-02 07:54:33 PDT
Comment on
attachment 91842
[details]
Fixed a regression Seems OK.
Ryosuke Niwa
Comment 21
2011-06-02 14:29:51 PDT
Committed
r87951
: <
http://trac.webkit.org/changeset/87951
>
Ryosuke Niwa
Comment 22
2011-06-02 14:41:07 PDT
Thanks for the review, landed after fixing the change log entry.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug