Closed
Bug 512100
Opened 15 years ago
Closed 15 years ago
Fix dependency between "browser_keyevents_during_autoscrolling.js" and "browser_bug471962.js"
Categories
(Toolkit :: XUL Widgets, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: Paolo, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
The following browser-chrome tests in "toolkit/content" show different behavior
if they are run in a different order:
* "browser_bug471962.js" (bug 471962 and bug 486342)
* "browser_keyevents_during_autoscrolling.js" (bug 501608)
The two tests succeed if they are run in the order above.
At least on Windows XP, if I run "browser_keyevents_during_autoscrolling.js"
alone (passing a --test-path to run_tests.py), or before "browser_bug471962.js"
(that can be achieved by renaming the files), the former fails
deterministically.
If I run "browser_bug471962.js" after
"browser_keyevents_during_autoscrolling.js", the former fails too. If I run
"browser_bug471962.js" alone, it always succeeds.
Reporter | ||
Comment 1•15 years ago
|
||
I still can't work on this at present, but the following change found in
the as-yet-unlanded patch in bug 501608, attachment 391901 [details] [diff] [review], looks promising:
- // cleaning-up
- gBrowser.loadURI("about:blank");
+ // cleaning-up
+ gBrowser.addTab();
+ gBrowser.removeCurrentTab();
Maybe the final loadURI call starts an asynchronous load that ends while
the next test is running, causing it to fail if it attempts another load.
It's just an hypothesis, though.
This doesn't explain why the test fails if run alone, which can actually
be a different problem than the failure of the next test.
Updated•15 years ago
|
Version: unspecified → Trunk
Updated•15 years ago
|
Reporter | ||
Comment 2•15 years ago
|
||
Portions of Masayuki's patch from bug 501608, plus waiting for all the events
to be dispatched after the clean-up phase, seem to solve the interdependency
problem on my machine.
Attachment #396191 -
Flags: review?(enndeakin)
Updated•15 years ago
|
Comment 3•15 years ago
|
||
Paolo, is this still an issue?
Reporter | ||
Comment 4•15 years ago
|
||
(In reply to comment #3)
> Paolo, is this still an issue?
This is fixed by your changes, thanks!
Out of curiosity, can you explain why calling stop() on the newly opened
tab actually fixes the dependency issue?
In "browser_bug471962.js", I now moved the code that performs the clean-up
to a common location, so that tests that use the library don't need to worry
about the implementation details. Do you think you can review the patch on
bug 521831?
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 5•15 years ago
|
||
Comment on attachment 396191 [details] [diff] [review]
The patch
Previous comment seems to suggest this patch isn't needed any more.
Attachment #396191 -
Flags: review?(enndeakin)
You need to log in
before you can comment on or make changes to this bug.
Description
•