Frequent "Awesomebar URL typed properly" failures when using enterUrl()

RESOLVED FIXED in Firefox 24

Status

()

defect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: bnicholson, Assigned: bnicholson)

Tracking

Trunk
Firefox 24
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

I've hit these failures on two different tests, neither of which are currently enabled: 
https://tbpl.mozilla.org/?tree=Try&rev=e3e21f2b2df2
https://tbpl.mozilla.org/?tree=Try&rev=4d171920dd00

Looking at the screenshots, the URL bar actually contains the expected text; Element#getText() is returning a previous value. I see the same thing when I run these tests locally -- the mochitest URL is fully entered, but getText() is still returning about:home.

I tried adding a waitForTest() before the assertion in enterUrl(), but this didn't help, so it doesn't appear to be a race condition. I also tried changing this mText [1] to be volatile since we're using the value in multiple threads, but that didn't help either.

I wonder if we need to send some kind of IME composition end/commit event after sending the string.

[1] http://mxr.mozilla.org/mozilla-central/source/build/mobile/robocop/FennecNativeElement.java.in#64
Blocks: 874985
Blocks: 813107
After some investigation, I found that normally, the activity returned by getActivityFromClick() == mSolo.getCurrentActivity(). When a failure occurs, however, they do not refer to the same activity. Strangely, even when the wrong activity is returned and a failure happens, the activity returned by getActivityFromClick() is still an instance of org.mozilla.gecko.AwesomeBar. So it appears that we are always getting an AwesomeBar instance, but for some reason, we're being given an old one when this happens.

The fix here is based on the assumption that although inst.waitForMonitor() is returning the wrong activity, it does at least block and wait for a new activity correctly. Returning mSolo.getCurrentActivity() appears to fix the problem, with hundreds of testThumbnail runs and no more mismatched URL failures: https://tbpl.mozilla.org/?tree=Try&rev=5d8ea688dcf0
Assignee: nobody → bnicholson
Status: NEW → ASSIGNED
Attachment #759383 - Flags: review?(gbrown)
Do you know the cause of the armv6 failure -- https://tbpl.mozilla.org/php/getParsedLog.php?id=23847282&tree=Try&full=1 ?

Have you tried running the full rc1/rc2 test suite against this change?
(In reply to Geoff Brown [:gbrown] from comment #2)
> Do you know the cause of the armv6 failure --
> https://tbpl.mozilla.org/php/getParsedLog.php?id=23847282&tree=Try&full=1 ?

Looks like an actual Fennec bug (commented on it in bug 813107).

> Have you tried running the full rc1/rc2 test suite against this change?

No, good idea. I'll do that now.
Argh, looks like the session restore tests need more work. Pushed again to try with those disabled: https://tbpl.mozilla.org/?tree=Try&rev=93992e5442e4
Comment on attachment 759383 [details] [diff] [review]
Use getCurrentActivity() in getActivityFromClick()

Review of attachment 759383 [details] [diff] [review]:
-----------------------------------------------------------------

Latest try run looks good to me.
Attachment #759383 - Flags: review?(gbrown) → review+
https://hg.mozilla.org/mozilla-central/rev/c0218a6cb1ed
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
See Also: → 819419
You need to log in before you can comment on or make changes to this bug.