Closed Bug 1071349 Opened 10 years ago Closed 10 years ago

[browser] Intermittent tbpl/try failure on browser_chrome_share_web_result_test.js [Browser Chrome - Share Web Result share web result via e-mail][NoSuchElement: (7) Unable to locate element: .icon[data-identifier*="mozilla1.org/"]]

Categories

(Firefox OS Graveyard :: Gaia::Browser, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(b2g-v2.1 fixed, b2g-v2.2 fixed)

RESOLVED FIXED
2.1 S5 (26sep)
Tracking Status
b2g-v2.1 --- fixed
b2g-v2.2 --- fixed

People

(Reporter: asuth, Assigned: kgrandon)

Details

(Whiteboard: [systemsfe])

Attachments

(2 files)

Attached file marionette stack trace (deleted) —
Especially on try builds, I'm seeing browser_chrome_share_web_result_test.js fail a lot. Like > 33% of the time on my runs. For example, it failed on :kgrandon's try build at https://tbpl.mozilla.org/?tree=Gaia-Try&rev=73bffadec97d it failed. (I pick Kevin's build to demonstrate this is not just me blaming an email problem on the browser :) The test types "mozilla" in the rocketbar and expects a link "mozilla1.org/" to show up, but it never does and it dies on "Unable to locate element: .icon[data-identifier*="mozilla1.org/"]" It looks like there's a fake everything.me server serving the contents of https://github.com/mozilla-b2g/gaia/blob/master/shared/test/integration/eme_server/fixtures/apps_search.json which is where mozilla1 would come from. My guess is that there is a race in this call: chrome.executeScript(function(url) { navigator.mozSettings.createLock().set({ 'everythingme.api.url': url }); }, [server.url + '/{resource}']); Although chrome.executeScript is synchronous, createLock and set I understand to be asynchronous. Arguably the idiom should be altered to be an async execute script which only triggers when the setting is actually written. Preferably that would be factored out into a common settings helper since that's a footgun idiom as it exists right now if I'm correct. However, it seems like there are a lot of moving parts in the test, so this is just my guess. Attaching the call-stack as an attachment. It appears that browser_chrome_bookmark_web_result_test.js overlaps this test up through the point where it fails, so it would likely experience the same failures.
Attached file Github pull request (deleted) —
Thank you for filing this. I've been meaning to fix or disable this test, but since you pointed out what was wrong, it should be pretty easy. Let's see what gaia-try does with this.
Comment on attachment 8493465 [details] Github pull request Dale or Andrew - could either of you guys take a look at this? Just need a single review probably. Thanks!
Attachment #8493465 - Flags: review?(dale)
Attachment #8493465 - Flags: review?(bugmail)
Comment on attachment 8493465 [details] Github pull request This looks good to me, the other test failures are unrelated and change makes sense
Attachment #8493465 - Flags: review?(dale) → review+
Comment on attachment 8493465 [details] Github pull request Thanks for the quick review. Letting Andrew off the hook :)
Attachment #8493465 - Flags: review?(bugmail)
Assignee: nobody → kgrandon
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [systemsfe]
Target Milestone: --- → 2.1 S5 (26sep)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: