Closed
Bug 474081
Opened 16 years ago
Closed 16 years ago
Sporadic failures in browser_bug321000.js
Categories
(Firefox :: Search, defect)
Firefox
Search
Tracking
()
VERIFIED
FIXED
Firefox 3.6a1
Tracking | Status | |
---|---|---|
status1.9.1 | --- | .3-fixed |
People
(Reporter: dholbert, Assigned: mak)
References
()
Details
(Keywords: intermittent-failure, verified1.9.1)
Attachments
(5 files, 4 obsolete files)
2.35 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
3.30 KB,
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
1.25 KB,
patch
|
johnath
:
review+
|
Details | Diff | Splinter Review |
9.51 KB,
patch
|
Details | Diff | Splinter Review | |
2.28 KB,
patch
|
Details | Diff | Splinter Review |
The "Linux mozilla-1.9.1 unit test" tinderbox just failed this test:
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/base/content/test/browser_bug321000.js | urlbar strips newlines and surrounding whitespace - Got , expected hello helloworldworld
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/base/content/test/browser_bug321000.js | searchbar replaces newlines with spaces - Got , expected hello hello world world
I tend to think this is sporadic, because the previous cycle used the exact same code revision ( http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d9ff78dd3b4b ) and it passed these tests.
Log for failing cycle:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1232145380.1232150430.2394.gz
Log for previous passing cycle:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1232135621.1232141350.15538.gz
Assignee | ||
Comment 1•16 years ago
|
||
This test was constantly failing on my windows vm, with this patch it is always successful instead.
Attachment #358032 -
Flags: review?(gavin.sharp)
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Updated•16 years ago
|
Attachment #358032 -
Flags: review?(gavin.sharp) → review+
Comment 2•16 years ago
|
||
Is the reason for the sporadic failure known? Maybe it's exposing a bug that should be fixed instead or at least be filed separately?
Comment 3•16 years ago
|
||
Pasting is async in this case because the Ctrl+V codepath ends up going through DocumentViewerImpl::FireClipboardEvent[1], which just fires an event. I suppose we could avoid the need for these listeners if we called nsIEditor::paste() directly, since it appears to synchronously insert the text.
[1] http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDocumentViewer.cpp#2455
Assignee | ||
Comment 4•16 years ago
|
||
on IRC Gavin pointed out that using CTRL + V is testing more than simply using Paste on nsIEditor, so the patch is fine as it is.
Assignee | ||
Comment 5•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
Assignee | ||
Comment 6•16 years ago
|
||
Keywords: fixed1.9.1
Comment 7•16 years ago
|
||
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/base/content/test/browser_bug321000.js | Timed out
From http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1232711766.1232717461.3319.gz
:-/
Assignee | ||
Comment 8•16 years ago
|
||
mh, how can that timeout, we don't receive input event?
Assignee | ||
Comment 9•16 years ago
|
||
btw reopening :(
there must be an issue in setting the focus to the urlbar or pasting or firing the oninput event.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 10•16 years ago
|
||
locally when that happens the clipboard is correctly set, the locationbar has focus (cursor blinking), but the syntesizeKey event does not happen, if i ctrl+V manually the test finishes correctly.
Assignee | ||
Comment 11•16 years ago
|
||
looks like copyString is async, probably handled async by the OS, so it could happen that when we paste the clipboard has not yet been set. Indeed trying to getData from the clipboard immediately after setting it fails and success randomly.
Assignee | ||
Comment 12•16 years ago
|
||
as discussed on irc, this patch adds polling the clipboard, i put a limit of 5s that should be enough always (if that's not enough, we probably have some issue on clipboard implementation!)
Attachment #358536 -
Flags: review?(gavin.sharp)
Comment 13•16 years ago
|
||
I wonder why test_bug253481.xul doesn't have this problem...
Assignee | ||
Comment 14•16 years ago
|
||
heh, this is interesting enough, that test fails on my VM! while it works if use a setTimeout before checking results!
Assignee | ||
Comment 15•16 years ago
|
||
hwv could make sense take the polling patch on trunk and see if failures stop. if that's true we can fix that test too, to avoid possible future randomness.
Would be interesting to know the order in which tests run, would it be possible that the clipboard is never cleared so when we set in the browser test, the same string in clipboard is then used in that test?
Ideally they should clear the clipboard content or use different strings.
Comment 16•16 years ago
|
||
(In reply to comment #15)
> Would be interesting to know the order in which tests run, would it be possible
> that the clipboard is never cleared so when we set in the browser test, the
> same string in clipboard is then used in that test?
That's an interesting theory. The tests are using slightly different strings, but I don't think the new lines at the beginning and at the end make a real difference for test_bug253481.xul. The tests should probably use unique strings, or clear the clipboard afterwards, or do both.
Reporter | ||
Comment 17•16 years ago
|
||
Another timeout today:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1233096716.1233100133.5685.gz
Linux mozilla-1.9.1 unit test on 2009/01/27 14:51:56
Reporter | ||
Comment 18•16 years ago
|
||
And another...
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1233129221.1233134130.28322.gz
Linux mozilla-1.9.1 unit test on 2009/01/27 23:53:41
Removing "fixed1.9.1" keyword, as this is apparently still broken on 1.9.1 tinderboxen.
Keywords: fixed1.9.1
Assignee | ||
Comment 19•16 years ago
|
||
set the clipboard to an empty string before exiting, so we can check if other tests are depending on this.
Attachment #358536 -
Attachment is obsolete: true
Attachment #360524 -
Flags: review?(gavin.sharp)
Attachment #358536 -
Flags: review?(gavin.sharp)
Updated•16 years ago
|
Attachment #360524 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Comment 20•16 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/49c138f3b421
let bake this on trunk for some day, to see if the randomness has gone.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Comment 21•16 years ago
|
||
This test timed out today:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1234333287.1234337680.5516.gz#err13
(also noted in bug 473680 comment 19)
Assignee | ||
Comment 22•16 years ago
|
||
the timeout now looks like other not explainable timeouts, especially on Linux, it's not timing out where we expect it could... rather on startup, as if setTimeout would be never executed.
Comment 23•16 years ago
|
||
(In reply to comment #22)
Confirmed (still there):
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1235198229.1235205701.20963.gz
Linux mozilla-1.9.1 unit test on 2009/02/20 22:37:09
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1235206781.1235212335.3260.gz
Linux mozilla-1.9.1 unit test on 2009/02/21 00:59:41
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1235221181.1235225547.3968.gz
Linux mozilla-1.9.1 unit test on 2009/02/21 04:59:41
{
chrome://mochikit/content/browser/browser/base/content/test/browser_bug321000.js
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/base/content/test/browser_bug321000.js | Timed out
}
Flags: wanted-firefox3.1?
Comment 24•16 years ago
|
||
Still there on trunk too:
{
chrome://mochikit/content/browser/browser/base/content/test/browser_bug321000.js
NEXT ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/base/content/test/browser_bug321000.js | Timed out
}
Updated•16 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 25•16 years ago
|
||
Attachment #365181 -
Flags: review?(johnath)
Assignee | ||
Comment 26•16 years ago
|
||
Attachment #365181 -
Attachment is obsolete: true
Attachment #365182 -
Flags: review?(johnath)
Attachment #365181 -
Flags: review?(johnath)
Comment 27•16 years ago
|
||
Comment on attachment 365182 [details] [diff] [review]
disable as comment only
[Checkin: Comment 29 & 38]
thanks. I'm not a module peer, of course, but this looks safe, and removing an intermittent orange is winning.
Attachment #365182 -
Flags: review?(johnath) → review+
Comment 28•16 years ago
|
||
Comment on attachment 365182 [details] [diff] [review]
disable as comment only
[Checkin: Comment 29 & 38]
>+_BROWSER_FILES = browser_sanitize-timespans.js \
+_BROWSER_FILES = \
browser_sanitize-timespans.js \
Please...
Assignee | ||
Comment 29•16 years ago
|
||
sorry Serge, was pushed just minutes before your comment :\
http://hg.mozilla.org/mozilla-central/rev/b0738a6a17fa
Comment 30•16 years ago
|
||
(In reply to comment #29)
> sorry Serge
When reactivating the test, then.
Assignee | ||
Comment 31•16 years ago
|
||
the "Timed out" we were seeing in failures, could have been a real exception instead, and the same for many other tests we were seeing "Timed out".
Try running this browser-chrome test, the throw is never catched nor dumped anywhere, and we only end up seeing a "Timed out" in the error log.
So the timeout is hiding the real failure, that could be an API throwing or anything other throwing.
function test() {
waitForExplicitFinish();
function finish_test() {
throw("test");
finish();
}
setTimeout(finish_test,1);
}
Comment 32•16 years ago
|
||
This happened on the 191 branch as well:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1236138732.1236144606.30522.gz&fulltext=1
should we disable the test on that branch, too?
Assignee | ||
Comment 33•16 years ago
|
||
sure, we can disable the test on 3.1 too, will do when the tree reopens.
Then i'd like to enable a new version of it for a test on trunk, adding some try catch, to evaluate comment 31.
Comment 34•16 years ago
|
||
That's interesting. The exceptions just get swallowed? Do they get reported to the error console? I know Mossop was interested in making the harness fail if there were errors logged to the error console.
Assignee | ||
Comment 35•16 years ago
|
||
the error console reports: "Error: uncaught exception: test".
maybe there's no need to fail for every error (since i see a lot of other errors in the console from other tests), but failing for uncaught exceptions and reporting them in the log looks like something wanted.
Assignee | ||
Comment 36•16 years ago
|
||
i've filed bug 481406 to investigate if we can report console errors as real errors.
Comment 37•16 years ago
|
||
Happened again on mozilla-1.9.1:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.1/1236435465.1236439345.8158.gz
Can we get that disable-this-test thing landed on branch as well?
Blocks: 438871
Whiteboard: [orange]
Comment 38•16 years ago
|
||
Comment 39•16 years ago
|
||
Now that bug 481406 is fixed, shall this test be re-enabled on trunk to see what the current situation/log is?
Flags: wanted-firefox3.6?
Flags: wanted-firefox3.5?
Flags: in-testsuite+
Whiteboard: [orange] → [test is disabled] [orange]
Updated•16 years ago
|
Attachment #358032 -
Attachment description: patch v1.0 → patch v1.0
[Checkin: Comment 5 & 6]
Updated•16 years ago
|
Attachment #360524 -
Attachment description: poll clipboard v1.1 → poll clipboard v1.1
[Checkin: Comment 5]
Updated•16 years ago
|
Attachment #365182 -
Attachment description: disable as comment only → disable as comment only
[Checkin: Comment 29 & 38]
Updated•16 years ago
|
Attachment #360524 -
Attachment description: poll clipboard v1.1
[Checkin: Comment 5] → poll clipboard v1.1
[Checkin: Comment 20]
Assignee | ||
Comment 40•16 years ago
|
||
sure, i'll provide an updated patch for that.
Assignee | ||
Comment 41•16 years ago
|
||
re-enable test, i cleaned it up a bit so it should be easier to maintain, and added some logging.
With the new harness behavior could be easier to catch where we fail.
Attachment #387629 -
Flags: review?(dao)
Comment 42•16 years ago
|
||
Comment on attachment 387629 [details] [diff] [review]
patch v2.0
>+ { desc: "Urlbar strips newlines and surrounding whitespace"
>+ , element: document.getElementById('urlbar')
gURLBar? Also, comma at the beginning of the line looks strange.
>+var gListener = {
>+ test: null,
> handleEvent: function(event) {
>+ if (event.type != "input")
>+ return;
>+
That listener isn't added for other events, right? So if handleEvent gets called for other events, that would be a bug. I'd remove the event.type check and rename gListener to gInputListener.
Attachment #387629 -
Flags: review?(dao) → review+
Assignee | ||
Comment 43•16 years ago
|
||
(In reply to comment #42)
> comma at the beginning of the line looks strange.
it's just to avoid polluting blame when adding new properties in future
Assignee | ||
Comment 44•16 years ago
|
||
while renaming listener i noticed there's no more need to have it global, so i've moved it inside test_paste, so the only remaining global var is gTests.
Attachment #387629 -
Attachment is obsolete: true
Comment 45•16 years ago
|
||
I'd rather optimize for readability. Blame isn't all that interesting here.
Assignee | ||
Comment 46•16 years ago
|
||
not a big deal, moving commas around, ready to push.
Attachment #387638 -
Attachment is obsolete: true
Assignee | ||
Comment 47•16 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/d26cb9a07f91
i'm resolving bug, the first one seeing a failure on m-c should reopen this.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Whiteboard: [test is disabled] [orange] → [orange]
Assignee | ||
Comment 48•16 years ago
|
||
Assignee | ||
Comment 49•16 years ago
|
||
Flags: wanted-firefox3.6?
Keywords: fixed1.9.1
Updated•16 years ago
|
status1.9.1:
--- → .3-fixed
Updated•16 years ago
|
Attachment #387679 -
Attachment description: patch v2.2 → patch v2.2
[Checkin: Comment 47]
Updated•16 years ago
|
Attachment #392772 -
Attachment description: sync test on 1.9.1 → sync test on 1.9.1
[Checkin: Comment 49]
Comment 50•16 years ago
|
||
fixed1.9.1 is for the bug fixes which got in for 1.9.1 release, AFAIK. status1.9.1.3-fixed should be enough here.
Keywords: fixed1.9.1
Comment 51•16 years ago
|
||
No orangeness since 3 weeks on 1.9.1 and 1.9.2. Lets call it verified fixed.
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment 57•14 years ago
|
||
Please ignore comment 52 and below.
Assignee | ||
Comment 58•14 years ago
|
||
on the other side, reporting an orange in a bug verified fixed more than 1 year ago is arguably wrong, they should have opened a new bug.
Updated•12 years ago
|
Keywords: intermittent-failure
Updated•12 years ago
|
Whiteboard: [orange]
You need to log in
before you can comment on or make changes to this bug.
Description
•