Download mozilla firefox for mac os x 10.2 code#

(It's actually quite possible that it's ALWAYS necessary given the code in its current state.) This works, but I'd like to tailor the reflow conditions to only do it when necessary if possible.

The sizes provided by the popup frame are only recomputed in layout, so I'm doing this by forcing a reflow on the frame in nsMenuFrame::OpenMenuInternal, before calling ActivateMenu(TRUE). What I'm working on now is getting the sizes right in ActivateMenu(TRUE). Even so, I had a hard time convincing myself that it was the right thing to do. We wouldn't lose anything by doing this because the size was wrong anyway. My temporary fix was to bypass the ResizeView call during ActivateMenu(TRUE). When the bounds do change (items added to or removed from a bookmark toolbar folder), a single SizeWindow won't do any harm. Usually, the bounds of the window are the same each time the menu shows, so there really shouldn't be any SizeWindows flying around here. It reaches the widget, which is asked to resize, and there's SizeWindow #2. While that's busy painting, the frame is given a new size, appropriate for the menu-open state. This happens on all platforms (different dimensions, of course). If you're following in the debugger, you can see the tiny 3x14 popup that's supposed to represent the hidden menu. That, in turn, brings in the widget resize, and that's where the first SizeWindow comes from. When it's time to show the menu again, nsMenuFrame::ActivateMenu(TRUE) retrieves that size and passes it to nsViewManager::ResizeView. Here's what's happening: once the window's been created and then disappears, the associated nsMenuPopupFrame is given a tiny (but nonzero) size (45x210 twips in this case, taken from the frame's minimum size). You were right about it being caused by SizeWindow during an update. Note that I reported more problems with Joshs build, but this Present yesterday, before the CFRunLoop patch. I noticed it on Joshs build, but not in the nightly at that time. (see bug 298112) : the bug appeared both with and without max_viewers set. No hangs on normaalīookmarks, only folders (with pulldown menus). SO it's not related to the bookmark icons or smtg. In the new profile, I noticed that it didn't happen on the default RSSįeed (Latest Headlines, with dozens of entries), although it immediatelyĪppeared on a folder I created in the toolbar, even though the folder was stillĮmpty. I always have to force-quit the application.ġ00% reproducable, but I don't have a talkback id (it hangs, it didn't crash). Sometimes I can open the menu once, but it will Pulldown menu from the bookmarks toolbar. Since bug 282940 was checked in (CFRunLoop), Firefox often hangs when I select a Running on an old 300MHz iBook, Mac Os X 10.2.8 Mozilla/5.0 (Macintosh U PPC Mac OS X Mach-O en-US rv:1.8b2) Gecko/20050622