Closed Bug 418859 Opened 17 years ago Closed 7 years ago

synthesizeMouse() doesn't work with <input> textboxes and <input type='file'> (in mochitests)

Categories

(Testing :: Mochitest, defect)

Product:
Testing
Component:
Mochitest
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: smichaud, Unassigned)

Details

Attachments

(8 files, 4 obsolete files)

testcase5
(deleted), text/html
Details
testcase6
(deleted), text/html
Details
Simple *.html mochitest that illustrates the problem (variation A rev1)
(deleted), text/plain
Details
Simple *.html mochitest that illustrates the problem (variation B rev1)
(deleted), text/plain
Details
Simple *.html mochitest that illustrates the problem (variation C rev1)
(deleted), text/plain
Details
Simple *.xul mochitest that works fine (rev1)
(deleted), text/plain
Details
variation C rev1, rewritten as a standalone testcase
(deleted), text/html
Details
Mochitest test case
(deleted), text/html
Details
I can't get the synthesizeMouse() function (in EventUtils.js) to work properly with html <input> controls of type "text" (when writing a mochitest). Martijn has already reported one problem with synthesizeMouse() at bug 418745, but that's not the only problem. Even when I work around bug 418745, I can't ever get synthesizeMouse() to focus an <input> control of type "text" by synthesizing a click on it. synthesizeMouse() seems to work fine with a XUL textbox element, though. I will attach example mochitests that illustrate what I've just said.
Attached file Simple *.xul mochitest that works fine (obsolete) (deleted) —
Steven, in your first 3 mochitests you're calling testSwitchTabs which don't exist, but testTextboxClick exists or vice versa. Isn't that the problem you're seeing? (the "Simple *.xul mochitest that works fine" testcase doesn't seem to have that problem)
Attached file testcase5 (deleted) —
Ok, this is basically variation A without depending on mochikit. But it uses enhanced privileges, so you still need to download it to your computer to be able to test it. This shows 'false' where one would expect 'true' to appear.
Attached file testcase6 (deleted) —
Doing <body onload="setTimeout(testTextboxClick, 0)"> instead of <body onload="testTextboxClick()"> makes it show 'true'. So apparently, you need to do it with a timer to do this kind of stuff correctly.
And I can see the same problem with a xul document, so this isn't limited to html only. So my guess is that this is an event handling problem.
testcase5 is probably correct behaviour. One can't focus a textbox unless the window is also focused. As the window is not focused until after the load event, changing 'onload' to 'onfocus' will cause the test to work fine. This is probably the issue with the other tests as well.
Well, using the .focus() methode just works fine.
Ok, sorry, I guess I advised Steven wrongly to not use 'onfocus'. It all seems a bit fragile, though, it means that whenever the window becomes unfocused for some reason, the testcases would fail.
Here are my four testcases again, with the dumb mistakes fixed (hopefully) and onload= changed to onfocus=. Interestingly, I still get the same results with them. But I also get the results that Martijn reports with his testcase5 and testcase6. More on this in a later comment.
Attachment #304770 - Attachment is obsolete: true
Attachment #304773 - Attachment is obsolete: true
By the way, I find that my *.xul test (attachment 305013 [details]), though it works with onfocus="testTextboxClick();", works better with onfocus="setTimeout(testTextboxClick, 0);" In both cases the test passes. But only in the second case does the text-input cursor start blinking in the <textbox> element.
(In reply to comment #12) > Interestingly, I still get the same results with them. But I also get You mean they still don't work for you when using 'onfocus' instead of 'onload'?
Like I said above, I get the same results as Martijn with his testcase5 and testcase6. It's particularly strange that his testcase6 works while my Variation C fails. I notice that my Variation C (like all mochitests) rewrites the page above the <input> control to show its results, but Martijn's testcase6 rewrites the page below the <input> control. Could this be what makes the difference? > You mean they still don't work for you when using 'onfocus' instead of > 'onload'? Yes.
> I notice that my Variation C (like all mochitests) rewrites the page > above the <input> control to show its results, but Martijn's > testcase6 rewrites the page below the <input> control. Could this > be what makes the difference? On second thought I think it's more likely that there's a subtle problem with SimpleTest.finish() -- possibly a timing problem.
Or with SimpleTest.waitForExplicitFinish().
Attachment #305012 - Attachment mime type: text/html → text/plain
As far as I can tell, variation A rev1 and variation B rev1 still use the load event handler (addLoadEvent), which doesn't work as Neil explained in comment 9 (although I still find it strange that it shouldn't work, fwiw). variation C rev1 works fine for me (after rewriting it into a testcase that doesn't need MochiKit). What I noticed as a problem, with the onfocus event handler on the body, that when the focus is somewhere in chrome, the focus event handler isn't called on the body. I still find this relying on focus events to fire quite fragile.
(In reply to comment #21) > What I noticed as a problem, with the onfocus event handler on the body, that > when the focus is somewhere in chrome, the focus event handler isn't called on > the body. > I still find this relying on focus events to fire quite fragile. I filed bug 419061 for this.
> variation C rev1 works fine for me (after rewriting it into a > testcase that doesn't need MochiKit). What's wierd (to me) is that it works without MochiKit but doesn't work with MochiKit.
(In reply to comment #23) > > variation C rev1 works fine for me (after rewriting it into a > > testcase that doesn't need MochiKit). > > What's wierd (to me) is that it works without MochiKit but doesn't > work with MochiKit. Ah, I see. I guess that could happen, when one of the previous MochiKit testcases has moved focus to chrome, which means you would hit bug 419061. But this is just speculation, of course. Does the Mochikit testcase work when you only run that one MochiKit testcase, instead of the whole Mochikit testcase group?
> Does the Mochikit testcase work when you only run that one MochiKit > testcase, instead of the whole Mochikit testcase group? All my tests of my mochitest examples have been of those tests by themselves (using the --test-path=[testname] parameter of runtests.pl). I've never run them with other mochitests.
To be more explicit, I always ran each test by itself.
Component: Testing → Mochitest
Product: Core → Testing
QA Contact: testing → mochitest
Version: Trunk → unspecified
Attached file Mochitest test case (deleted) —
I got the exact same issue. I wrote a mochitest which should pass IMO but doesn't.
Btw, synthesizeMouse doesn't work for clicking on a input type form control. I had to simulate a SPACE key to have a file picker showing in bug 377624.
Summary: synthesizeMouse() doesn't work with <input> textboxes (in mochitests) → synthesizeMouse() doesn't work with <input> textboxes and <input type='file'> (in mochitests)
CC'ing people who may be interested by this issue.
It would be interesting if someone could debug this by putting a breakpoint here <http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#228> and working down the call stack from there to see what's happening. I don't have the cycles to do that right now. Mounir, do you think that's the sort of thing you might be interested to work on?
(In reply to comment #30) > It would be interesting if someone could debug this by putting a breakpoint > here > <http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#228> > and working down the call stack from there to see what's happening. I don't > have the cycles to do that right now. Mounir, do you think that's the sort of > thing you might be interested to work on? I've not so much cycles to dedicate to this bug too. However, I would like to see this fixed so I may want to look at that if I want to change my mind from my current work. If someone wants to work on this, feel free to take the bug.
FWIW, this test seems to be simulating a click on a file control: <http://mxr.mozilla.org/mozilla-central/source/layout/forms/test/bug536567_subframe.html?force=1#65>
Mass closing mochitest bugs that haven't had activity in the past 5 years. Please re-open or file a new bug with modern context if this is still relevant.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: