Closed Bug 993712 Opened 10 years ago Closed 10 years ago

Intermittent browser_984455_bookmarks_items_reparenting.js | timed out | Uncaught exception - Context menu (BMB_bookmarksToolbarPopup) did not fire popupshown within 20 seconds.

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 32
Tracking Status
firefox30 --- unaffected
firefox31 --- verified
firefox32 --- verified
firefox-esr24 --- unaffected

People

(Reporter: philor, Assigned: mconley)

References

Details

(Keywords: intermittent-failure, Whiteboard: p=0 s=it-32c-31a-30b.3 [qa-])

Attachments

(2 files, 1 obsolete file)

https://tbpl.mozilla.org/php/getParsedLog.php?id=37457799&tree=Mozilla-Inbound
Windows 7 32-bit mozilla-inbound debug test mochitest-browser-chrome on 2014-04-08 09:13:42 PDT for push 468b75c559b8
slave: t-w732-ix-058

09:32:10     INFO -  --DOMWINDOW == 39 (3173DDE0) [pid = 3640] [serial = 3553] [outer = 00000000] [url = chrome://browser/content/browser.xul]
09:32:10  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Uncaught exception - Context menu (BMB_bookmarksToolbarPopup) did not fire popupshown within 20 seconds.
Looks like you own this one, Mike :)
Flags: needinfo?(mconley)
Interesting - I mostly see debug builds showing this error, but every now and then I see an opt (example: comment 49).

So clearly we've got some kind of race here. Let me see if I can track it down.
Assignee: nobody → mconley
Flags: needinfo?(mconley)
I'll start by seeing if I can force a screenshot out of a timed out test, by removing the customize tests popup timeout handler, and forcing a traditional test timeout.

https://tbpl.mozilla.org/?tree=Try&rev=ad4f5baeb20c
Grrr - that didn't work. My attempt at causing a timeout introduced other failures. This should work better:

https://tbpl.mozilla.org/?tree=Try&rev=fcf651f6883b
So, I'm retriggering bc1 like crazy, and so far, I'm not seeing the timeout. This makes me suspect that 20 seconds is, somehow, just not enough for the menupopup to open, and that if we wait a bit longer, it'll eventually get there.

I have _no idea_ why it'd need more than 20 seconds. But if that's the case, we might be able to fix this by just upping the timeout amount to something greater than 20 seconds. Maybe 60 seconds instead.

I've triggered more bc1 tests, and we'll see if any more oranges show up. If they don't, I'll put together a patch to bump the timeout amount.
Ok, let's see if 60 seconds is enough:

https://tbpl.mozilla.org/?tree=Try&rev=baaa0c963863
I think the try push in comment 67 is pretty compelling. I'll put the patch up for review.
Attached patch Patch v1 (obsolete) — Splinter Review
Comment on attachment 8407666 [details] [diff] [review]
Patch v1

What say you, Gijs?
Attachment #8407666 - Flags: review?(gijskruitbosch+bugs)
Comment on attachment 8407666 [details] [diff] [review]
Patch v1

Bah, I just saw the orange on Windows 7 in that try push. :/

Back to square one then - I'm going to try to force a normal timeout to get a screenshot, but I'll focus on Win 7 debug.
Attachment #8407666 - Flags: review?(gijskruitbosch+bugs)
Ok, let's try to force a traditional timeout on Windows debug:

https://tbpl.mozilla.org/?tree=Try&rev=e69f8e93b02f
Getting rid of the 20 second timeout seems to be enough for this one, Gijs. Bumping it to 60 seconds didn't seem to be enough, at least once (see comment 75).

I'm opting for removing that timeout guard there. Thoughts?
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Mike Conley (:mconley) from comment #90)
> Getting rid of the 20 second timeout seems to be enough for this one, Gijs.
> Bumping it to 60 seconds didn't seem to be enough, at least once (see
> comment 75).
> 
> I'm opting for removing that timeout guard there. Thoughts?

This doesn't seem to make sense to me. The timeout in the run from comment #67 is the test timing out after 45 seconds, not because of the 20s catch function, but because of the 45s test timeout. That means removing the timeout or changing it to 60s is going to do roughly the same: hit the mochitest timeout when the popup doesn't show within <mochitest timeout> (currently 45s).

It sounds like waiting isn't the issue here - we're actually not getting called about the popup showing for some reason. The lack of screenshots doesn't help in figuring out why this is, though. :-(

IME these tests failing for the main menu panel had to do with delayed window closures from other tests. I'm also seeing some of those in the logs here (lots of --DOMWINDOW spam in the debug log), so it might be worth looking at the tests preceding this one and checking they're all properly waiting for their respective newly opened windows to close and unload.
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to :Gijs Kruitbosch from comment #93)
> (In reply to Mike Conley (:mconley) from comment #90)
> > Getting rid of the 20 second timeout seems to be enough for this one, Gijs.
> > Bumping it to 60 seconds didn't seem to be enough, at least once (see
> > comment 75).
> > 
> > I'm opting for removing that timeout guard there. Thoughts?
> 
> This doesn't seem to make sense to me. The timeout in the run from comment
> #67 is the test timing out after 45 seconds, not because of the 20s catch
> function, but because of the 45s test timeout. That means removing the
> timeout or changing it to 60s is going to do roughly the same: hit the
> mochitest timeout when the popup doesn't show within <mochitest timeout>
> (currently 45s).
> 
> It sounds like waiting isn't the issue here - we're actually not getting
> called about the popup showing for some reason. The lack of screenshots
> doesn't help in figuring out why this is, though. :-(
> 
> IME these tests failing for the main menu panel had to do with delayed
> window closures from other tests. I'm also seeing some of those in the logs
> here (lots of --DOMWINDOW spam in the debug log), so it might be worth
> looking at the tests preceding this one and checking they're all properly
> waiting for their respective newly opened windows to close and unload.

Ok, let's try that approach.

I found that the browser_968447_bookmarks_toolbar_items_in_panel.js opens a window, and just calls .close() on it. It's the only test that does that, and I've confirmed that it runs before browser_984455_bookmarks_items_reparenting.js. I've pushed a patch to try that makes that first test yield promiseWindowClosed instead.

Fingers crossed:

https://tbpl.mozilla.org/?tree=Try&rev=26b67371315e
Attached patch Patch v2Splinter Review
I could probably land this r=trivial, but I'll do the belt+suspenders thing. :)
Attachment #8407666 - Attachment is obsolete: true
Attachment #8409998 - Flags: review?(jaws)
Comment on attachment 8409998 [details] [diff] [review]
Patch v2

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

Appreciate the belt and suspenders, good to see reminders of what not to do. Thanks for the patch! :)
Attachment #8409998 - Flags: review?(jaws) → review+
Ok, let's see if this fixes it:

remote:   https://hg.mozilla.org/integration/fx-team/rev/ff282758a46d
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/ff282758a46d
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 31
:-(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #8409998 - Flags: checkin+
Alright, here we go again.

Here's a fresh try push, using the new --screenshot-on-fail mochitest argument that landed in bug 991348.

Maybe that'll be more illuminating:

https://tbpl.mozilla.org/?tree=Try&rev=ad85e79afc44
(In reply to Mike Conley (:mconley) from comment #135)
> Alright, here we go again.
> 
> Here's a fresh try push, using the new --screenshot-on-fail mochitest
> argument that landed in bug 991348.
> 
> Maybe that'll be more illuminating:
> 
> https://tbpl.mozilla.org/?tree=Try&rev=ad85e79afc44

Retriggered some more... of course, when we want it to reproduce, it doesn't. :\
I wonder if this is a victim of bug 805068?
See Also: → 805068
I think we should try fixing bug 1002517, and see if this goes away next.
Depends on: 1002517
Depends on: 805068
No longer depends on: 1002517
See Also: 805068
(In reply to TBPL Robot from comment #240)

This was after bug 805068 was merged to inbound, so this wasn't fixed by it :(
I hate this orange. :/

Gijs - I'm thinking we go back to plan A, and try removing that 20 second timeout - not as a solution to this bug, but in order to try to trigger the mochitest timeout handler which will allow us to grab a screenshot. What do you think?
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Mike Conley (:mconley) from comment #267)
> I hate this orange. :/
> 
> Gijs - I'm thinking we go back to plan A, and try removing that 20 second
> timeout - not as a solution to this bug, but in order to try to trigger the
> mochitest timeout handler which will allow us to grab a screenshot. What do
> you think?

I mean, I suspect the screenshot will show a window with the popup not showing, and that's it, but trying it won't hurt, I guess.

I was actually going to suggest bisecting this (in terms of disabling some of the CUI tests that run before it and seeing if that helps), but I guess that even though we get like 5-10 failures a day, the frequency might still be low enough that that will be a long and laborious process. :-\

The other thing is that I thought we were going to start running tests per folder, which would help with that...
Flags: needinfo?(gijskruitbosch+bugs)
Alright, hand-rolled timeout removed for now:

remote:   https://hg.mozilla.org/integration/fx-team/rev/c0d4a7bb2d41
Whiteboard: [leave open]
No longer depends on: 805068
(In reply to TBPL Robot from comment #276)
> Tomcat
> https://tbpl.mozilla.org/php/getParsedLog.php?id=39799248&tree=Mozilla-
> Inbound
> Windows XP 32-bit mozilla-inbound debug test mochitest-browser-chrome-1 on
> 2014-05-16 02:22:26
> revision: c8e329647317
> slave: t-xp32-ix-002
> 
> TEST-UNEXPECTED-FAIL |
> chrome://mochitests/content/browser/browser/components/customizableui/test/
> browser_984455_bookmarks_items_reparenting.js | Test timed out
> Return code: 1

Screen shot:

http://mozilla-releng-blobs.s3.amazonaws.com/blobs/mozilla-inbound/sha512/93aac04b4716213aaf79cf69167fa11793558eeebc5f0d13921ec5b234e38b35a8c9ef86cfa1e2a92bd4b4d041d7cf0d2723dfb084b091615315ccbcffc6c10f

(In reply to TBPL Robot from comment #272)
> edmorley
> https://tbpl.mozilla.org/php/getParsedLog.php?id=39739386&tree=Fx-Team
> WINNT 6.2 fx-team debug test mochitest-browser-chrome-1 on 2014-05-15
> 08:13:07
> revision: 9954f1b718d5
> slave: t-w864-ix-068
> 
> TEST-UNEXPECTED-FAIL |
> chrome://mochitests/content/browser/browser/components/customizableui/test/
> browser_984455_bookmarks_items_reparenting.js | Test timed out
> Return code: 1

Screen shot:

http://mozilla-releng-blobs.s3.amazonaws.com/blobs/fx-team/sha512/f0ae517d03223cfba97e3e44a89385a9dc6da0311f8ee07a51e89bb28be716dd061a34bf08d7b5c32bd4bc016341fe088c733c07796597bda3c2ead8dc6b2595


So it looks like the popup is opening fine, but the transitionend listener isn't firing? Coincidentally, this started failing on the day bug 610545 landed.

Neil, can you shed some light here?
Blocks: 610545
Flags: needinfo?(enndeakin)
Is the test assuming that the transitionend event will occur before or after the popupshown event? Until bug 994117 is fixed, they may come in either order. If so, the patch in that bug may fix this.

Is the popup being opened and closes several times in succession?
Flags: needinfo?(enndeakin)
adjusted the summary to catch this new timeout
Summary: Intermittent browser_984455_bookmarks_items_reparenting.js | Uncaught exception - Context menu (BMB_bookmarksToolbarPopup) did not fire popupshown within 20 seconds. → Intermittent browser_984455_bookmarks_items_reparenting.js | timed out | Uncaught exception - Context menu (BMB_bookmarksToolbarPopup) did not fire popupshown within 20 seconds.
(In reply to Neil Deakin from comment #279)
> Is the test assuming that the transitionend event will occur before or after
> the popupshown event? Until bug 994117 is fixed, they may come in either
> order. If so, the patch in that bug may fix this.

No, the test doesn't check for the popupshown event at all.

> Is the popup being opened and closes several times in succession?

Yes, but the failure occurs before that in this test, although it's possible other tests might also have opened the menu...
(In reply to :Gijs Kruitbosch from comment #278)
> (In reply to TBPL Robot from comment #276)
> > Tomcat
> > https://tbpl.mozilla.org/php/getParsedLog.php?id=39799248&tree=Mozilla-
> > Inbound
> > Windows XP 32-bit mozilla-inbound debug test mochitest-browser-chrome-1 on
> > 2014-05-16 02:22:26
> > revision: c8e329647317
> > slave: t-xp32-ix-002
> > 
> > TEST-UNEXPECTED-FAIL |
> > chrome://mochitests/content/browser/browser/components/customizableui/test/
> > browser_984455_bookmarks_items_reparenting.js | Test timed out
> > Return code: 1
> 
> Screen shot:
> 
> http://mozilla-releng-blobs.s3.amazonaws.com/blobs/mozilla-inbound/sha512/
> 93aac04b4716213aaf79cf69167fa11793558eeebc5f0d13921ec5b234e38b35a8c9ef86cfa1e
> 2a92bd4b4d041d7cf0d2723dfb084b091615315ccbcffc6c10f
> 
> (In reply to TBPL Robot from comment #272)
> > edmorley
> > https://tbpl.mozilla.org/php/getParsedLog.php?id=39739386&tree=Fx-Team
> > WINNT 6.2 fx-team debug test mochitest-browser-chrome-1 on 2014-05-15
> > 08:13:07
> > revision: 9954f1b718d5
> > slave: t-w864-ix-068
> > 
> > TEST-UNEXPECTED-FAIL |
> > chrome://mochitests/content/browser/browser/components/customizableui/test/
> > browser_984455_bookmarks_items_reparenting.js | Test timed out
> > Return code: 1
> 
> Screen shot:
> 
> http://mozilla-releng-blobs.s3.amazonaws.com/blobs/fx-team/sha512/
> f0ae517d03223cfba97e3e44a89385a9dc6da0311f8ee07a51e89bb28be716dd061a34bf08d7b
> 5c32bd4bc016341fe088c733c07796597bda3c2ead8dc6b2595
> 
> 
> So it looks like the popup is opening fine, but the transitionend listener
> isn't firing? Coincidentally, this started failing on the day bug 610545
> landed.
> 
> Neil, can you shed some light here?

I think we're getting off track a little here - the popup is _not_ opening. The popup that's supposed to be open isn't just the bookmarks menu popup, but the popup under "Bookmarks Toolbar", which in both screenshots is not open.
(In reply to Mike Conley (:mconley) from comment #284)
> I think we're getting off track a little here - the popup is _not_ opening.
> The popup that's supposed to be open isn't just the bookmarks menu popup,
> but the popup under "Bookmarks Toolbar", which in both screenshots is not
> open.

Err, are you sure?

If I read: https://tbpl.mozilla.org/php/getParsedLog.php?id=39799248&full=1&branch=mozilla-inbound right:

01:39:43     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Entering test testOverflowingBookmarksButtonContextMenu
01:39:43     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Should start with a non-overflowing toolbar.
01:39:43     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Should start in default state.
01:39:43     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Waiting for bookmarks menu popup to show after clicking dropmarker.
01:39:43     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Console message: [JavaScript Warning: "anonymous function does not always return a value" {file: "chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js" line: 120}]

<snip>

02:44:09  WARNING -  TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Test timed out

there is no way of knowing what we're waiting for. We should add some more info statements to the test.
Landed:

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


to get us more info, as this is high up in last week's OF stats and we should really figure this out. :-(
Looks like:

02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Entering test testOverflowingBookmarksButtonContextMenu
02:27:16     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Should start with a non-overflowing toolbar.
02:27:16     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Should start in default state.
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Waiting for bookmarks menu popup to show after clicking dropmarker.
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Console message: [JavaScript Warning: "anonymous function does not always return a value" {file: "chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js" line: 126}]
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Waiting to open menu for BMB_bookmarksToolbar
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Waiting for context menu on BMB_bookmarksToolbarPopup
02:27:16     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | New bookmark item shouldn't be disabled
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Closing context menu
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Closing menu for BMB_bookmarksToolbar
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Waiting to open menu for BMB_unsortedBookmarks
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Waiting for context menu on BMB_unsortedBookmarksPopup
02:27:16     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | New bookmark item shouldn't be disabled
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Closing context menu
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Closing menu for BMB_unsortedBookmarks
02:27:16     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Closing bookmarks menu
02:27:17     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Waiting for overflow
02:27:17     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Item with ID bookmarks-menu-button should no longer be in the gNavBar
02:27:17     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Item with ID bookmarks-menu-button should be overflowing
02:27:17     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Item with ID bookmarks-menu-button should have overflowedItem attribute
02:27:17     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Waiting until we stop overflowing
02:27:17     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Item with ID bookmarks-menu-button should no longer be overflowing
02:27:17     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Item with ID bookmarks-menu-button should be in the nav bar
02:27:17     INFO -  TEST-PASS | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Item with ID bookmarks-menu-button should not have overflowedItem attribute
02:27:17     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Waiting for bookmarks menu popup to show after clicking dropmarker.
02:27:18     INFO -  TEST-INFO | chrome://mochitests/content/browser/browser/components/customizableui/test/browser_984455_bookmarks_items_reparenting.js | Waiting to open menu for BMB_bookmarksToolbar



and because there isn't:

    1.12 +    info("Waiting for context menu on " + aItemWithContextMenu.id);

looks like the submenu isn't opening, for whatever reason. That's odd, and I don't know why that'd happen.

Mike, got ideas now that we have this information?
Flags: needinfo?(mconley)
So let's see if maybe our synth mouse events are contributing to this.

This patch makes us use openPopup directly on the submenus of the bookmarks menu.
Flags: needinfo?(mconley)
Attachment #8427990 - Attachment is patch: true
Attachment #8427990 - Flags: review?(jaws)
Comment on attachment 8427990 [details] [diff] [review]
Switch to using openPopup to open the menu instead of a synth mouse event

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

rs=me

Did you push this to try and request multiple runs to see if this intermittent orange went away?
Attachment #8427990 - Flags: review?(jaws) → review+
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #304)
> Comment on attachment 8427990 [details] [diff] [review]
> Switch to using openPopup to open the menu instead of a synth mouse event
> 
> Review of attachment 8427990 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> rs=me
> 
> Did you push this to try and request multiple runs to see if this
> intermittent orange went away?

Er, whoops, pushed without seeing your comment.

To answer your question - no, I didn't push to try and look to see if the orange was gone. There have been numerous failed attemps to smoke out the orange on try (see some of my previous comments - the builds are gone by now, but trust me, dozens and dozens).

Gijs and I have been landing logging and attempts / guesses at fixes on fx-team/m-c, since that seems to be the best way to see if the orange is gone. :/
(In reply to Mike Conley (:mconley) from comment #305)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #304)
> > Comment on attachment 8427990 [details] [diff] [review]
> > Switch to using openPopup to open the menu instead of a synth mouse event
> > 
> > Review of attachment 8427990 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > rs=me
> > 
> > Did you push this to try and request multiple runs to see if this
> > intermittent orange went away?
> 
> Er, whoops, pushed without seeing your comment.

This was https://hg.mozilla.org/integration/fx-team/rev/a6a58a279fcf fwiw.


> Gijs and I have been landing logging and attempts / guesses at fixes on
> fx-team/m-c, since that seems to be the best way to see if the orange is
> gone. :/

Indeed. The problem is that even a 1/100 builds orange is frequent enough to be annoying for sheriffs considering how many builds we run every day, but obviously manually retriggering 100 bc1 runs is kind of annoying.
There hasn't been an m-c or integration branch occurrence of this since this last patch landed (more than a week ago, with more-than-daily failures beforehand). I expect this has fixed the issue. The remaining issue is that the failure has moved to aurora, which is an ESR-branch-to-be. I'm uplifting this so we green that up.

remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/13f8ae33faf8
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Whiteboard: [leave open]
Target Milestone: Firefox 31 → Firefox 32
Marco, can you make this part of (Mike's work for) this iteration? (I guess most of the work was done in the previous one, but better late than never)
Status: RESOLVED → VERIFIED
Flags: needinfo?(mmucci)
Whiteboard: p=3 [qa-]
Flags: needinfo?(mmucci)
Whiteboard: p=3 [qa-]
Added to Iteration 32.3
Flags: firefox-backlog+
Whiteboard: p=0 s=it-32c-31a-30b.3 [qa-]
(In reply to Marco Mucci [:MarcoM] from comment #318)
> Added to Iteration 32.3

Why was this marked p=0 ? I did put in a point value originally (p=3)
Flags: needinfo?(mmucci)
(In reply to :Gijs Kruitbosch from comment #319)
> (In reply to Marco Mucci [:MarcoM] from comment #318)
> > Added to Iteration 32.3
> 
> Why was this marked p=0 ? I did put in a point value originally (p=3)

Treating the bug as a community/contributor submission as Gavin informed me that Mike C. would not be participating in the regular Desktop iterations.  We do not track point values for community/contributor bugs - only when they are done and if they require QA verification.
Flags: needinfo?(mmucci)
"p=X" as a way of denoting remaining-work-points-for-the-FX-desktop-team is pretty opaque to anyone who hasn't sat in those meetings, as jaws notes on Firefox-Dev. A reasonable person would assume that means "priority", so we could avoid future confusion by giving that tag a better name. 

Contributor-owned bugs don't automatically become low-priority bugs or low-workload bugs; we have the [diamond] whiteboard flag to surface organizational priorities we'd like community members' help with.
You need to log in before you can comment on or make changes to this bug.