658941 - permaorange: browser_awesomescreen.js and browser_contentpopup.js broken by bug 657997

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Phil Ringnalda (:philor)]

Prior to bug 657997, the Linux mobile desktop permaorange was down to just one browser_scrollbar.js failure and a shutdown crash. Now, it's added in

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_autocomplete.js | Test timed out
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_awesomescreen.js | Test timed out
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_contentpopup.js | Test timed out
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_dragger.js | Sanity check. Blank document cannot be panned left or right. - Got 800, expected 480
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_vkb.js | Test timed out

Android's failure list added:

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_autocomplete.js | Test timed out (formerly a pair of unexpected passes)
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_awesomescreen.js | Test timed out
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_contentpopup.js | Test timed out
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_dragger.js | Sanity check. Blank document cannot be panned left or right. - Got 800, expected 1024
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_vkb.js | Test timed out

Comment 1

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch

The patch turns back the situation with normal (== with the scrollbar failure, the one I don't see on my computer :/)

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to comment #1)
> Created attachment 534728 [details] [diff] [review] [review]
> Patch
> 
> The patch turns back the situation with normal (== with the scrollbar
> failure, the one I don't see on my computer :/)

Also I've stupidly include the 2 lines fix for bug 657242 in the patch( todo_is -> is)

Comment 3

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch v0.2

I've removed the previously mentioned fix and also the waitForFirstPaint method uses for debugging (added in head.js)

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 534763 [details] [diff] [review]
Patch v0.2

>diff --git a/mobile/chrome/tests/browser_tabs.js b/mobile/chrome/tests/browser_tabs.js

>-  Browser.closeTab(new_tab_01, { forceClose: true });
>-  Browser.closeTab(new_tab_02, { forceClose: true });
>-  Browser.closeTab(new_tab_03, { forceClose: true });
>-  Browser.closeTab(new_tab_04, { forceClose: true });
>-  Browser.closeTab(new_tab_05, { forceClose: true });
>+  while (Browser.tabs.length > 1)
>+    Browser.closeTab(Browser.tabs[Browser.tabs.length - 1], { forceClose: true });

Don't do this. I want to make sure the test only closes the tabs it opened. Just looping over the tabs is not specifc enough. Either leave the code as is, or put the opened tabs in an array and loop over that array (we do that in other tests).

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch v0.3

Addressed comments.

Comment 6

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch v0.4

There is an issue introduce by bug 636792 that broke the browser_autocomplete.js test and I think this should be fixed into a separate bug as this one is the one for the HTTP regression.

Comment 7

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

http://hg.mozilla.org/mozilla-central/rev/c183753a3d00

Comment 8

[Phil Ringnalda (:philor)]

http://tinderbox.mozilla.org/showlog.cgi?log=Mobile/1306331051.1306334387.12999.gz

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_autocomplete.js | Test timed out
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_awesomescreen.js | Test timed out
...
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/tests/browser_contentpopup.js | Test timed out

Looks like you got two of them, though.

Comment 9

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

For the browser_autocomplete.js I have added a fix in bug 636792. This is a regression from something else.

Comment 10

[Phil Ringnalda (:philor)]

And to make the trail even twistier, the browser_awesomescreen.js timeout got killed by commenting-out in http://hg.mozilla.org/mozilla-central/rev/a52b04dc29ea from a bustage fixing followup to bug 645725.

Comment 11

[Phil Ringnalda (:philor)]

Attachment: disable b_autocomplete and b_contentpopup

I hate to keep pounding away with the same Disable Hammer, but politically we need the Android tests to be something that runs, not something that's hidden away because they are totally broken and utterly without value and merely wasting electricity and CPU cycles.

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 538432 [details] [diff] [review]
disable b_autocomplete and b_contentpopup

Sigh

Comment 13

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/e6ded63249b8

Comment 14

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/e6ded63249b8

I'm not closing the bug since looks like this is just a temporary disable. please close it if I'm wrong.