Closed Bug 1275963 Opened 8 years ago Closed 6 years ago

Intermittent browser_bug556061.js | Found an unexpected tab at the end of test run: about:blank

Categories

(Firefox :: Address Bar, defect, P3)

Product:
Firefox
Component:
Address Bar
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox49 --- affected
firefox50 --- affected

People

(Reporter: RyanVM, Assigned: gbrown)

Details

(Keywords: intermittent-failure, Whiteboard: [fxsearch])

Attachments

(1 file)

use desktop-test-xlarge for linux 64 mochitest-clipboard
1.85 KB, patch
jmaher
: review+
Details | Diff | Splinter Review 
This is extremely frequent now that this is running in the mochitest-clipboard job. Not sure if it's related to bug 1274299 or not (or whether that will hit anymore with the clipboard split). Gijs, do you have cycles to look into this?

https://treeherder.mozilla.org/logviewer.html#?job_id=9557993&repo=fx-team#L4911
Flags: needinfo?(gijskruitbosch+bugs)
I'll have to make some, as I just requested uplift on all those URL bar fixes. Meanwhile, do you know what's up with that log viewer? Trying to actually view anything produces "The long no longer exists or has expired." ?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(ryanvm)
Stupid bugzilla. Can't keep needinfo flags anymore if also requesting info from someone else. :-\
Flags: needinfo?(gijskruitbosch+bugs)
Bug 1275796. Full logs still work in the mean time.
Flags: needinfo?(ryanvm)
remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=57e2b6b96d41
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to :Gijs Kruitbosch from comment #4)
> remote:  
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=57e2b6b96d41

This seems to not help.

Ryan, can you clarify the 'very frequent' thing? I don't see this on brass stacks: https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1275963&startday=2016-05-25&endday=2016-06-01&tree=all
Flags: needinfo?(ryanvm)
When I filed this, there were 9 instances in less than a day, which was a pace that was trending for the top 10. Hard to make much in the way of judgments since then, however, since we're in the middle of a holiday week and I'm sure that push volumes are down.
Flags: needinfo?(ryanvm)
The majority of these failures are now on taskcluster jobs. That's partly because taskcluster Linux 64 pgo and Linux 64 asan jobs run more frequently than their buildbot counterparts. But even taking that into account, it seems to me that this failure happens more frequently on taskcluster than on buildbot.

:jmaher -- Any thoughts on how I might modify the taskcluster config to help make this more reliable?
Flags: needinfo?(jmaher)
Why did this spike so suddenly? Has anyone tried bisecting it by retriggering? Shouldn't be too hard given it started so suddenly... unless it's the result of an infra change? Leaving ni for jmaher in that respect. I don't have any obvious ideas - I tried to reproduce this a month ago and failed, seems unlikely it'll be any different today.
Flags: needinfo?(gijskruitbosch+bugs)
The spike around June 26 is because that's when we started running Linux x64 asan tests on taskcluster. The taskcluster tests are the same as the traditional tests run from buildbot. For a trial period, the buildbot tests still run, in addition to the taskcluster ones: So Linux x64 asan mochitest-clipboard and mochitest-clipboard-e10s now run twice as often as they did previous to June 26. In fact, it's worse than that, because the taskcluster tests sometimes run when the buildbot ones don't (they are scheduled more aggressively). And on top of that, I think this failure has a greater chance of occuring on a taskcluster run than on buildbot, which is unusual and unexpected to me, and what I'm asking jmaher about.

That said, it is still not hard to find this failure on buildbot -- it's not all taskcluster's fault!
this is the clipboard job and this test is the first test to run in the browser-chrome portion of the test.  So what test is leaving the previous tab open?  I believe this is marionette which we use to load the addons to avoid signing.

I believe browser chrome has a control window, then the browser window, this looks to be accurate based on a screenshot from a failure:
https://public-artifacts.taskcluster.net/AvHtCpepTXSSD1ZWQ10LMw/0/public/test_info//mozilla-test-fail-screenshot_MmIKKy.png

I am not sure where in the process Marionette interferes.

:ahal, does Marionette open a tab up upon launch of the browser?
Flags: needinfo?(jmaher) → needinfo?(ahalberstadt)
I'd prefer to find the root cause of this failure, but here's an alternative: Using a faster worker type appears to effectively avoid this failure.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=279a8d28b5975f5be1e26b66fe194c8c2268bb25

(Compare to normal: https://treeherder.mozilla.org/#/jobs?repo=try&revision=919d5739b7678fce00f1a45adf86fca44d7f3ae5 )
Attachment #8766835 - Flags: review?(jmaher)
Comment on attachment 8766835 [details] [diff] [review]
use desktop-test-xlarge for linux 64 mochitest-clipboard

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

ok, lets just get it green!
Attachment #8766835 - Flags: review?(jmaher) → review+
(In reply to Joel Maher (:jmaher) from comment #19)
> this is the clipboard job and this test is the first test to run in the
> browser-chrome portion of the test.  So what test is leaving the previous
> tab open?  I believe this is marionette which we use to load the addons to
> avoid signing.
> 
> I believe browser chrome has a control window, then the browser window, this
> looks to be accurate based on a screenshot from a failure:
> https://public-artifacts.taskcluster.net/AvHtCpepTXSSD1ZWQ10LMw/0/public/
> test_info//mozilla-test-fail-screenshot_MmIKKy.png
> 
> I am not sure where in the process Marionette interferes.
> 
> :ahal, does Marionette open a tab up upon launch of the browser?

Not that I'm aware of.. I mean aside from the normal tab that is opened when you regularly launch a browser
Flags: needinfo?(ahalberstadt)
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ec69950a1438
Use desktop-test-xlarge for linux x64 mochitest-clipboard tests; r=jmaher
Leave open since my patch won't affect buildbot jobs and may not fully eliminate failures on taskcluster.
Keywords: leave-open
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Whiteboard: [fxsearch]
This hasn't happened for ages, we'll call it "fixed" due to the fact we landed a patch that seemed to help fix it.
Assignee: nobody → gbrown
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: