Closed Bug 1200766 Opened 9 years ago Closed 8 years ago

Intermittent test_fullscreen-api-race.html | application crashed [@ nsGlobalWindow::FinishFullscreenChange(bool)] ( Assertion failure: presShell->IsInFullscreenChange(), at nsGlobalWindow.cpp:6635)

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox43 --- affected

People

(Reporter: RyanVM, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, crash, intermittent-failure) 

      No description provided.
No longer blocks: fullscreen-api
According to "War on Orange", this intermittent happens 11 times after comment 17, but why there wasn't any log here?
Tomcat, any idea about comment 18?
Flags: needinfo?(cbook)
(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #19)
> Tomcat, any idea about comment 18?

i think ed manage the new orangefactor bot. Maybe he knows if there was a problem or so - or why the bot hasn't commented so far
Flags: needinfo?(cbook) → needinfo?(emorley)
https://groups.google.com/d/msg/mozilla.dev.tree-management/az643p0u4hs/3el7fqIDBwAJ

"""
There will be two types of summary:
a) Daily: Intended to warn of sudden spikes in failure rate, for which
waiting a week would be too long. Posted to bugs with >= 15 failures/day
across all trees.
b) Weekly: The primary summary, intended to keep interested parties up to
date and make it clear the bug is still occurring. Posted if >=5
failures/week across all trees.
"""

The 11 occurrences mentioned in comment 18 were total over 3 months, not in an individual day or week:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&tree=all&startday=2015-10-12&endday=2016-01-12&bugid=1200766

This is working as expected.

Tomcat - it's probably worth the sheriffs bookmarking that google groups post above, it's pretty important that the sheriffs understand the current algorithm (and I'm also open to suggestions for tweaking it if you have ideas) :-)
Flags: needinfo?(emorley)
Why is there a 5 failures/week threshold? I'd suggest it post a weekly summary if there is any failure in the week. Not posting anything would give people a false impression that this intermittent has been resolved.

If a per-week failure report is still considered too annoying for such low-volume intermittent, probably we can have some kind of report a month or 6 weeks after the previous report if there is any failure happens within the duration.

My main concern is the false impression. I've visited this bug twice and it took me some time to realize that this bug hasn't actually been fixed yet, although the last report was posted 3 months ago.
The bug where the thresholds were set is mentioned in the google groups post linked above (which should answer your question). There's no perfect solution here, but there's are still likely improvements that can be made. If you file bugs in Tree Management::OrangeFactor it will be easier to discuss them there :-)
Also note that in the not too distant future 80% of intermittent failures will not ever have bugs filed, since they are just not actionable (think a crash-stats like model, where bugzilla isn't the source of truth, a dashboard is, from which bugs can be filed for instances that are deemed important/actionable), so this bug would likely fall into that category anyway.
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
It doesn't happen for over half year. Close as WORKSFORME.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.