Firefox 6.0 Crash Report [@ uGlobalMenu::RemoveMenuObjectAt ]

Bug #821391 reported by Chris Coulson on 2011-08-05
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Global menubar extension
Critical
Chris Coulson
firefox (Ubuntu)
High
Chris Coulson
Natty
High
Chris Coulson
Oneiric
High
Chris Coulson
Changed in globalmenu-extension:
importance: Undecided → Critical
assignee: nobody → Chris Coulson (chrisccoulson)
status: New → Triaged
Changed in firefox (Ubuntu Oneiric):
assignee: nobody → Chris Coulson (chrisccoulson)
Changed in firefox (Ubuntu Natty):
assignee: nobody → Chris Coulson (chrisccoulson)
Changed in firefox (Ubuntu Oneiric):
importance: Undecided → High
Changed in firefox (Ubuntu Natty):
importance: Undecided → High
status: New → Triaged
Changed in firefox (Ubuntu Oneiric):
status: New → Triaged
description: updated
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 6.0~b5+build1+nobinonly-0ubuntu2

---------------
firefox (6.0~b5+build1+nobinonly-0ubuntu2) oneiric; urgency=low

  * Update globalmenu-extension to 1.9.1
    - Drop Firefox 4 and 5 compatibility
    - Drop the uIGlobalMenuLoader interface, as it never served any purpose
    - Rework how we synchronize attributes to menuitems from their
      corresponding command nodes
    - Don't synchronize attributes from command nodes associated with menus
    - Rework how we handle document insertion/removals. Rather than keeping
      our dbusmenu structure in sync at all times, and routing the events
      to the correct node in the tree, we just mark the menu as invalid and
      rebuild it from scratch next time it opens. This should reduce problems
      like LP: #821391
    - Honour the collapsed attribute. This solves a problem with multiple
      seprators appearing adjacent to each other in the greasemonkey menu
    - Store all booleans as PRPackedBool rather than PRBool
    - Add error checking around uGlobalMenuDocListener
    - Make uGlobalMenuDummy more robust, and use it as a fallback if the
      real menuitem fails to initialize. This should help reduce problems
      like LP: #831391
    - If a menu fails to build correctly, mark it invalid and stop processing
      document events on it (which should avoid the crash in LP: #831391)
    - Invalidate a menu if we fail to insert/remove a node whilst processing
      a document event (which should help avoid the crash in LP: #831391)
    - Make uGlobalMenu::CanOpen() respect the collapsed attribute
    - Allow more than one menu node to register as a listener for any DOM
      node. In the case of command nodes, these may be shared across multiple
      menu nodes, with each one interested in receiving events. Previously, we
      just erased the first listener if a second menu node tried to register
      (discovered after adding error checking around uGlobalMenuDocListener)
 -- Chris Coulson <email address hidden> Tue, 09 Aug 2011 18:29:02 +0100

Changed in firefox (Ubuntu Oneiric):
status: Triaged → Fix Released
Chris Coulson (chrisccoulson) wrote :

Well, "fixed" is more like "rewritten tonnes of stuff to hopefully work around a problem that I haven't figured out yet, and hope for the best" :/

Changed in firefox (Ubuntu Natty):
status: Triaged → Fix Released
Changed in globalmenu-extension:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers