Bug 22358 - Add a test for "Copy" after showing a tooltip
Summary: Add a test for "Copy" after showing a tooltip
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Pam Greene (IRC:pamg)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-19 11:13 PST by Pam Greene (IRC:pamg)
Modified: 2008-12-01 12:48 PST (History)
0 users

See Also:


Attachments
New test + result (12.32 KB, patch)
2008-11-19 11:17 PST, Pam Greene (IRC:pamg)
no flags Details | Formatted Diff | Diff
Patch as committed, with shorter timeouts (12.32 KB, patch)
2008-12-01 12:47 PST, Pam Greene (IRC:pamg)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pam Greene (IRC:pamg) 2008-11-19 11:13:56 PST
This is a test for bug 18506: "Crash when Ctrl C (copy) is pressed after a series of specific mouse events".
Comment 1 Pam Greene (IRC:pamg) 2008-11-19 11:17:02 PST
Created attachment 25281 [details]
New test + result

This is the test created by Rahul in bug 18506 and described in more detail there.
Comment 2 Darin Adler 2008-11-19 11:29:07 PST
Comment on attachment 25281 [details]
New test + result

How long does this test take to run?

A test that intentionally takes multiple seconds to run is not compatible with the original WebKit regression test philosophy. Anything we can do to avoid having actual 1-second delays in the test would be worthwhile.

With 8000+ tests we really want them all to run as quickly as possible and avoid requiring any real time delays. For example, EventSender has a "leap time forward" feature that we've used in the past to avoid this for some tests.

I'm going to say review+, but I am quite concerned about making our tests take a long time to run, one test at a time.
Comment 3 Pam Greene (IRC:pamg) 2008-11-20 10:05:06 PST
(In reply to comment #2)
> I'm going to say review+, but I am quite concerned about making our tests take
> a long time to run, one test at a time.

I was also concerned about the timeouts, but Rahul's comment in bug 18506 that "making even any small
changes renders the test useless," combined with the fact that the bug was fixed back in April and is hard to test for failure now, made me wary of shortening them.  I've asked Rahul whether that was one of the things he tried specifically back then.
Comment 4 Pam Greene (IRC:pamg) 2008-11-20 15:53:28 PST
Comment on attachment 25281 [details]
New test + result

Removing Darin's r+ pending further investigation of the setTimeout() calls to speed this up.
Comment 5 Pam Greene (IRC:pamg) 2008-12-01 12:47:25 PST
Created attachment 25634 [details]
Patch as committed, with shorter timeouts

Reduced the timeouts to 400 and 200, respectively, from 1000 and 1000.  Thanks to Rahul for running tests and determining that these are the smallest numbers that still produce the crash on an unpatched version of Chromium.
Comment 6 Pam Greene (IRC:pamg) 2008-12-01 12:48:56 PST
Landed in r38863.