1015126 - Test Failure "controller.waitForPageLoad(): A page load has been detected" due to missing home button on the navigation toolbar

Status: RESOLVED INVALID

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

Description

[Daniel Gherasim]

We've seen this failure:
controller.waitForPageLoad(URI=http://localhost:43336/search/opensearch.html, readyState=complete) on a mac osx 10.7 node with the latest Nightly.

Failed 4 times in a testrun in this tests:

testSearch/testSearchViaFocus.js
testSearch/testSearchViaShortcut.js
testSearch/testOpenSearchAutodiscovery.js
testSearch/testAddMozSearchProvider.js

Report:
http://mozmill-
daily.blargon7.com/#/functional/report/7a69d3e8424ecf8642bb6566e4fed8d2

Comment 1

[Daniel Gherasim]

Another failure with readyState = complete in testSecurity/testSecurityInfoViaMoreInformation.js.
http://mozmill-daily.blargon7.com/#/remote/report/6959f9a8236961096763389083e95e8f

I suspect it's the same failure (even though it's a remote url).
So changing bug description to reflect the state here.

Comment 2

[Daniel Gherasim]

This week I've seen failures in a row with the same 3 tests in the same testruns.
This tests are failing with readyState complete:

http://mozmill-daily.blargon7.com/#/functional/failure?app=All&branch=All&platform=All&from=2014-02-03&test=%2FtestPreferences%2FtestRestoreHomepageToDefault.js&func=testRestoreHomeToDefault

http://mozmill-daily.blargon7.com/#/functional/failure?app=All&branch=All&platform=All&from=2014-02-03&test=%2FtestPreferences%2FtestSetToCurrentPage.js&func=testSetHomePage

http://mozmill-daily.blargon7.com/#/functional/failure?app=All&branch=All&platform=All&from=2014-02-03&test=%2FtestToolbar%2FtestHomeButton.js&func=testHomeButton

Here is how it looks a single report:
http://mozmill-daily.blargon7.com/#/functional/report/74dbcf1bcfcf95d7600c6041dd10d80c

Comment 3

[Andrei Eftimie]

These are failing very often lately.
Only 33 and 32 seems to be affected.
Failed only on Linux.

It all seems to have started on the 2014-06-10:
http://mozmill-daily.blargon7.com/#/functional/failure?app=Firefox&branch=All&platform=All&from=2014-06-01&test=%2FtestPreferences%2FtestRestoreHomepageToDefault.js&func=testRestoreHomeToDefault

When this fails all 3 tests fail with waitForPageLoad.
> /testPreferences/testRestoreHomepageToDefault.js	
> /testPreferences/testSetToCurrentPage.js	
> /testToolbar/testHomeButton.js

I propose to skip them for the time being.
We used to see this 4-5 times a day. Today these have failed 17 times!

I'll prepare a skip patch.

Comment 4

[Andrei Eftimie]

Attachment: skip.patch

I've disabled these 3 tests only on Linux.

They are run on OSX: http://mozmill-crowd.blargon7.com/#/functional/report/59ac3f70f127c02da3a59eb1fc658e6a

And they are skipped on Linux:
http://mozmill-crowd.blargon7.com/#/functional/report/59ac3f70f127c02da3a59eb1fc6769bc

Comment 5

[Andreea Matei [:AndreeaMatei]]

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

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

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

Comment 6

[Andrei Eftimie]

Works fine on Aurora as well:
http://mozmill-crowd.blargon7.com/#/functional/report/59ac3f70f127c02da3a59eb1fc682f1f
http://mozmill-crowd.blargon7.com/#/functional/report/59ac3f70f127c02da3a59eb1fc6858d3

Transplanted:
https://hg.mozilla.org/qa/mozmill-tests/rev/23e8abb07d5c (mozilla-aurora)

Comment 7

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

I will check that on one of the new kickstarted machines which showed this a lot.

Comment 9

[Daniel Gherasim]

This also fails on windows:
http://mozmill-release.blargon7.com/#/functional/report/a3b8d1e9bea5a0fc05cd41dbf60d7c8c

Comment 10

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

(In reply to Henrik Skupin (:whimboo) [away 07/19 - 08/01] from comment #7)
> I will check that on one of the new kickstarted machines which showed this a
> lot.

Just adding before it gets lost again. The problem as covered in this bug can constantly be reproduced on a kickstarted machine. For this simply use mm-ci-ub-12.04-64 (staging).

Comment 11

[Andrei Eftimie]

I found why this is failing on puppetized machines. We are running on a much lower screen resolution on these machines (800x600).
I can reproduce the same failures locally if I have a similar screen real-estate.

Now to find out exactly what is failing (most likely we are unable to properly use some UI elements)

Comment 12

[Andrei Eftimie]

Attachment: low-resolution.png

Here is the problem depicted graphically.

On lower window sizes, the toolbar buttons collapse and we fail to trigger click events on those items. We would need to click on the "expand" button first.

If memory serves me well, this is an Australis feature, and we had a bug that mentioned this. I will dig it up.

Comment 13

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

Interesting. Do we make use of the home button in all of the cases as covered here? I think that we should have only a single test, which cares about toolbar elements. Otherwise we should use the menu, if there is a command available - which is in case of go to home page.

Comment 14

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

The problem with the screen resolution is probably because we do not use the xorg.conf yet. There is bug 1027345 which has to be addressed, and which lift us up to 1024x768. Looks like this is a real blocker for us for switching to puppet.

Comment 15

[Andrei Eftimie]

Seems we did have 1 Australis bug that was never finished, and a fix there should fix this issue. See bug 942151.

Comment 16

[Andrei Eftimie]

(In reply to Henrik Skupin (:whimboo) [away 07/19 - 08/01] from comment #13)
> Interesting. Do we make use of the home button in all of the cases as
> covered here? I think that we should have only a single test, which cares
> about toolbar elements. Otherwise we should use the menu, if there is a
> command available - which is in case of go to home page.

Yes, all 3 tests that were constantly failing would use the "home-button" directly.
> firefox/tests/functional/testPreferences/testRestoreHomepageToDefault.js
> firefox/tests/functional/testPreferences/testSetToCurrentPage.js
> firefox/tests/functional/testToolbar/testHomeButton.js

Comment 17

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

Ok, so this is the case for our Puppet driven Ubuntu hosts then. But why are we seeing this on our current production boxes? Shall we aim to start Firefox maximized? Maybe that is the problem here, especially since Australis is hiding toolbar buttons?

Comment 18

[Andrei Eftimie]

(In reply to Henrik Skupin (:whimboo) [away 07/19 - 08/01] from comment #17)
> Ok, so this is the case for our Puppet driven Ubuntu hosts then. But why are
> we seeing this on our current production boxes? Shall we aim to start
> Firefox maximized? Maybe that is the problem here, especially since
> Australis is hiding toolbar buttons?

On our production ci machines the default size of Firefox also misses the "home-button". It looks to me that the recently added "loop-call-button" pushes the "home-button" into the expandable panel. This can be solved by maximizing the Firefox window.

Comment 19

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

(In reply to Andrei Eftimie from comment #18)
> "home-button". It looks to me that the recently added "loop-call-button"
> pushes the "home-button" into the expandable panel. This can be solved by
> maximizing the Firefox window.

Do we know which bug added this? Could be added to the blocking list, and this might be a regression beside that bug.

Comment 20

[Andreea Matei [:AndreeaMatei]]

It must be bug 1017273:
https://hg.mozilla.org/mozilla-central/rev/6dc734bab538#l2.12

Comment 21

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

So can you please compare the build before and after its landing? How does the default menu palette look like? Do we hide the home button by default in a sub menu since the loop button is present? If that is the case we should request an increase of the default width.

Comment 22

[Andrei Eftimie]

AFAIK the default width is a percentage of the screen resolution.
This only affects us at 800x600 right now.

Comment 23

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

The default width is calculated differently across platforms. It's not always a percentage of the screen width. Given that it really only affects us for a resolution of 800x600 (which we don't want to test), the bug has way lesser priority then.

None of our current CI systems is running at 800x600, and we don't activate puppetagain unless we support at least 1024x768. So I don't see that we should continue here. I even vote for wontfix.

Comment 24

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

(In reply to daniel.gherasim from comment #0)
> We've seen this failure:
> controller.waitForPageLoad(URI=http://localhost:43336/search/opensearch.html,
> readyState=complete) on a mac osx 10.7 node with the latest Nightly.

Wait, the 800x600 statement is not true! None of our 10.7 machines running that resolution.

Comment 25

[Andrei Eftimie]

(In reply to Henrik Skupin (:whimboo) from comment #24)
> (In reply to daniel.gherasim from comment #0)
> > We've seen this failure:
> > controller.waitForPageLoad(URI=http://localhost:43336/search/opensearch.html,
> > readyState=complete) on a mac osx 10.7 node with the latest Nightly.
> 
> Wait, the 800x600 statement is not true! None of our 10.7 machines running
> that resolution.

The initial report on OSX is different from all others treated in this bug.
So all of them were actually on Linux.

Comment 26

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

Ok, so it looks like that one machine which was mostly affected is mm-ub-1310-32-4.qa.scl3.mozilla.com. Could you do some testruns with those affected tests on that machine? Would be good to know how often it reproduces.

Comment 27

[Andrei Eftimie]

Attachment: 1024x768.jpg

Ah so I was wrong just now. I did explain it in comment 18, maybe that wasn't clear enough.

On our ubuntu CI machines, where we run at 1024x768 screen resolution, this issue is affecting us right now. With the recently (then) introduced "call" button the "home" button gets pushed in the expandable panel.

With this in mind, I would indeed push to have a greater default window size in Firefox as a new user should have all default buttons visible. The question would be: is anyone still using 1024x768?q

Comment 28

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

We have a min-width specified which should not hide any main toolbar buttons. I think it is this one:
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.css#9

You could tweak this css file and check if a higher value solves the problem. This is similar to bug 951928, which got fixed. So lets get a Firefox bug filed for a fix.

Comment 29

[Andrei Eftimie]

This just failed on ESR31:
http://mozmill-release.blargon7.com/#/functional/report/4b004f9a9a3a5bc3aa0f3a07c16c400d

We'll need to disable these tests as well on this branch.

Comment 30

[Andrei Eftimie]

Disabled to ESR31, transplanted:
https://hg.mozilla.org/qa/mozmill-tests/rev/8e6a57061e5c (mozilla-esr31)

Comment 31

[Daniela Domnici]

Attachment: patch_V1

Created the fix patch for the nightly branch.

Comment 32

[Daniela Domnici]

Tested it on all platforms.Here are the results:
Ubuntu: http://mozmill-crowd.blargon7.com/#/functional/report/999627efae7b8074fc4a2f85163f181d.
Windows: http://mozmill-crowd.blargon7.com/#/functional/report/999627efae7b8074fc4a2f85163fa0d9.
MAC OSX: http://mozmill-crowd.blargon7.com/#/functional/report/999627efae7b8074fc4a2f85163fdb95

Comment 33

[Mihaela Velimiroviciu (:mihaelav)]

Comment on attachment 8559891 [details] [diff] [review]
patch_V1

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

Looks ok with the nit bellow addressed.
Also, the commit message should be updated, it has a misspelled word (it should be "... due to too small window...")

::: firefox/tests/functional/testPreferences/testRestoreHomepageToDefault.js
@@ +10,5 @@
>  var tabs = require("../../../lib/tabs");
>  var utils = require("../../../../lib/utils");
>  
>  var prefWindow = require("../../../lib/ui/pref-window");
> +var browser = require("../../../lib/ui/browser");

This should be placed before prefWindow

Comment 34

[Daniela Domnici]

Attachment: patch_V2

Fixed the nits.

Comment 35

[Andreea Matei [:AndreeaMatei]]

Comment on attachment 8561361 [details] [diff] [review]
patch_V2

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

https://hg.mozilla.org/qa/mozmill-tests/rev/195befdcc229 (default)

Comment 36

[Daniela Domnici]

The attachment 8561361 [details] [diff] [review] also applies to aurora, beta and release.For esr31 branch we don`t have the ../ui/base-window.js library, so we can`t backport it to esr31.

Comment 37

[Daniela Domnici]

Attachment: patch_V1_esr31

Created the patch for the esr31 branch.

Results: http://mozmill-crowd.blargon7.com/#/functional/report/beeca5bc62c04337e8365d933b792fec

Comment 38

[Andreea Matei [:AndreeaMatei]]

https://hg.mozilla.org/qa/mozmill-tests/rev/1c8d308ac9ca (aurora)
https://hg.mozilla.org/qa/mozmill-tests/rev/794c97f00d76 (beta)
https://hg.mozilla.org/qa/mozmill-tests/rev/86d6fbd80543 (release)

Comment 39

[Andreea Matei [:AndreeaMatei]]

https://hg.mozilla.org/qa/mozmill-tests/rev/983244502ef3 (esr31)

Comment 40

[Daniela Domnici]

Failed again, with aurora and esr31.

Results: http://mozmill-daily.blargon7.com/#/functional/failure?app=All&branch=All&platform=All&from=2015-02-10&to=&test=%2FtestPreferences%2FtestRestoreHomepageToDefault.js&func=testRestoreHomeToDefault

Comment 41

[Daniela Domnici]

Failed again, with aurora and esr31:

Reports: http://mozmill-daily.blargon7.com/#/functional/failure?app=All&branch=All&platform=All&from=2015-02-11&to=2015-02-12&test=%2FtestPreferences%2FtestRestoreHomepageToDefault.js&func=testRestoreHomeToDefault 

And also in /testToolbar/testHomeButton.js | testHomeButton
http://mozmill-daily.blargon7.com/#/functional/failure?app=All&branch=All&platform=All&from=2015-02-10&to=2015-02-12&test=%2FtestToolbar%2FtestHomeButton.js&func=testHomeButton

Comment 42

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

This should have been totally backed out yesterday! I cannot even understand why this patch got backported straight through beta, release and esr31!. I will go ahead and backout the latest patch across branches.

Comment 43

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

https://hg.mozilla.org/qa/mozmill-tests/rev/6c1f80aa73a0 (default)
https://hg.mozilla.org/qa/mozmill-tests/rev/47f225c2f882 (aurora)
https://hg.mozilla.org/qa/mozmill-tests/rev/655650d00c1b (beta)
https://hg.mozilla.org/qa/mozmill-tests/rev/d3e137a24573 (release)
https://hg.mozilla.org/qa/mozmill-tests/rev/5fe4162edb1c (esr31)

Comment 44

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

There are lots of failures for testHomeButton.js on platforms other than Linux. We should get this test skipped completely and not only on Linux.

Comment 45

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

https://hg.mozilla.org/qa/mozmill-tests/rev/38925cbbe37b (default)
https://hg.mozilla.org/qa/mozmill-tests/rev/620b41b85fd3 (aurora)
https://hg.mozilla.org/qa/mozmill-tests/rev/dd330bca00c0 (beta)
https://hg.mozilla.org/qa/mozmill-tests/rev/a196c9b8d900 (release)
https://hg.mozilla.org/qa/mozmill-tests/rev/a74e3d49a0a4 (esr31)

Comment 46

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

Mozmill tests have been superseded by Marionette tests.