Opened 10 years ago

Closed 10 years ago

#9480 closed defect (fixed)

DOH robot broken on safari 4 production

Reported by: bill Owned by: haysmark
Priority: high Milestone: 1.4
Component: TestFramework Version: 1.3.0
Keywords: Cc: Adam Peller
Blocked By: Blocking:

Description

If I run tests like Tree_a11y.html or editor's new BackForwardState.html on safari 4 / mac, nothing appears on the screen, although in the console I can see that something is going on (ie, the Tree is initializing).

If I run BackForwardState.html on safari 4 / PC, it keeps running endlessly, switching between the two HTML pages that are part of the test.

Attachments (8)

wrapper.html (1.1 KB) - added by haysmark 10 years ago.
Safari bug.
DOHRobot.jar (42.3 KB) - added by haysmark 10 years ago.
Robot jar.
9480.patch (16.1 KB) - added by haysmark 10 years ago.
Fixes #9480. Support for Safari 4 and Chrome 2.
9480_132.patch (26.3 KB) - added by haysmark 10 years ago.
Patch against 1.3.2.
DOHRobot.2.jar (42.3 KB) - added by haysmark 10 years ago.
1.3.2. robot jar.
9480.2.patch (566 bytes) - added by haysmark 10 years ago.
Fixes #9480. Fix typeKeys default duration.
9480.3.patch (675 bytes) - added by haysmark 10 years ago.
Fixes #9480. Fix typeKeys default duration and handles the case when the argument is a keyCode.
DateTextBox.html (1.8 KB) - added by bill 10 years ago.
simplified dijit/tests/form/robot/DateTextBox.html. On second run on FF3.5/mac the drop down seems hidden by a transparent overlay preventing mouseover and mouseclick events

Download all attachments as: .zip

Change History (27)

Changed 10 years ago by haysmark

Attachment: wrapper.html added

Safari bug.

comment:1 Changed 10 years ago by haysmark

Well it seems like there are two tickets here. I will look into the tests not firing but I know for a fact I have successfully run a test on Safari 4/Mac.

For your other ticket, I attached a test case I want you to try out in Safari. Put it in dijit/tests/editor

In the test, there is some text you can click that tracks the number of times you clicked it. Click it a few times. There is also a frame pointing to the backforward test. Click the link as usual then click the back link after the helper page loads.

I found that the counter outside the frame reset to 0, as if Safari is refreshing the entire page. You don't see this behavior in Firefox by comparison. I'm not sure what you want me to do about it . . .

comment:2 Changed 10 years ago by haysmark

Milestone: tbd1.3.2

comment:3 Changed 10 years ago by Douglas Hays

Chrome will need a refreshed patch to work.

Changed 10 years ago by haysmark

Attachment: DOHRobot.jar added

Robot jar.

Changed 10 years ago by haysmark

Attachment: 9480.patch added

Fixes #9480. Support for Safari 4 and Chrome 2.

Changed 10 years ago by haysmark

Attachment: 9480_132.patch added

Patch against 1.3.2.

Changed 10 years ago by haysmark

Attachment: DOHRobot.2.jar added

1.3.2. robot jar.

comment:4 Changed 10 years ago by haysmark

Attached fix for trunk and 1.3.2. Fix was for some unthreaded calls hanging and for the security manager.

comment:5 Changed 10 years ago by Douglas Hays

(In [18737]) References #9480. Proxy commit for haysmark. Adds Safari 4 and Chrome 2 support to the robot (trunk).

comment:6 Changed 10 years ago by Douglas Hays

Resolution: fixed
Status: newclosed

(In [18738]) Fixes #9480. Proxy commit for haysmark. Adds Safari 4 and Chrome 2 support to the robot (1.3.2).

comment:7 Changed 10 years ago by bill

Thanks, Safari 4 is working now. Chrome still isn't working for me, but as that's a separate issue I filed a separate ticket, #9526.

Also, either this ticket should be marked as milestone=1.4 or the fix should be checked into the branch.

comment:8 Changed 10 years ago by bill

Resolution: fixed
Status: closedreopened

Ignore my comment above, I see that you checked this into the 1.3.2 branch already (although maybe you shouldn't have).

Starting with [18737] dijit/tests/form/robot/DateTextBox is getting errors. (I'm testing on FF3.5/mac.) Not sure where the issue is but this since it started w/this checkin, reopening this ticket.

GROUP "direct input" has 1 test to run
american keydown
american keydown
onchange w/value: undefined
_AssertFailure: http://localhost/trunk/dojo/_base/_loader/bootstrap.js:563 doh._AssertFailure: assertEqual() failed: expected 0 but got -1 with hint: value
[ Error: assertEqual() failed: expected 0 but got -1 with hint: value ]
ERROR IN: (function () {var d = new (doh.Deferred);doh.robot.sequence(function () {american.focus();}, 500);doh.robot.typeKeys("1/3/2005", 500);doh.robot.keyPress(dojo.keys.TAB, 100, {});doh.robot.sequence(d.getTestCallback(dojo.hitch(this, function () {doh.is(0, dojo.date.compare(new Date(2005, 0, 3), american.attr("value")), "value");doh.is(1, changes.length, "one onchange event");doh.is(0, dojo.date.compare(new Date(2005, 0, 3), changes[0]), "value reported by onchange: " + changes[0] + ", should be " + new Date(2005, 0, 3));})), 1000);return d;})
Total time for GROUP " direct input " is 0 ms
FAILED test: direct input 0 ms

comment:9 Changed 10 years ago by bill

PS: run the tests against dijit [18725]... starting with [18748] dijit also has changes which are breaking the test.

comment:10 Changed 10 years ago by haysmark

Well it would help if you shared what you saw, on my mac I noticed that the keys were randomly sticking, almost as if it were doing typematic. The robot log indicates it was receiving the events from the JS in the correct order and also pressing the right number of keys, so it remains to be seen whether FF is indeed generating typematic keystrokes. Also, peller updated the robot test so you can update to the latest version.

comment:11 Changed 10 years ago by bill

Cc: Adam Peller added

The code in question is:

doh.robot.typeKeys('1/3/2005', 500);
doh.robot.keyPress(dojo.keys.TAB, 500, {});
}}

On my machine it's just typing "1" into the <input> field and then tabbing away.  I was thinking that it was a timing problem and that we needed to give more delay between the typeKeys and keyPress, especially since !DateTextBox is busy popping up the calendar icon and display "invalid date messages"  (I'm not sure why the invalid message is popping up before tabbing away, that seems like another bug).    But anyway, increasing the delays doesn't seem to help.

There's also another issue that if you run the test twice w/out shutting down the browser, more errors occur, but let's deal w/one problem at a time.

comment:12 Changed 10 years ago by bill

Woops, that didn't get formatted right, let me try again. The code in question is:

doh.robot.typeKeys('1/3/2005', 500);
doh.robot.keyPress(dojo.keys.TAB, 500, {});

On my machine it's just typing "1" into the <input> field and then tabbing away. I was thinking that it was a timing problem and that we needed to give more delay between the typeKeys and keyPress, especially since DateTextBox is busy popping up the calendar icon and display "invalid date messages" (I'm not sure why the invalid message is popping up before tabbing away, that seems like another bug). But anyway, increasing the delays doesn't seem to help.

There's also another issue that if you run the test twice w/out shutting down the browser, more errors occur, but let's deal w/one problem at a time.

comment:13 Changed 10 years ago by haysmark

Bill, [19023] adds a third param to that typeKeys code you list, I noticed this fixed the test for me, does it fix it for you as well?

It looks like the default duration for typeKeys is 0. Clearly the default duration should be non-zero since the OS can't type that fast. How about length of string*50ms?

Changed 10 years ago by haysmark

Attachment: 9480.2.patch added

Fixes #9480. Fix typeKeys default duration.

comment:14 Changed 10 years ago by haysmark

I attached my fix.

Changed 10 years ago by haysmark

Attachment: 9480.3.patch added

Fixes #9480. Fix typeKeys default duration and handles the case when the argument is a keyCode.

comment:15 Changed 10 years ago by haysmark

I looked at the FF3.5 on mac refresh bug, the behavior I observed was that the first keydown was taking too long and so repeated itself. I think the reason you only see this on refresh is because on the first run the robot types keys as part of init where as on refresh it does not.

comment:16 Changed 10 years ago by bill

[19023] fixed the test for me too (on the first run).

About the FF3.5/mac refresh bug, I think we are seeing different problems. I'll attach a simplified DateTextBox?.html that reproduces it (for me).

It seems like on the second run there's some transparent pane over the page... hovering over the arrow icon (in the displayed date drop down) doesn't change the cursor to the hand cursor, and after pressing firebug's "click an element in the page to inspect", no matter where I put the cursor it just blue-outlines a line in the upper left hand side of the screen (perhaps the iframe holding the robot itself).

Changed 10 years ago by bill

Attachment: DateTextBox.html added

simplified dijit/tests/form/robot/DateTextBox.html. On second run on FF3.5/mac the drop down seems hidden by a transparent overlay preventing mouseover and mouseclick events

comment:17 Changed 10 years ago by bill

(In [19081]) Make default duration for typeKeys() == 50ms * # of chars, rather than 0ms (0ms effectively tries to press all the keys at the same time).

Avoids problems w/dropped characters on FF/mac and perhaps other browsers/environments too.

Patch from Mark Hays (IBM, CCLA). Refs #9480.

comment:18 Changed 10 years ago by bill

Milestone: 1.3.21.4

comment:19 Changed 10 years ago by haysmark

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.