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)
Tracking
(b2g-v2.1 fixed, b2g-v2.2 fixed)
RESOLVED
FIXED
2.1 S5 (26sep)
People
(Reporter: asuth, Assigned: kgrandon)
Details
(Whiteboard: [systemsfe])
Attachments
(2 files)
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.
Assignee | ||
Comment 1•10 years ago
|
||
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.
Assignee | ||
Comment 2•10 years ago
|
||
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 3•10 years ago
|
||
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+
Assignee | ||
Comment 4•10 years ago
|
||
Comment on attachment 8493465 [details]
Github pull request
Thanks for the quick review. Letting Andrew off the hook :)
Attachment #8493465 -
Flags: review?(bugmail)
Assignee | ||
Comment 5•10 years ago
|
||
Assignee: nobody → kgrandon
Status: NEW → RESOLVED
Closed: 10 years ago
status-b2g-v2.1:
--- → affected
status-b2g-v2.2:
--- → fixed
Resolution: --- → FIXED
Whiteboard: [systemsfe]
Target Milestone: --- → 2.1 S5 (26sep)
Assignee | ||
Comment 6•10 years ago
|
||
Uplifted to v2.1 to get the tree green, a=testonly: https://github.com/mozilla-b2g/gaia/commit/db34a4b7edc0e08ede425f21f8a5b5e161e7dda8
You need to log in
before you can comment on or make changes to this bug.
Description
•