STEPS TO REPRODUCE: 1. Connect to Weave 2. From Weave Context menu, choose "Sync Now", to make sure you're fully synchronized. (Not sure if this is required, but it's the state I've been in when I've reproduced this.) 3. Severely rate-limit your network connection. On Ubuntu Linux: "sudo wondershaper eth0 10 10" 4. Open Weave Context menu, and choose "Sync Now" 5. Immediately re-open Weave Context menu and choose "Activity Log" (while you're syncing) RESULT: * Crash * ALSO: The next time I start Firefox & connect to Weave, Weave performs a full sync (with "First sync, uploading all items" showing up in the activity log) Crash reports: http://crash-stats.mozilla.com/report/index/6885b562-9156-4da8-949a-d298d2091103 http://crash-stats.mozilla.com/report/index/f7622986-9d96-4721-92eb-26ce92091103 Version Info: Weave version 0.8 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091103 Minefield/3.7a1pre

This should be fixed by bug 526661 now that Firefox just does a plain file load instead of a continuous incremental read while the service is also writing to the file.

Nope, not fixed by that bug. I'm using Weave 1.0b1pre now, and I just hit this crash again, accidentally. I then tried to reproduce it intentionally using steps from comment 0, and was easily able to do so. Crash reports for these instances: http://crash-stats.mozilla.com/report/index/e7fd326e-7894-456b-8f53-0eb1e2091109 http://crash-stats.mozilla.com/report/index/88d9d633-7ab0-4bbf-95c7-2aca12091109 I presume that Bug 526661's patch is included in this Weave version, because now when I view the activity log (without crashing :)), it appears in a Firefox tab.

[Removing "over a slow connection" from summary, since that's not actually required to reproduce the bug -- it just makes it _easier_ to reproduce. I've hit this crash while using a non-rate-limited connection at the Mozilla office -- that was the first crash report in Comment 2.]

Looks like this crash is cross-platform. I just searched the crash reports for this signature, and there are 6 instances of this crash on Windows, and 21 on Mac, during the past two weeks. (Also -- one Mac crash had the comment "tried to open weave's activity log while syncing") http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=nsXULPopupManager%3A%3AHidePopupsInDocShell%28nsIDocShellTreeItem*%29&date=&range_value=2&range_unit=weeks&do_query=1&signature=nsXULPopupManager%3A%3AHidePopupsInDocShell%28nsIDocShellTreeItem*%29

This crash also happens if I choose "Preferences" from the Weave context menu in step 5 of STR, btw. A crash report from doing that looks pretty much the same as the others here: http://crash-stats.mozilla.com/report/pending/f8dd8927-35a1-4cda-aa4b-078a82091112 No crash when I click the "Last Update" entry at the bottom of the context menu, though. (Though that does make the context menu go away)

I just tried to see if I could reproduce this from the "Tools | Weave" sub-menu, but that sub-menu actually **won't open** while weave is syncing!! This is true when I'm doing an incremental sync (with my network connection slowed down to make it take longer), as well as when I'm doing a full initial sync (after having clicked "start over" in Weave's preferences and re-entering my credentials). Additionally: if I open the weave context-icon's menu _while it's syncing_, clicking elsewhere (e.g. on a webpage) doesn't dismiss the context menu like it normally does. I'm guessing that these menu issues are related to whatever's broken here...

Do you remember what's in the status bar when it crashes? It's the act of clicking on Activity Log (or Preferences) that causes the crash and not just highlighting it? I haven't been able to reproduce this on os x 3.5. According to the crash stats, it seems to happen on all versions of firefox on all platforms.

Oh, well I just crashed on this stack: http://crash-stats.mozilla.com/report/index/bp-fb81b303-cfe1-4715-8cd4-68f922091112 But this happened when I was trying to quit Firefox 3.5.5.

(In reply to comment #7) > Do you remember what's in the status bar when it crashes? Just the spinning circular icon and my username. (If I let it complete without crashing, the spinning logo eventually changes back to the static rectangular icon, without my username text ever changing. That is to say, I guess: no new data is actually being synchronized, because nothing needs to be, per Step 2 of the STR in comment 0.) > It's the act of > clicking on Activity Log (or Preferences) that causes the crash and not just > highlighting it? I haven't been able to reproduce this on os x 3.5. Yes -- at least, that's what causes the immediate crash. Simply highlighting an entry in the menu doesn't appear to cause a crash.

(In reply to comment #9) > Simply highlighting > an entry in the menu doesn't appear to cause a crash. I take that back -- highlighting an entry in the menu *does* cause a crash, though it's delayed and has a varying signature. I've just tried this twice: - Load this page - Perform this bug's STR (but hover over an entry instead of selecting it, in step 4, and keep hovering until the sync completes) - Click in the bugzilla "Comment" textbox and start typing. --> ***CRASH*** before any characters appear My crashes from this were: http://crash-stats.mozilla.com/report/index/bp-4e04ab86-f86e-4979-aa00-1fb052091112 http://crash-stats.mozilla.com/report/index/847f7747-1719-4cd3-9f53-d9a612091112 (Note that the crash signatures are different from the one in this bug's summary, and different from each other)

Actually, amending comment 10 a bit: - Perform this bug's STR, but in step 4, simply click the Weave status-bar icon to open the menu. Don't bother moving the mouse (or clicking) after this. - Wait for the sync to complete -- this will make the menu disappear. - Press the "a" key on your keyboard. ***CRASH*** [@nsMenuPopupFrame::FindMenuWithShortcut(nsIDOMKeyEvent*, int&) ] http://crash-stats.mozilla.com/report/index/8e50337e-bc7b-4436-a158-238412091112 http://crash-stats.mozilla.com/report/index/eff05550-9aba-4621-b6cd-51c512091112

I added some dumps to sync.js and the crash appears after onMenuPopupHiding finishes. But it is indeed strange that the popup can't be dismissed by clicking away when it's potentially going to crash.

Signature nsMenuPopupFrame::FindMenuWithShortcut(nsIDOMKeyEvent*, int&) UUID 8e50337e-bc7b-4436-a158-238412091112 Time 2009-11-12 16:18:42.29446 Uptime 57 Last Crash 87 seconds before submission Product Firefox Version 3.7a1pre Build ID 20091112030932 Branch 1.9.3 OS Linux OS Version 0.0.0 Linux 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 2009 i686 GNU/Linux CPU x86 CPU Info GenuineIntel family 10 model 15 stepping 2 Crash Reason SIGSEGV Crash Address 0xb6e6700c User Comments synced weave. opened up weave's status-bar context-menu while it was syncing. After it finished syncing, the context-menu automatically closed. Then I pressed the "a" key on my keyboard, and Firefox crashed. Processor Notes Crashing Thread Frame Module Signature [Expand] Source 0 libxul.so nsMenuPopupFrame::FindMenuWithShortcut layout/xul/base/src/nsMenuPopupFrame.cpp:1306 1 libxul.so nsXULPopupManager::HandleShortcutNavigation layout/xul/base/src/nsXULPopupManager.cpp:1571 2 libxul.so nsXULPopupManager::KeyPress layout/xul/base/src/nsXULPopupManager.cpp:2019 3 libxul.so nsEventListenerManager::HandleEvent content/events/src/nsEventListenerManager.cpp:172 4 libxul.so nsEventTargetChainItem::HandleEvent content/events/src/nsEventDispatcher.cpp:250 5 libxul.so nsEventTargetChainItem::HandleEventTargetChain content/events/src/nsEventDispatcher.cpp:287 6 libxul.so nsEventDispatcher::Dispatch content/events/src/nsEventDispatcher.cpp:584 7 libxul.so PresShell::HandleEventInternal layout/base/nsPresShell.cpp:6582 8 libxul.so PresShell::HandleEvent layout/base/nsPresShell.cpp:6340 9 libxul.so nsViewManager::HandleEvent view/src/nsViewManager.cpp:1202 10 libxul.so nsViewManager::DispatchEvent view/src/nsViewManager.cpp:1181 11 libxul.so _ZL11HandleEventP10nsGUIEvent view/src/nsView.cpp:167 12 libxul.so nsWindow::DispatchEvent widget/src/gtk2/nsWindow.cpp:588 13 libxul.so nsWindow::OnKeyPressEvent widget/src/gtk2/nsWindow.cpp:3123

(In reply to comment #14) > Signature nsMenuPopupFrame::FindMenuWithShortcut(nsIDOMKeyEvent*, int&) > bp-8e50337e-bc7b-4436-a158-238412091112 (For the record, that is my first crash report from comment 11. Sorry for not having updated the bug summary at that point)

It seems like if an extension can trigger this crash, there's a core bug here, and probably one we want to fix before Firefox 3.6 ships.

The basic problem here is the following: nsXULPopupManager::mPopups ends up with multiple items (in the case I just managed to crash with, 3 items) that all have the same frame Then we call nsXULPopupManager::PopupDestroyed, passing that frame. PopupDestroyed happily destroys *only the first* of those three items and leaves the other two. Then we call nsXULPopupManager::GetVisiblePopups, it accesses the frame on the second of those three items, and we crash. Is it valid for mPopups to have multiple nsMenuChainItem objects pointing to the same frame? If it is, then the bug is in PopupDestroyed; if not, then the bug is in whatever let it get into that situation.

> Is it valid for mPopups to have multiple nsMenuChainItem objects pointing to > the same frame? I assume not. dholbert, can you take this, figure out how we get multiple nsMenuChainItem objects with the same frame, and fix it? :-)

Yup.

dholbert tracked down the weirdness in popups getting destroyed and this patch seems to fix it for him

That may work around the problem for Weave, but there is a core layout bug here which we should still fix.

Let's make bug 531075 about the core Layout problem, and return this bug here to being a Weave bug. (Note that Mardak's patch fixes other issues too -- e.g. the "Tools | Weave" issue described in comment 6 -- and I think it's a useful patch beyond being just being a workaround for the Layout issue.)

http://hg.mozilla.org/labs/weave/rev/16a2fafdeed8 Use setTimeout to allow the popup close before blocking its closing with a long operation like sync.

https://crash-stats.mozilla.com/report/index/a90e882b-64a5-478d-99ab-3995c2110430 Just got this crash. this bug is duplicate of the crash I got: 527448 ?

i.e. Bug 527448

(In reply to comment #24) > https://crash-stats.mozilla.com/report/index/a90e882b-64a5-478d-99ab-3995c2110430 > > Just got this crash. Your crash looks very different from this one. Also, this bug is fixed. Please file a *new* bug if you continue to have a problem.