Closed Bug 1090618 Opened 11 years ago Closed 11 years ago

Intermittent testPictureLinkContextMenu | Checking if the text is correctly copied - The text was correctly copied

Categories

(Firefox for Android Graveyard :: Testing, defect)

Product:
Firefox for Android Graveyard
Component:
Testing
Platform:
All
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox34 unaffected, firefox35 unaffected, firefox36 fixed, firefox-esr31 unaffected)

Status:
RESOLVED FIXED
Milestone:
Firefox 36
Tracking Flags:
Tracking Status
firefox34 --- unaffected
firefox35 --- unaffected
firefox36 --- fixed
firefox-esr31 --- unaffected

People

(Reporter: KWierso, Assigned: mfinkle)

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

extend-clipboard-timeout v0.1
1.24 KB, patch
mcomella
: review+
Details | Diff | Splinter Review
Mike - Related to the latest set of changes you made?
Assignee: nobody → michael.l.comella
(In reply to Mark Finkle (:mfinkle) from comment #25) > Mike - Related to the latest set of changes you made? Did you have a specific changeset in mind? The mass StringHelper changes, maybe? Off the top of my head, I'm not sure what's going on here but I'll take a look.
Status: NEW → ASSIGNED
Ah, I see - I made the latest changes to the file [1] (10/10), but I believe these changes to be unrelated. [1]: https://hg.mozilla.org/mozilla-central/rev/9eb089d7c2b9
The problem line is [1]: verifyCopyOption(photoMenuItems[0], "Firefox.jpg"); // Test the "Copy Image Location" option where verifyCopyOption verifies the clipboard content. From the failure logs: 14:04:08 INFO - Clipboard text = foo.bar@example.com , expected text = Firefox.jpg "foo.bar@example.com" appears to be content from the clipboard from a previously run test, testMailToContextMenu. [1]: https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/tests/testPictureLinkContextMenu.java?rev=9eb089d7c2b9#27
Locally, it takes an unexpectedly long time for the clipboard to update (65 tests are run before the expected result is found). I'd expect updating the clipboard to be a synchronous operation, but maybe our code path is async (or Android's).
Surprise! It seems saving to the clipboard is is an asynchronous operation [1]! This would explain why the issue only seems to be present on emulators (and 2.3 at that). Expected fix: Increase the timeout from 10k seconds (but that sounds way too long already) gbrown: Has anything changed in the test infra recently that might cause the 2.3 emulators to be running more slowy? Perhaps just before this issue started on 10/28. [1]: https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/util/Clipboard.java?rev=8159fc66c700#63
Flags: needinfo?(gbrown)
(In reply to Michael Comella (:mcomella) from comment #50) > Surprise! It seems saving to the clipboard is is an asynchronous operation > [1]! This would explain why the issue only seems to be present on emulators > (and 2.3 at that). Good catch Mike!
I took a look at all uses of verifyCopyOption, which outputs "Clipboard text = " into the test logs. The emulator is slower than the real hardware, but not by much. That said, testPictureLinkContextMenu is by far the slowest clipboard test. Most are done in less than 2 secs, but this test is typically 4 to 6 secs. These intermittents are > 10 secs. (In reply to Michael Comella (:mcomella) from comment #50) > Expected fix: Increase the timeout from 10k seconds (but that sounds way too > long already) Not 10K seconds. 10K milliseconds. I am fine with bumping this one test to 20K milliseconds.
OK. I made it 30 seconds. It's a worst-case, so no tests should actually wait 30 seconds unless something is really screwed up. I am not eager to come back to bump this higher incrementally.
Assignee: michael.l.comella → mark.finkle
Attachment #8514783 - Flags: review?(michael.l.comella)
It's arguable that spinning the test to check the clipboard (getText) every 100ms is somehow choking the background thread, keeping the clipboard (setText) from doing it's job faster.
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=c5696b285583 One of the Android 2.3 RC2 runs took 10.9 seconds to complete the clipboard operation. This would have failed previously.
(In reply to Michael Comella (:mcomella) from comment #50) > gbrown: Has anything changed in the test infra recently that might cause the > 2.3 emulators to be running more slowy? Perhaps just before this issue > started on 10/28. I don't think so. I reviewed the history of config changes and don't see anything that might account for a 2.3 change.
Flags: needinfo?(gbrown)
Comment on attachment 8514783 [details] [diff] [review] extend-clipboard-timeout v0.1 Review of attachment 8514783 [details] [diff] [review]: ----------------------------------------------------------------- wfm. Don't forget to add a patch description. Note: waitForTest sleeps for 100 millis, while mSolo.waitForCondition waits for 500 millis - I imagine they have more experience on this front than us and that 500 is a more optimal time, so I filed bug 1092254 to just use that instead. If you want, we can wait for that to land and see if it might fix this intermittent so we're not forced to increase the failure wait times.
Attachment #8514783 - Flags: review?(michael.l.comella) → review+
https://hg.mozilla.org/mozilla-central/rev/78421574587d
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
FWIW, this test runs on Aurora as well and there have been zero non-trunk reports in this bug. Tells me that infra isn't at fault for whatever caused this to spike.
status-firefox34: --- → unaffected
status-firefox35: --- → unaffected
status-firefox36: --- → fixed
status-firefox-esr31: --- → unaffected
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: