1043923 - Test failure 'controller.waitForPageLoad(URI=about:newtab, readyState=complete)' in /testAwesomeBar/testVisibleItemsMax.js

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: Mozmill Tests, defect, P1)

Description

[Andrei Eftimie]

Module:    testVisibleItemsMax
Test:      /testAwesomeBar/testVisibleItemsMax.js    
Failure:   controller.waitForPageLoad(URI=about:newtab, readyState=complete)
Branches:  default
Platforms: All
Report:    http://mozmill-daily.blargon7.com/#/functional/report/4c400675e8fe3ac64bc7502e7636155a

Fails across platforms.
I'll have a skip patch shortly.

I can reproduce it locally. Does not fail if the test is run individually.
Need to run a testrun.

MC pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a91ec42d6a9c&tochange=613e79262240

Comment 1

[Andrei Eftimie]

Attachment: skip.patch

Comment 2

[Andreea Matei [:AndreeaMatei]]

Comment on attachment 8462537 [details] [diff] [review]
skip.patch

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

http://hg.mozilla.org/qa/mozmill-tests/rev/0cf430138cc0 (default)

Comment 3

[Andrei Eftimie]

Pushlog: https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=362b6f577380&tochange=8bb77d17d0ee
Regressor: bug 1040335

This only enabled the unified autocomplete toolbar.
> browser.urlbar.unifiedcomplete

I'll dissect the failure now, maybe prepare a testcase.

Comment 4

[Andrei Eftimie]

Attachment: testcase.js

Testcase attached. Seems there's a race condition.
Once we switch to a tab, if we type to fast and press enter the urlbar does not acknowledge our input at all. This is weird.

There's a commented sleep call in line 37.
With that 100ms sleep everything works fine.
This is weird because the sleep is between typing a new url and hitting enter.

I'll need to debug further to understand why this is failing.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Andrei, do you have any news here? Maybe Marco can help us? I don't see that he has been cc'ed to this bug.

Comment 6

[Andrei Eftimie]

Attachment: async_title_loading.mov

I found out _why_ this is failing.

Steps (from the testcase):
1. We open a tab, load a page
2. Open a new tab, type in "grants" (this is included in the url from step 1)
3. Click on the "Switch to tab" item from the Autocomplete List
4. After the switch we try typing in something
5. The LocationBar value is getting updated with the original url, overwriting anything we wrote.

Attached is a screencast showcasing the behaviour (this is the second screencast I've done in years, so I'm not sure if a quicktime .mov file is any good for other platforms, used the system default to record on OSX, if anyone needs it converted please let me know and I'll do my best).

The issue is visible between the seconds 11-13.

==

There's no way to reproduce this manually as 100ms seems a strong threshold that makes the testcase pass every time.

Marco, in lieu of the new Unified Autocomplete that's been preffed on in bug 1040335, is this behaviour expected?

If so, are there other particular cases where we might expect the LocationBar to async load the URL? And are there any observers we might want to listen to?

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

This is really strange, we are switching to an existing tab, not loading it... I wonder if

assert.waitFor(() => controller.tabs.activeTab.location.href === "http://mozqa.com/data/firefox/layout/mozilla_grants.html",

is continuing too early, so if unified is filing in the url in the original tab before the switch to tab happens, then you type before switch to tab has finished doing its job. maybe before we were not setting the value to the urlbar so you were properly expecting the switch operation to complete.
This is just a theory though. what makes me think may be the case, is the fact the switch operation is handled by the browser not by autocomplete.

The other fact that might be related is we use promises/Task and those run on the next tick.

does the test pass if you wait just one tick instead of 100ms?

Comment 8

[Andrei Eftimie]

(In reply to Marco Bonardo [:mak] (Away 15-31 Aug) from comment #7)
> This is really strange, we are switching to an existing tab, not loading
> it... I wonder if
> 
> assert.waitFor(() => controller.tabs.activeTab.location.href ===
> "http://mozqa.com/data/firefox/layout/mozilla_grants.html",
> 
> is continuing too early, so if unified is filing in the url in the original
> tab before the switch to tab happens, then you type before switch to tab has
> finished doing its job. maybe before we were not setting the value to the
> urlbar so you were properly expecting the switch operation to complete.
> This is just a theory though. what makes me think may be the case, is the
> fact the switch operation is handled by the browser not by autocomplete.

I've been issuing some dumps, here's the interesting cross-section:
(for each row we have: active tab index, controller.tabs.activeTab.location.href, urlbar.value)

> == 2) active tab: 2 : http://mozqa.com/data/firefox/layout/mozilla_grants.html - mozqa.com/data/firefox/layout/mozilla_grants.html
Here we open a new tab, type in "grants"
> == 3) active tab: 3 : about:newtab -
> == 4) active tab: 3 : about:newtab -
> == 5) active tab: 3
We now click on "switch to tab":
> == 6) active tab: 2 : http://mozqa.com/data/firefox/layout/mozilla_grants.html - mozqa.com/data/firefox/layout/mozilla_grants.html
> == 7) active tab: 2 : http://mozqa.com/data/firefox/layout/mozilla_grants.html - mozqa.com/data/firefox/layout/mozilla_grants.html
> == 8) active tab: 2 : http://mozqa.com/data/firefox/layout/mozilla_grants.html - mozqa.com/data/firefox/layout/mozilla_grants.html
> == 9) active tab: 2 : http://mozqa.com/data/firefox/layout/mozilla_grants.html - mozqa.com/data/firefox/layout/mozilla_grants.html
Exactly here we type the new url:
> == 10) active tab: 2 : http://mozqa.com/data/firefox/layout/mozilla_grants.html - http://mozqa.com/data/firefox/layout/mozilla.html
We hit Enter:
> == 11) active tab: 2 : http://mozqa.com/data/firefox/layout/mozilla_grants.html - mozqa.com/data/firefox/layout/mozilla_grants.html
> == 12) active tab: 2 : http://mozqa.com/data/firefox/layout/mozilla_grants.html - mozqa.com/data/firefox/layout/mozilla_grants.html

So the activeTab is switched right away when we "Switch to tab", it still has the original URL loaded, but after some time the url gets updated and whatever value we type in between these 2 points gets overwritten.

Comment 9

[Andrei Eftimie]

Seems this issue was fixed with the build from 15th August.
Pushlog for fix on mc: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5299864050ee&tochange=c9f8cc9ce89c

Comment 10

[Andrei Eftimie]

Fix came in from fx-team: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=31db71673c6e&tochange=9eb591a1a203

Where the fix for bug 1051830 came in, which is possible also fixed this issue.

Comment 11

[Andrei Eftimie]

Confirmed: landing of bug 1051830 did also made this test pass.
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=938003717a25&tochange=2ccc5c9a58fa

Comment 12

[Andrei Eftimie]

Attachment: unskip.patch

Seems the disable line got duplicate somewhere, so a straight backout doesn't work.

Comment 13

[Andrei Eftimie]

Both OSX and Windows are green with this patch.

Comment 14

[Andreea Matei [:AndreeaMatei]]

Comment on attachment 8477366 [details] [diff] [review]
unskip.patch

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

Updated the commit message and pushed:
http://hg.mozilla.org/qa/mozmill-tests/rev/03dd84d656d3 (default)