Open Bug 949434 Opened 8 years ago Updated 6 years ago

Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/downloads/test/browser/browser_first_download_panel.js | Test timed out

Categories

(Firefox :: Downloads Panel, defect, P3)

x86
Linux
defect

Tracking

()

People

(Reporter: cbook, Unassigned)

References

()

Details

(Keywords: intermittent-failure, Whiteboard: [test disabled on Linux][leave open])

Attachments

(1 obsolete file)

Rev3 Fedora 12 fx-team debug test mochitest-browser-chrome on 2013-12-12 01:26:17 PST for push 53f6414f956a

slave: talos-r3-fed-030


https://tbpl.mozilla.org/php/getParsedLog.php?id=31864359&tree=Fx-Team

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/downloads/test/browser/browser_first_download_panel.js | Test timed out
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/downloads/test/browser/browser_overflow_anchor.js | Panel should be anchored to the chevron. - Got null, expected [object XULElement]
Paolo, can you please take a look at what might have caused this very recent regression?
Flags: needinfo?(paolo.mozmail)
I don't think I'll be able to look into this before I have made more progress on the work I'm doing for the Login Manager. Maybe Mike or Gijs can help?
Flags: needinfo?(paolo.mozmail)
Flags: needinfo?(mdeboer)
Flags: needinfo?(gijskruitbosch+bugs)
Looking...
Assignee: nobody → gijskruitbosch+bugs
Flags: needinfo?(gijskruitbosch+bugs)
Can't reproduce locally on my VM. I'll try to make time to add some logging to the CustomizableUI bit that's erroring to get a full stacktrace. This isn't the only bug where that error appears and it seems like it's just generally causing problems. Not 100% sure why/how yet.
Actually, as I was adding stuff here, the only thing that I can think of is that the overflowable toolbar's overriding getter somehow returns null. For that to happen, _list or _target should be null. For that to happen, the problem would have to be that they're not initialized. Which could theoretically (and apparently practically?) happen if you were to call inbetween load() and _delayedBrowserStartup. Hmm. Jared, does this change make sense to you? Just fetching elements earlier shouldn't really make any other differences here, but it might fix this issue. What do you think?
Attachment #8348204 - Flags: review?(jaws)
See Also: → 949357
Flags: needinfo?(mdeboer)
Comment on attachment 8348204 [details] [diff] [review]
Australis' overflowable toolbar might have race condition causing test failures,

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

Worth a try, as long as using the customizationTarget getter doesn't force the binding to be constructed earlier than before.
Attachment #8348204 - Flags: review?(jaws) → review+
(In reply to Jared Wein [:jaws] (Away 20 Dec to 2 Jan) from comment #40)
> Comment on attachment 8348204 [details] [diff] [review]
> Australis' overflowable toolbar might have race condition causing test
> failures,
> 
> Review of attachment 8348204 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Worth a try, as long as using the customizationTarget getter doesn't force
> the binding to be constructed earlier than before.

The constructor is invoked from registerToolbarNode, which is invoked from the binding, so that shouldn't happen.

remote:   https://hg.mozilla.org/integration/fx-team/rev/b26925dd9232

(Leaving open to see if this fixes the orange)
Whiteboard: [leave open]
Whiteboard: [leave open] → [leave open][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/b26925dd9232

FWIW, there have definitely been instances of this on fx-team after this landed there.
Whiteboard: [leave open][fixed-in-fx-team] → [leave open]
(In reply to :Gijs Kruitbosch (Unavailable Dec 19 - Jan 2) from comment #87)
> (Leaving open to see if this fixes the orange)

This is currently #3 on Orange Factor. Jared, can you please take a look since it appears that Gijs isn't around?
Flags: needinfo?(jaws)
Test disabled at jaws' request.
https://hg.mozilla.org/integration/fx-team/rev/2898275c1c43
Flags: needinfo?(jaws)
Whiteboard: [leave open] → [test disabled on Linux][leave open]
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #111)
> https://hg.mozilla.org/mozilla-central/rev/b26925dd9232
> 
> FWIW, there have definitely been instances of this on fx-team after this
> landed there.

Yeah, the patch fixed the error that was originally reported and might have fixed other random test failures, but seems unrelated to this actual test failure. It'd be helpful if I could actually reproduce the test failure itself locally, though. :-(
Unassigning because if the error is unrelated I don't actually know what's causing this test to timeout, and as I can't reproduce locally...
Assignee: gijskruitbosch+bugs → nobody
Attachment #8348204 - Attachment is obsolete: true
Attachment #8348204 - Flags: checkin+
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.