WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 35255
[Qt] DRT: Send double click event from EventSender
https://bugs.webkit.org/show_bug.cgi?id=35255
Summary
[Qt] DRT: Send double click event from EventSender
Diego Gonzalez
Reported
2010-02-22 12:16:30 PST
Make Qt DumpRenderTree EventSender able to send double click events LayoutTests: fast/events/dblclick-addEventListener.html
Attachments
Proposed patch
(4.27 KB, patch)
2010-02-22 12:33 PST
,
Diego Gonzalez
no flags
Details
Formatted Diff
Diff
Proposed patch
(5.76 KB, patch)
2010-02-23 13:13 PST
,
Diego Gonzalez
no flags
Details
Formatted Diff
Diff
Proposed patch
(6.46 KB, patch)
2010-02-24 06:10 PST
,
Diego Gonzalez
no flags
Details
Formatted Diff
Diff
Proposed patch
(6.36 KB, patch)
2010-02-24 07:20 PST
,
Diego Gonzalez
no flags
Details
Formatted Diff
Diff
Proposed patch
(6.36 KB, patch)
2010-02-24 07:30 PST
,
Diego Gonzalez
no flags
Details
Formatted Diff
Diff
Proposed patch
(6.11 KB, patch)
2010-03-02 11:34 PST
,
Diego Gonzalez
hausmann
: review-
Details
Formatted Diff
Diff
Proposed patch
(6.45 KB, patch)
2010-03-03 09:35 PST
,
Diego Gonzalez
no flags
Details
Formatted Diff
Diff
Show Obsolete
(6)
View All
Add attachment
proposed patch, testcase, etc.
Diego Gonzalez
Comment 1
2010-02-22 12:33:03 PST
Created
attachment 49233
[details]
Proposed patch
WebKit Review Bot
Comment 2
2010-02-22 12:35:28 PST
Attachment 49233
[details]
did not pass style-queue: Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1 WebKitTools/DumpRenderTree/qt/EventSenderQt.cpp:103: Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5] Total errors found: 1 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.
Diego Gonzalez
Comment 3
2010-02-23 13:13:34 PST
Created
attachment 49319
[details]
Proposed patch
Kenneth Rohde Christiansen
Comment 4
2010-02-23 13:28:43 PST
Comment on
attachment 49319
[details]
Proposed patch
> + // only consider a click to count, a event which was sent from the > + // same previous button and from the same position > + if (m_currentButton == button && m_mousePos == m_clickPos) > + m_clickCount++; > + else > + m_clickCount = 1;
Is time difference not supposed to be considered as well? Doesn't Qt already handle this?
> + QMouseEvent* event; > + if (m_clickCount == 2) { > + event = new QMouseEvent(QEvent::MouseButtonDblClick, m_mousePos, > + m_mousePos, mouseButton, m_mouseButtons, > + Qt::NoModifier); > + } else { > + event = new QMouseEvent(QEvent::MouseButtonPress, m_mousePos, > + m_mousePos, mouseButton, m_mouseButtons, > + Qt::NoModifier);
event = new QMouseEvent((m_clickCount == 2) ? QEvent::MouseButtonDblClick : QEvent::MouseButtonPress, m_mousePos, m_mousePos, mouseButton, m_mouseButtons, Qt::NoModifier); seems simpler
Diego Gonzalez
Comment 5
2010-02-23 13:35:48 PST
(In reply to
comment #4
)
> (From update of
attachment 49319
[details]
) > > > + // only consider a click to count, a event which was sent from the > > + // same previous button and from the same position > > + if (m_currentButton == button && m_mousePos == m_clickPos) > > + m_clickCount++; > > + else > > + m_clickCount = 1; > > Is time difference not supposed to be considered as well? Doesn't Qt already > handle this? > > > + QMouseEvent* event; > > + if (m_clickCount == 2) { > > + event = new QMouseEvent(QEvent::MouseButtonDblClick, m_mousePos, > > + m_mousePos, mouseButton, m_mouseButtons, > > + Qt::NoModifier); > > + } else { > > + event = new QMouseEvent(QEvent::MouseButtonPress, m_mousePos, > > + m_mousePos, mouseButton, m_mouseButtons, > > + Qt::NoModifier); > > event = new QMouseEvent((m_clickCount == 2) ? QEvent::MouseButtonDblClick : > QEvent::MouseButtonPress, > m_mousePos, m_mousePos, mouseButton, m_mouseButtons, > Qt::NoModifier); > > seems simpler
checking now about time considerations
Antonio Gomes
Comment 6
2010-02-23 13:49:10 PST
imho it is fragile aproach we to be considering all this variants ourselves. it would be much simpler if EventSender classes had a dlKeyDown method, instead of blowing our fragile EventSender::keyDown w/ counts and time checks. of course it'd be something to be done to other ports' drt , and be discussed in the webkit-dev mailing list first.
Diego Gonzalez
Comment 7
2010-02-24 06:10:26 PST
Created
attachment 49384
[details]
Proposed patch
WebKit Review Bot
Comment 8
2010-02-24 06:19:23 PST
Attachment 49384
[details]
did not build on qt: Build output:
http://webkit-commit-queue.appspot.com/results/304469
Diego Gonzalez
Comment 9
2010-02-24 07:20:51 PST
Created
attachment 49389
[details]
Proposed patch
Antonio Gomes
Comment 10
2010-02-24 07:25:16 PST
diego: + // only consider a click to count, a event which was sent from the + // same previous button and from the same position. Using 400ms as + // the double-click interval like in KDE default settings. * aN event * sent => originated by (?) * AT the same position ...
Diego Gonzalez
Comment 11
2010-02-24 07:30:53 PST
Created
attachment 49391
[details]
Proposed patch Correcting comments. Thanks tonikitoo
Antonio Gomes
Comment 12
2010-02-24 07:48:23 PST
just guessing: @diego: 1) it is possible to have 3 click situations, like to selection a whole paragraph. I do not know if we have layout tests for that, but would the patch work ? 2) if in the same test we have a single click event followed by a dl click event (or in the reverse order). would the patch work ? if answer is good for both question, i think it is robust enough :)
Diego Gonzalez
Comment 13
2010-02-24 07:59:56 PST
(In reply to
comment #12
)
> just guessing: > > @diego: > > 1) it is possible to have 3 click situations, like to selection a whole > paragraph. I do not know if we have layout tests for that, but would the patch > work ? >
Yes it's possible, just use the click counter to get the triple click and send the event. I did not find any layout test treating that.
> 2) if in the same test we have a single click event followed by a dl click > event (or in the reverse order). would the patch work ? >
I'm pretty sure it will work if a really single click be sent
> if answer is good for both question, i think it is robust enough :)
Diego Gonzalez
Comment 14
2010-03-02 11:34:08 PST
Created
attachment 49824
[details]
Proposed patch
Simon Hausmann
Comment 15
2010-03-03 06:32:37 PST
Comment on
attachment 49824
[details]
Proposed patch r- because the m_timer should be stopped and resetClickCount() should be const, as discussed on IRC. the rest looks good to me :)
Antonio Gomes
Comment 16
2010-03-03 08:56:16 PST
(In reply to
comment #15
)
> (From update of
attachment 49824
[details]
) > r- because the m_timer should be stopped and resetClickCount() should be const, > as discussed on IRC. the rest looks good to me :)
simon, I do not think resetClickCount should be 'const'. it is doing a assignmentt: + void resetClickCount() { m_clickCount = 0; } did i miss something ?
Diego Gonzalez
Comment 17
2010-03-03 09:35:57 PST
Created
attachment 49917
[details]
Proposed patch Make the m_clickTimer stops as Simon requests. I agree with tonikitoo, in this case the const in void resetClickCount() { m_clickCount = 0; } maybe is not applicable.
Simon Hausmann
Comment 18
2010-03-03 12:33:15 PST
(In reply to
comment #16
)
> (In reply to
comment #15
) > > (From update of
attachment 49824
[details]
[details]) > > r- because the m_timer should be stopped and resetClickCount() should be const, > > as discussed on IRC. the rest looks good to me :) > > simon, I do not think resetClickCount should be 'const'. it is doing a > assignmentt: > > + void resetClickCount() { m_clickCount = 0; } > > > did i miss something ?
You're right, I'm on crack :), there's no point in using const here. For a split second I thought it was an accessor.
Simon Hausmann
Comment 19
2010-03-03 12:36:41 PST
Comment on
attachment 49917
[details]
Proposed patch r+, but I realize an even simpler way of doing the timer is by not using a QObject timer at all but instead to simply use a cheap lightweight QTime object and instead of checking if the timer is active check if the elapsed() time since the start is less than the double click interval.
Diego Gonzalez
Comment 20
2010-03-03 12:50:45 PST
(In reply to
comment #19
)
> (From update of
attachment 49917
[details]
) > r+, but I realize an even simpler way of doing the timer is by not using a > QObject timer at all but instead to simply use a cheap lightweight QTime object > and instead of checking if the timer is active check if the elapsed() time > since the start is less than the double click interval.
Thanks, Simon. I used QTime in previous patches but the patch only will work for evironments with Qt > 4.6, for this I opted to use QBasicTimer. :)
Antonio Gomes
Comment 21
2010-03-04 09:46:28 PST
Comment on
attachment 49917
[details]
Proposed patch (In reply to
comment #20
)
> (In reply to
comment #19
) > > (From update of
attachment 49917
[details]
[details]) > > r+, but I realize an even simpler way of doing the timer is by not using a > > QObject timer at all but instead to simply use a cheap lightweight QTime object > > and instead of checking if the timer is active check if the elapsed() time > > since the start is less than the double click interval. > > Thanks, Simon. I used QTime in previous patches but the patch only will work > for evironments with Qt > 4.6, for this I opted to use QBasicTimer. :)
that is actually a problem , because EWS-Qt build bot still lives w/ qt4.5 . well, i'd prefer simon's approach, but ... cq+
WebKit Commit Bot
Comment 22
2010-03-04 11:30:48 PST
Comment on
attachment 49917
[details]
Proposed patch Clearing flags on attachment: 49917 Committed
r55541
: <
http://trac.webkit.org/changeset/55541
>
WebKit Commit Bot
Comment 23
2010-03-04 11:30:54 PST
All reviewed patches have been landed. Closing bug.
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