Bug 7583 - DRT hangs when doing eventSender.mouseDown on native widgets
Summary: DRT hangs when doing eventSender.mouseDown on native widgets
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-03 17:18 PST by Justin Garcia
Modified: 2006-03-09 08:36 PST (History)
1 user (show)

See Also:


Attachments
test that hangs (1.20 KB, text/plain)
2006-03-03 17:19 PST, Justin Garcia
no flags Details
Reduction (306 bytes, text/html)
2006-03-04 01:46 PST, mitz
no flags Details
Add eventSender.click() for native widgets (5.38 KB, patch)
2006-03-08 09:41 PST, mitz
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Garcia 2006-03-03 17:18:59 PST
Attaching a test that hangs
Comment 1 Justin Garcia 2006-03-03 17:19:39 PST
Created attachment 6835 [details]
test that hangs
Comment 2 Justin Garcia 2006-03-03 17:20:35 PST
<rdar://problem/4454360> layout tests that use eventSender hang
Comment 3 mitz 2006-03-04 01:46:10 PST
Created attachment 6838 [details]
Reduction

The problem here is that when you mousedown in a native widget (in this case a text field), it enters its own mouse-tracking runloop until the mouse is released. (The reason this doesn't happen with the first mousedown in the first attachment is that the onfocus handler fires first; you will probably want to call test() only once, either as onfocus handler or from step1, and also add a mouseup between the two mousedowns, if you can get around this bug).
Comment 4 Justin Garcia 2006-03-06 11:46:29 PST
Vicki handed this testcase off to me, and I hadn't even looked at it when I brought it over to radar.  She wanted to create a testcase for the fix for 7363.  The fact that there is a mouseDown with no mouseUp just looks like a mistake, and not something that is necessary to test her fix.  I'm closing this bug.
Comment 5 mitz 2006-03-06 11:56:04 PST
(In reply to comment #4)
In case it wasn't clear from my previous comment, the missing mouseUp is not what's making the test hang. I think it might be possible to test the fix without mouse events by calling focus() on the text fields.
Comment 6 Justin Garcia 2006-03-06 13:17:13 PST
(In reply to comment #3)
> The problem here is that when you mousedown in a native widget (in this case a
> text field), it enters its own mouse-tracking runloop until the mouse is
> released. 

I thought that this meant that we would just need to send a mouseUp event.  Sending a mouseUp has no effect.  I'm reopening.

> I think it might be possible to test the fix without mouse events by calling 
> focus() on the text fields.

I agree, I wrote two testcases for Vicki's fix for 7363 and I'll check them in once she reviews them.
Comment 7 Justin Garcia 2006-03-07 22:01:12 PST
This is b/c JS is suspended while the mouse is down over native widgets.  Mitz's idea is to add a click method to eventSender.  I'm going to let him work on this.
Comment 8 mitz 2006-03-08 09:41:25 PST
Created attachment 6943 [details]
Add eventSender.click() for native widgets

This implementation of click should only be used with native widgets. Implementing a second "convenience" code path that simply does a mouseDown followed by a mouseUp requires [WebHTMLView _hitViewForEvent:], which is internal.
Comment 9 Darin Adler 2006-03-09 07:42:36 PST
Comment on attachment 6943 [details]
Add eventSender.click() for native widgets

OK, r=me