Closed Bug 474081 Opened 16 years ago Closed 16 years ago

Sporadic failures in browser_bug321000.js

Categories

(Firefox :: Search, defect)

defect
Not set
normal

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)

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
This test was constantly failing on my windows vm, with this patch it is always successful instead.
Attachment #358032 - Flags: review?(gavin.sharp)
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Attachment #358032 - Flags: review?(gavin.sharp) → review+
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?
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
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.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
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 :-/
mh, how can that timeout, we don't receive input event?
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 → ---
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.
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.
Attached patch poll clipboard v1.0 (obsolete) — Splinter Review
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)
I wonder why test_bug253481.xul doesn't have this problem...
heh, this is interesting enough, that test fails on my VM! while it works if use a setTimeout before checking results!
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.
(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.
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
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
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)
Attachment #360524 - Flags: review?(gavin.sharp) → review+
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 ago16 years ago
Resolution: --- → FIXED
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.
(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?
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 }
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch temporary disable the test (obsolete) — Splinter Review
Attachment #365181 - Flags: review?(johnath)
Attachment #365181 - Attachment is obsolete: true
Attachment #365182 - Flags: review?(johnath)
Attachment #365181 - Flags: review?(johnath)
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 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...
sorry Serge, was pushed just minutes before your comment :\ http://hg.mozilla.org/mozilla-central/rev/b0738a6a17fa
(In reply to comment #29) > sorry Serge When reactivating the test, then.
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); }
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?
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.
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.
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.
i've filed bug 481406 to investigate if we can report console errors as real errors.
Depends on: 481406
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]
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]
Attachment #358032 - Attachment description: patch v1.0 → patch v1.0 [Checkin: Comment 5 & 6]
Attachment #360524 - Attachment description: poll clipboard v1.1 → poll clipboard v1.1 [Checkin: Comment 5]
Attachment #365182 - Attachment description: disable as comment only → disable as comment only [Checkin: Comment 29 & 38]
Attachment #360524 - Attachment description: poll clipboard v1.1 [Checkin: Comment 5] → poll clipboard v1.1 [Checkin: Comment 20]
sure, i'll provide an updated patch for that.
Attached patch patch v2.0 (obsolete) — Splinter Review
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 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+
(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
Attached patch patch v2.1 (obsolete) — Splinter Review
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
I'd rather optimize for readability. Blame isn't all that interesting here.
not a big deal, moving commas around, ready to push.
Attachment #387638 - Attachment is obsolete: true
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 ago16 years ago
Resolution: --- → FIXED
Whiteboard: [test is disabled] [orange] → [orange]
Attachment #387679 - Attachment description: patch v2.2 → patch v2.2 [Checkin: Comment 47]
Attachment #392772 - Attachment description: sync test on 1.9.1 → sync test on 1.9.1 [Checkin: Comment 49]
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
No orangeness since 3 weeks on 1.9.1 and 1.9.2. Lets call it verified fixed.
Status: RESOLVED → VERIFIED
Keywords: verified1.9.1
OS: Linux → All
Hardware: x86 → All
Please ignore comment 52 and below.
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.
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: