608349 - Fix browser-chrome tests

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Wesley Johnston (:wesj)]

Attachment: Patch

I'm seeing about 12 browser-chrome test failures in mobile:

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_addons.js | Restart exists = true - Got false, expected true

hash entry is wrong. Its probably easiest to just not use one.

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_awesomescreen.js | urlbar text should be selected on a click - Got false, expected true
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_awesomescreen.js | urlbar text should be selected on a click - Got false, expected true
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_awesomescreen.js | urlbar text should be selected on a click - Got false, expected true

We are setting edit.clickSelectsAll = false; and then expecting the text to be selected.

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_preferences_text.js | The About Page and the Fennec Start are of same height
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_preferences_text.js | The fields of Privacy & Security are of same height
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_preferences_text.js | The fields of Content Region and above are of same height
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_preferences_text.js | The fields of Privacy & Security and above are of same height

Broken when the theme landed. I fixed on of these. The others are for checkboxes, which for some reason are drawn wrong when I run mochitests (they use the system theme, not the fennec one). 

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_tapping.js | Plain link context types
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_tapping.js | Plain image context types
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_tapping.js | Nested image context types

Clicks aren't firing on the elements they are supposed to. Using the boundingClientRect on the first one seems to fix this for all three tests...

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/mobile/chrome/browser_viewport.js | Viewport scale=0.8163 [got 1, expected 0.8163]

I don't think we're zooming out any more (not sure what bug changed that?), so I just updated this test to expect 1.

Comment 1

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

(In reply to comment #0)
> Created attachment 486985 [details] [diff] [review]
> Patch
> 
> I'm seeing about 12 browser-chrome test failures in mobile:
> 
> TEST-UNEXPECTED-FAIL |
> chrome://mochitests/content/browser/mobile/chrome/browser_addons.js | Restart
> exists = true - Got false, expected true
> 
> hash entry is wrong. Its probably easiest to just not use one.

Sounds good

> TEST-UNEXPECTED-FAIL |
> chrome://mochitests/content/browser/mobile/chrome/browser_awesomescreen.js |
> urlbar text should be selected on a click - Got false, expected true
> TEST-UNEXPECTED-FAIL |
> chrome://mochitests/content/browser/mobile/chrome/browser_awesomescreen.js |
> urlbar text should be selected on a click - Got false, expected true
> TEST-UNEXPECTED-FAIL |
> chrome://mochitests/content/browser/mobile/chrome/browser_awesomescreen.js |
> urlbar text should be selected on a click - Got false, expected true
> 
> We are setting edit.clickSelectsAll = false; and then expecting the text to be
> selected.

These awesomescreen failures are probably causing the awesomescreen to stay open and then causing many of the next tests to fail.

We should force the awesomescreen to close in the cleanup of these tests.

Comment 2

[Matt Brubeck (:mbrubeck)]

Comment on attachment 486985 [details] [diff] [review]
Patch

Great!

Comment 3

[Matt Brubeck (:mbrubeck)]

http://hg.mozilla.org/mobile-browser/rev/19b67cae68f6

Comment 4

[Anna (Waverley)]

How can I verify this?

Comment 5

[Dão Gottwald [:dao]]

bugspam