Closed Bug 900911 Opened 7 years ago Closed 7 years ago

Test failure 'Active tab url should equal the page url' in /testAwesomeBar/testSwitchToTab.js

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

defect
Not set

Tracking

(firefox22 unaffected, firefox23 unaffected, firefox24 unaffected, firefox25 fixed, firefox26 fixed, firefox-esr17 unaffected)

RESOLVED FIXED
Tracking Status
firefox22 --- unaffected
firefox23 --- unaffected
firefox24 --- unaffected
firefox25 --- fixed
firefox26 --- fixed
firefox-esr17 --- unaffected

People

(Reporter: andrei, Assigned: andrei)

Details

(Whiteboard: [mozmill-test-failure][mozmill-2.0])

Attachments

(2 files, 1 obsolete file)

7.36 KB, text/javascript
Details
1.17 KB, patch
AndreeaMatei
: review+
Details | Diff | Splinter Review
Test:      testSwitchToTab    
Failure:   Active tab url should equal the page url
Branches:  default
Platforms: All

Does not fail if test is run independently.
Either one of testCheckItemHighlight.js or testEscapeAutocomplete.js if run before the mentioned test make it fail.

Possible regression. Does not fail on older Nightly versions.
Working on a regression range now.

The failure also mentions a distorted test name:
> "message": "Active tab url should equal the page url", 
> "lineNumber": 82, 
> "name": "testSwitchToTab/</switchToTab<", 
> "fileName": "file:///Users/andrei.eftimie/work/mozilla/temp/mozmill-tests/tests/functional/testAwesomeBar/testSwitchToTab.js"
Something regressed in the Nightly build from 2013-06-28, which was build from: http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=8e3a124c9c1a

Looking into tinderbox builds to further narrow it down.
Responsible pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=8f7ef2198996

Responsible bug 791776

I'll make a simplified testcase before tagging Marko for more info.
Attached file testcase.js
Attached is a testcase.
This doesn't look like a genuine regression to me.

I'll have shortly a fix attached and explained.
Assignee: nobody → andrei.eftimie
Status: NEW → ASSIGNED
Attached patch 1.patch (obsolete) — Splinter Review
Now to explain the problem:
We are typing multiple strings in the urlbar, for each of them waiting for the switchToTab item to appear.
After we type something in we wait for the Autocomplete popup to 1) be open and 2) have a different number of items than 0.

The problem would arise at the next iteration.
Typing (or some parts of the update to the UI) are now async and no longer block, we still have the old Autocomplete results open. Our checks pass, and we click again on the previous link.

The fix is to simply clear the urlbar before doing any typing, the Autocomplete closes, and we start the second iteration fresh. (We could wait for a few ms before searching for the switchToTab item).
Attachment #785027 - Flags: review?(hskupin)
Attachment #785027 - Flags: review?(dave.hunt)
Comment on attachment 785027 [details] [diff] [review]
1.patch

Since this is a mozmill-tests issue, added Andreea as reviewer aswell.
Attachment #785027 - Flags: review?(andreea.matei)
Comment on attachment 785027 [details] [diff] [review]
1.patch

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

Please add a commit message to the patch.

::: tests/functional/testAwesomeBar/testSwitchToTab.js
@@ +43,5 @@
>    // Wait for 4 seconds to work around Firefox LAZY ADD of items to the DB
>    controller.sleep(PLACES_DB_TIMEOUT);
>  
>    TEST_DATA.forEach(function (aPage) {
> +    locationBar.clear();

Hm, interesting that this is only happening on 2.0. I'd look more into that. 
But it would make sense to have this change anyway, looks like an improvement of the code.
The thing is, clear() already focuses before actually clearing, so I would remove the line bellow.
Attachment #785027 - Flags: review?(hskupin)
Attachment #785027 - Flags: review?(dave.hunt)
Attachment #785027 - Flags: review?(andreea.matei)
Attachment #785027 - Flags: review-
[mozmill-2.0?] is an entry for the mozmill component only. It will not help when set for mozmill-tests. As of now I don't see what has to be fixed for Mozmill 2 here.
Whiteboard: [mozmill-test-failure][mozmill-2.0?] → [mozmill-test-failure]
This only fails under mozmill 2.0, hence the whiteboard entry.
Didn't thought it applied only to mozmill proper.

I'll look a bit more into this, since it still seems a bit strange.
Clearing the locationbar before each change does fix it, but it seems I am missing something.
Well, than lets indicate that. I thought you wanted to bring this up as blocker for 2.0.
Whiteboard: [mozmill-test-failure] → [mozmill-test-failure][mozmill-2.0]
Attached patch 2.patchSplinter Review
> The thing is, clear() already focuses before actually clearing, so I would
> remove the line bellow.
Thanks Andreea for noticing this.
Have removed the focus call now.

> Hm, interesting that this is only happening on 2.0. I'd look more into that. 
> But it would make sense to have this change anyway, looks like an improvement 
> of the code.
I am not sure what we do differently in Mozmill 1.5... I don't think it's worth 
much more time
This change does improve the stability of the test, and fixes the problem we see
in Mozmill 2.0

Here are testruns in 1.5:
http://mozmill-crowd.blargon7.com/#/functional/report/6d53b7d749a60e65551b4b1d19d61c86
http://mozmill-crowd.blargon7.com/#/functional/report/6d53b7d749a60e65551b4b1d19d7175c

Here is a testrun under 2.0:
http://mozmill-crowd.blargon7.com/#/functional/report/6d53b7d749a60e65551b4b1d19d574d1
(have bug 886811 applied)
Attachment #785027 - Attachment is obsolete: true
Attachment #796048 - Flags: review?(andreea.matei)
Comment on attachment 796048 [details] [diff] [review]
2.patch

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

Landed:
http://hg.mozilla.org/qa/mozmill-tests/rev/8290d510a1cc (default)

Are there any other branches affected here?
Attachment #796048 - Flags: review?(andreea.matei) → review+
Yes we should backport this.
Will run some tests and come back.
Only Aurora is affected.
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.