QA/Firefox3/TestResults/RC1/RC2BugCandidates: Difference between revisions

QA/Firefox3/TestResults/RC1/RC2BugCandidates (view source)

Revision as of 20:50, 23 May 2008

241 bytes added , 23 May 2008

m

→‎Bug Candidates for Triage

Tchung

Confirmed users

6,361

edits

@@ Line 27: / Line 27: @@
 *'''[RC2+]'''{{Bug|435047}} – Consistent Crash in nsHTMLReflowState::GetNearestContainingBlock when visiting site. depends on {{bug|398332}}  We want this for RC2.  Highly visited site.
 *'''[RC2+]'''{{bug|433525}} - crash [@ nsNavHistoryQueryResultNode::IsContainersQuery()].   Number 1 topcrash, is a recent regression which we should probably respin for. The bug has a patch ready to go.  We want this for RC2.
-* {{Bug|434401}} – crash [@ gfxWindowsFont::GetOrMakeFont(FontEntry*, gfxFontStyle const*)]. that may be happening in thebes or layout. dbaron believes thebes. Needs a developer, comments in stack aren't helpful. This is a crash on startup.
+*'''[RC2?]'''{{Bug|434401}} – crash [@ gfxWindowsFont::GetOrMakeFont(FontEntry*, gfxFontStyle const*)]. that may be happening in thebes or layout. dbaron believes thebes. Needs a developer, comments in stack aren't helpful. This is a crash on startup.  We want to nominate for RC2.
-* {{Bug|434403}} – startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)]. recent regression. While we saw this crash in beta 5 (presumably from upgrading from beta 4), it's much greater this release and happens at a different address. If timeless is right in that bug, it's a pretty easy fix.  but we'd need to test with a round of RC1 -> RC2, to confirm its been fixed.
+* <del>{{Bug|434403}} – startup crash [@ nsDocShell::SetupNewViewer(nsIContentViewer*)]. recent regression. While we saw this crash in beta 5 (presumably from upgrading from beta 4), it's much greater this release and happens at a different address. If timeless is right in that bug, it's a pretty easy fix.  but we'd need to test with a round of RC1 -> RC2, to confirm its been fixed. </del>  We have no patch, and QA cannot reproduce.  Moving it out.
 ;Accessibility [marcoz]
-*'''[RC2?][has-patch,has-review]'''{{Bug|432970}} - Shutdown() of nsXULTooltipAccessible is not called. Affects Linux only, but can cause accessible tree corruption because tooltip accessibles from tabs that are already closed may still be around and accidentally accessed by the Orca screen reader. Again not a blocker, but a good candidate to tag along.  (Per [https://bugzilla.mozilla.org/show_bug.cgi?id=432970#c11 #c11], 2 related crashes)
+*'''[RC2?][has-patch,has-review]'''{{Bug|432970}} - Shutdown() of nsXULTooltipAccessible is not called. Affects Linux only, but can cause accessible tree corruption because tooltip accessibles from tabs that are already closed may still be around and accidentally accessed by the Orca screen reader. Again not a blocker, but a good candidate to tag along.  (Per [https://bugzilla.mozilla.org/show_bug.cgi?id=432970#c11 #c11], 2 related crashes)  We want this in RC2.  Patch should be low risk.
-*'''[RC2?][has-patch,has-review]'''{{Bug|434002}} - event show isn't fired for treecol accessible. This is an embarrassing oversight from review of fix for {{bug|413777}}. It basically means that event_show is never ever called for any accessible even if it needs to be. The most obvious use case we found isn't in Firefox but Thunderbird, when column (See [https://bugzilla.mozilla.org/show_bug.cgi?id=434002#c6 #c6])
+*'''[RC2?][has-patch,has-review]'''{{Bug|434002}} - event show isn't fired for treecol accessible. This is an embarrassing oversight from review of fix for {{bug|413777}}. It basically means that event_show is never ever called for any accessible even if it needs to be. The most obvious use case we found isn't in Firefox but Thunderbird, when column (See [https://bugzilla.mozilla.org/show_bug.cgi?id=434002#c6 #c6])  We want this for RC2.
 *'''[RC2?][has-patch,has-review]'''{{Bug|432467}} - firefox segfaults in plone kupu editor [@ nsDocAccessible::FlushPendingEvents]. This is a crasher reported by the RedHat folks that indicates a race condition between two things trying to release the same accessible. See comment #4 for the description. Assessment of risk is also in the bug. I wouldn't respin for this, but if it could tag along if RC2 is being done anyway, that would be very good I think. This can happen with other ajax-enabled stuff as well. (Has patch, has review)
-*'''[RC2?][has-patch,has-review]'''{{Bug|432869}} - Divide by zero in IsProbablyForLayout(). This came up while triaging crash-stats. It is a simple check for certain types of layout tables to make sure we never divide by zero. Was probably missed during review of another bug's patch. Again, for safety reasons, it would be good to have this, but not blocking the release if 3.0.1 is only 4 to 6 weeks away after that. headers of the message trees change when switching from folder to folder. But this can happen to any extension suing tree tables in Firefox and replacing one view with another and changing column headers, and it can happen to some types of Ajax-empowered web sites, leading to accessible tree corruptions. Again not a blocker per se, but again a good candidate to ride along on an RC2 build.
+*'''[RC2?][has-patch,has-review]'''{{Bug|432869}} - Divide by zero in IsProbablyForLayout(). This came up while triaging crash-stats. It is a simple check for certain types of layout tables to make sure we never divide by zero. Was probably missed during review of another bug's patch. Again, for safety reasons, it would be good to have this, but not blocking the release if 3.0.1 is only 4 to 6 weeks away after that. headers of the message trees change when switching from folder to folder. But this can happen to any extension suing tree tables in Firefox and replacing one view with another and changing column headers, and it can happen to some types of Ajax-empowered web sites, leading to accessible tree corruptions. Again not a blocker per se, but again a good candidate to ride along on an RC2 build.   Low risk, if we respin RC2, we should take this.
 ;Webdev or External