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

RESOLVED FIXED in Firefox 24



6 years ago
6 years ago


(Reporter: bnicholson, Assigned: bnicholson)


Firefox 24
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)

I've hit these failures on two different tests, neither of which are currently enabled:

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.

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:
Assignee: nobody → bnicholson
Attachment #759383 - Flags: review?(gbrown)
Do you know the cause of the armv6 failure -- ?

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 --
> ?

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:
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+
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.