Closed Bug 298502 (macdropdownhang) Opened 19 years ago Closed 19 years ago

[10.2] empty pulldown menu and Firefox hangs (regression after bug 282940)

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jo.hermans, Assigned: mark)

References

Details

(5 keywords)

Attachments

(4 files)

output of "sample firefox 20"
7.37 KB, text/plain
Details
Always reflow when opening the menu (for reference only)
2.10 KB, patch
Details | Diff | Splinter Review
Reflow when opening a closed menu
2.04 KB, patch
roc
: review+
roc
: superreview+
dveditz
: approval1.8.0.1+
dveditz
: approval1.8.1+
Details | Diff | Splinter Review
As checked in on branches
2.05 KB, patch
Details | Diff | Splinter Review 
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050622
Firefox/1.0+
running on an old 300MHz iBook, Mac Os X 10.2.8

Since bug 282940 was checked in (CFRunLoop), Firefox often hangs when I select a
pulldown menu from the bookmarks toolbar. Sometimes I see an empty window (no
icons) and the wheel-of-death. Sometimes I can open the menu once, but it will
hang the second time. I always have to force-quit the application.

100% reproducable, but I don't have a talkback id (it hangs, it didn't crash).
I'll try a kill signal in a few minutes. It didn't help when I created a new
profile. In the new profile, I noticed that it didn't happen on the default RSS
feed (Latest Headlines, with dozens of entries), although it immediately
appeared on a folder I created in the toolbar, even though the folder was still
empty. SO it's not related to the bookmark icons or smtg. No hangs on normaal
bookmarks, only folders (with pulldown menus). Also not related to the bfcache
(see bug 298112) : the bug appeared both with and without max_viewers set.

I had reported it on
<http://weblogs.mozillazine.org/josh/archives/2005/06/firefox_and_thu.html> when
I noticed it on Joshs build, but not in the nightly at that time. Also was not
present yesterday, before the CFRunLoop patch. So it's definetely related to
that patch. Note that I reported more problems with Joshs build, but this
nightly build is a lot better.
I'm running Jaguar (Mac OS X 10.2.8), and it's a old and slow iBook (300MHz), so
it might be an event-related issue that won't be experienced by everyone. I'm
now trying to see where else I can get Firefox to hang.
no corefile yet, but I have a talkback ID : TB6896889E
Note about the talkback-report : I tried to generate a coredump with kill -SEGV,
but I got a talkback report instead. That's why you see that it's killed by a
signal.
A better way to get the stack would be to sample the hung process with Sampler,
and attach the report here.
Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2)
Gecko/20050622 Firefox/1.0+ on a 1.5ghz powerbook running 10.4.1 and a 400mhz
imac running 10.3.9 it doesn't beachball for me. However, the open in tabs
option is replaced by a blank area the second time the popdown menu is
activated. Mousing over other popdown folder menus and then back will some times
cause it to appear properly.
I don't have Sampler installed (or anything else of the dev.tools), so I can't help.

But recently, I noticed that the bug changed a bit. Now, it almost never hangs
the first time the pulldown menu is shown, but 100% of the time it will hang the
second time. And I've also see it hang when a form-completion menu is shown, but
that's not 100% repeatable. I haven't seen any other hangs in other menus
(context-menu for example).

PS: I've seen bug 299384 too, but its fix didn't help. It was a crash anyway,
not a hang.
reporter: Activity Monitor has a sample button in the process properties pane.
(In reply to comment #7)
> reporter: Activity Monitor has a sample button in the process properties pane.

Not in Jaguar (where it's still called Process Viewer). And I don't have enough
diskspace to install the full developers tools (over 500 MB) for Jaguar, never
mind the newer ones.
Assignee: nobody → sfraser_bugs
Assignee: sfraser_bugs → nobody
Can anyone reproduce this other than Jo? BTW, white areas in the bookmark
toolbar menus are bug 289973.
Whiteboard: needinfo
(In reply to comment #9)
> BTW, white areas in the bookmark toolbar menus are bug 289973.

Note: bug 289973 didn't fix this.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050721
Firefox/1.0+
Jo, we still need more info from you to be able to fix this. Hop onto the
#camino irc channel sometime (irc.mozilla.org).

    
    

    
  
This is a deadlock in CGSRWLockLockForWriting on the SizeWindow call. I bet it's
10.2 only.
Summary: empty pulldown menu and FF hangs (regression after bug 282940) → [10.2] empty pulldown menu and FF hangs (regression after bug 282940)
Whiteboard: needinfo

    
    

    
  
(In reply to comment #13)
> This is a deadlock in CGSRWLockLockForWriting on the SizeWindow call. I bet it's
> 10.2 only.

This seems to be one of the bugs that could be fixed by going to Cocoa widgets.

    
    

    
  
*** Bug 318515 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 312111 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 318492 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 315467 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 318594 has been marked as a duplicate of this bug. ***

    
  
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?

    
  
Component: Toolbars → Bookmarks
Keywords: hang, 
          
            helpwanted
Version: Trunk → unspecified

    
  
QA Contact: toolbars → bookmarks
Assignee: nobody → mark
Component: Bookmarks → Widget: Mac
Product: Firefox → Core
Version: unspecified → Trunk

    
  
QA Contact: bookmarks → mac
Summary: [10.2] empty pulldown menu and FF hangs (regression after bug 282940) → [10.2] empty pulldown menu and Firefox hangs (regression after bug 282940)

    
    

    
  
I'm a stupid user, but it seems to happen when you click a bookmarkfolder in the Bookmarks Toolbar Folder for the second time after starting Firefox and when you have a pulldown menu on a form element (remembered values for a text box). It seems to be happening on Mac OSX 10.2.8. See http://forums.mozillazine.org/viewtopic.php?p=1914080#1914080 for discussion of users.

Firefox 1.07 does not show this behaviour, version 1.5 does.

    
    

    
  
*** Bug 318854 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 318634 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 318215 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 318754 has been marked as a duplicate of this bug. ***

    
    

    
  
I need to understand the prognosis of this bug. It is not clear from the entries, but people seem to be saying it's 10.2's fault. I read that as meaning Mozilla will not fix it because they cannot. That is certainly not clearly stated, but it is clearly *implied*.

Don't you think this proves that Firefox 1.5 isn't compatible with 10.2? Shouldn't the stated compatibility of 1.5 be changed to 10.3 and above?

    
    

    
  
I posted a dupe awhile back, and if it's Jaguar's fault, why does 1.0.7 work fine? Somehow I feel that the bug can and should be attended to. It would be a shame to make Firefox 1.5 incompatible with the first "cat name" release of Mac OS X.

    
    

    
  
Experiencing this in OS X 10.2.8 on a 400 MHz G3. I get the spinning beach ball and have to force-quit; no talkback option. At first I thought it was corruption in my bookmarks, so I deleted them (and the backup files). I then cleaned all traces of 1.5 off my system and reinstalled. Using only the default bookmarks set, I find that FF hangs *every time* when I click on the Latest Headlines folder a second time. I also found that the problem does not occur if I open the same bookmarks from the left panel after opening it with Command-b.

I did not have this problem on 1.0.7.

I'm going to have to revert.

    
    

    
  
(In reply to comment #26)
> I posted a dupe awhile back, and if it's Jaguar's fault, why does 1.0.7 work
> fine? Somehow I feel that the bug can and should be attended to.

I fully agree.
If I understand the initial bug description correctly, this bug was introduced with the switch of plevent handling to CFRunLoopSources.
The interesting thing is, Camino has been using CFRunLoopSources for some time now, and it still runs fine in Jaguar, whereas FF 1.5 does not.

    
    

    
  
Comment 13 explains the cause of this bug. I do not believe that the cause was the CFRunLoop changes, but rather bug 288117 or something like it. I would not be surprised if this regressed at the same time as bug 289973.

The cause is that Firefox is trying to resize a window while updating the window (i.e. painting it). That seems to trip up a bug in 10.2.

If you want to find out what caused this, go back through the nightly builds, testing on 10.2 to find the first build in which this bug occurs (binary search will help, and you'll have to know whether to test branch or trunk builds, which I don't offhand).

Does this mean that Firefox is not "compatible" with 10.2? I guess so, though compatibility is always a relative term.



    
    

    
  
(In reply to comment #29)
> Comment 13 explains the cause of this bug. I do not believe that the cause was
> the CFRunLoop changes, but rather bug 288117 or something like it. I would not
> be surprised if this regressed at the same time as bug 289973.

No, I'm pretty sure that it was the CFRunLoop changes (indirectly probably). See <http://weblogs.mozillazine.org/josh/archives/2005/06/firefox_mac_bui.html> (the url in comment 0 seems to be wrong).

I first noticed it in Joshes experimental build on June 18th ; it wasn't present in the trunk build at that time (I'm a daily tester). It wasn't caused by the bfcache changes, which we were also experimenting at that time (that's why I mentioned it in the url). The trunk build didn't have those changes, until the moment that the CFRunloop chnages were checked in (the 21st). I filed this bug the day after, when I tested the nightly build. The build of June 20th did not have this bug.

    
    

    
  
> Does this mean that Firefox is not "compatible" with 10.2?
> I guess so, though compatibility is always a relative term.

Well, let me ask you something: Is an application "compatible" if you may select any individual menu exactly once for the entire time you run the application, otherwise the program hangs and you have to force-quit?

This is a serious showstopper bug for 10.2 users. The evidence is accumulating that it is a bug Mozilla *can* fix. The options are fixing it or not fixing it; in the latter case, it's incumbent upon Mozilla to honestly state the true compatibilty of Firefox 1.5, namely OS X 10.3 and later. 

    
    

    
  
*** Bug 319208 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 318476 has been marked as a duplicate of this bug. ***

    
    

    
  
Same problems as other users have indicated. It's so frequent that I have removed 1.5 and gone back to using 1.0.7.

    
    

    
  
Same problem as previously described running on 10.2.8; even occurs in fresh, clean install in safe mode; only experienced since installed 1.5 - will have to revert if not fixed.

    
    

    
  
As a workaround, the hangs can largely be avoided by disabling 'Save information I enter in forms and in the Search Bar' under Preferences -> Privacy -> Saved Forms, although this is a fairly major inconvenience. The hangs can also happen with the pulldown menus on the 'back' and 'forward' buttons though, so cannot necessarily be entirely avoided.

    
    

    
  
I believe I had that disabled, but the the hanging still occurred in the bookmarks dropdown.

    
    

    
  
(In reply to comment #36)
> As a workaround, the hangs can largely be avoided by disabling 'Save
> information I enter in forms and in the Search Bar' under Preferences ->
> Privacy -> Saved Forms, although this is a fairly major inconvenience.

No, I always have this disabled but I still get the bookmarks dropdown hang.

    
    

    
  
Same problem here. I just joined b/c I so so so want wonderful tech genius people to fix this. Hangs on drop-down menu folders, 10.2.8, pBook G4 867MHz. Thanks.

    
    

    
  
(In reply to comment #36)
I always disable this feature, but FF 1.5 hangs nevertheless.

    
    

    
  
Could this have caused issues with autocomplete drop downs as well? See bug 314474, bug 319747 (and dupes).

    
    

    
  
*** Bug 314474 has been marked as a duplicate of this bug. ***

    
  
Blocks: 319747

    
    

    
  
*** Bug 320560 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 319747 has been marked as a duplicate of this bug. ***
No longer blocks: 319747

    
    

    
  
I am experiencing this self-same bug, pulldown menus on Bookmarks Toolbar display 1st time then, open blank and hangs Firefox second time. I was just going to report this, but found this entry and had to provide info about experiences with it. Also, Firefox hangs when pulldown menus open for selection of form input (2nd time also). Turning off Save Form input clears this up.

Software: MacOS X 10.2.8 (Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC), Firefox 1.5 (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5), ext: Adblock 0.5.2.056, Tabbrowser Prefs 1.2.8.8, Forcastfox 0.8.2.5, Disable Targets for Download 1.0, DOM inspector 1.8, Talkback 1.5. 

Hardware: Macintosh G4, AGP graphics version, 1gb RAM with 1.4 GHz CPU ugrade  installed (was dual 450 MHZ)

I have no trace or stack info, I had not gotten very far into confirming the reproducability of this bug.

    
  
Alias: macdropdownhang

    
    

    
  
*** Bug 320762 has been marked as a duplicate of this bug. ***

    
    

    
  
I couldn't help but notice that the system requirements for 1.5 now say OS X 10.3. Does this mean that this bug will go unresolved?

    
    

    
  
------- Comment #47 from trashmemozilla@mytrashmail.com  2005-12-19 16:53 PST -------
I couldn't help but notice that the system requirements for 1.5 now say OS X
10.3. Does this mean that this bug will go unresolved?


Yep, means exactly that, unless anyone wants to take on a fix... Good, though, that incompatability with 10.2.8  has been recognised.


But Mozilla 1.5 is now dead in the water for many Mac users.  I am using Opera now, perfectly happy. bye, Mozilla...



    
    

    
  
------- Comment #47 from trashmemozilla@mytrashmail.com  2005-12-19 16:53 PST -------
I couldn't help but notice that the system requirements for 1.5 now say OS X
10.3. Does this mean that this bug will go unresolved?


Yep, means exactly that, unless anyone wants to take on a fix... Good, though, that incompatability with 10.2.8  has been recognised.


But Mozilla 1.5 is now dead in the water for many Mac users.  I am using Opera now, perfectly happy. bye, Mozilla...



    
    

    
  
This bug didn't seem to be getting fixed, so I asked that the system requirements be changed, at least for the time being, to accurately reflect Firefox's compatibility. Stephen, what's the reason you are not using 1.0.7? Is Opera better? I haven't used it much. Thanks. Take care.

    
    

    
  
(In reply to comment #50)
> This bug didn't seem to be getting fixed, so I asked that the system
> requirements be changed, at least for the time being, to accurately reflect
> Firefox's compatibility. Stephen, what's the reason you are not using 1.0.7? Is
> Opera better? I haven't used it much. Thanks. Take care.
> 

Yes, I'm finding Opera better. Occasional problems with html on some sites, but on the whole it works well. I particularly like its 'wand' tool for remembering passwords and log-ins. Was recommended by a friend who's an IT consultant - he now uses it in preference to Firefox/Mozilla on both Mac and PC.

    
    

    
  
(In reply to comment #51)
> Yes, I'm finding Opera better

What does this have to do with this bug?

    
    

    
  
Investigating.

I've found something promising given the comments in this bug, but I haven't tested on Shagwire yet.  Stay tuned.

    
    

    
  
Good news!

I've confirmed by testing on the Jag that I've found the cause of the bug.  The solution might be a little tricky, I'm working on it.

    
    

    
  
*** Bug 321957 has been marked as a duplicate of this bug. ***

    
    

    
  
(In reply to comment #54)
> Good news!
> 
> I've confirmed by testing on the Jag that I've found the cause of the bug.  The
> solution might be a little tricky, I'm working on it.

You mean the one I mentioned in comment 13?

    
    

    
  
You were right about it being caused by SizeWindow during an update.  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).  When it's time to show the menu again, nsMenuFrame::ActivateMenu(TRUE) retrieves that size and passes it to nsViewManager::ResizeView.  That, in turn, brings in the widget resize, and that's where the first SizeWindow comes from.  Repainting is async.  If you're following in the debugger, you can see the tiny 3x14 popup that's supposed to represent the hidden menu.  This happens on all platforms (different dimensions, of course).

While that's busy painting, the frame is given a new size, appropriate for the menu-open state.  It reaches the widget, which is asked to resize, and there's SizeWindow #2.

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.  When the bounds do change (items added to or removed from a bookmark toolbar folder), a single SizeWindow won't do any harm.

My temporary fix was to bypass the ResizeView call during ActivateMenu(TRUE).  This gets things rolling on Jaguar.  We wouldn't lose anything by doing this because the size was wrong anyway.  Even so, I had a hard time convincing myself that it was the right thing to do.

What I'm working on now is getting the sizes right in ActivateMenu(TRUE).  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).  This works, but I'd like to tailor the reflow conditions to only do it when necessary if possible.  (It's actually quite possible that it's ALWAYS necessary given the code in its current state.)

Or, in 500 words or less: should be fixed in 1.5.0.1.
Status: NEW → ASSIGNED

    
  
Component: Widget: Mac → Layout

    
    

    
  
(In reply to comment #57)
> Or, in 500 words or less: should be fixed in 1.5.0.1.

Thank you very much!  I'm eagerly awaiting this fix.  Currently, I'm using Mac OS X 10.2.8, and am looking for a useful browser in which to do most of my work.

I use Safari 1.0.3 (v85.8.1) most of the time, but it doesn't include the option to save Web pages in "Web Page, complete" format.

Firefox 1.0.7, on the other hand, is incompatible with version 2.8 of my favorite GrApple (Classic Pro) theme, which has the "Pinstripe" icons by Stephen Horlander, and Aronnax`s Web site ( http://www.grapple.net.tf/ ) is down at the moment, so I can't retrieve an earlier version.  Besides, it's very depressing to be forced to stick to an outdated version.

I checked out Opera 8.51.2182, but either it doesn't have an option to create folders in the Personal Bar (apparently, its equivalent of the Bookmarks Toolbar), or I can't figure out how to do that.  I need the option to create folders with pull-down menus in the equivalent of the Bookmarks Toolbar.  Besides, it has some strange keyboard shortcuts (e.g., Cmd-T doesn't create a new tab, but Cmd-N does).

Camino 1.0 beta 2 lack multilingual support.  Camino 0.8.4 multilingual is outdated, and underpowered compared to Firefox 1.5.  In addition, Camino 0.8.4 does not display certain Web pages (such as my Yahoo! Mail Inbox) in as easy-to-read a layout at does Firefox 1.5: The characters either are too small, or too large (when sized up to the next size).

As a last resort, I also checked out OmniWeb 5.1.2, but it isn't free.  In addition, to my astonishment, although it had options to save the HTML alone, or the linked images, or the linked documents to any Web page, it didn't have any equivalent of the "Web Page, complete" format.

If anybody knows of any other interim alternatives, please post a comment here.

    
    

    
  
(In reply to comment #58)
> If anybody knows of any other interim alternatives, please post a comment here.

Please don't.  There are other good fora for that type of discussion, see http://forums.mozillazine.org/ as a good start.

    
    

    
  
(In reply to comment #57)
> While that's busy painting, the frame is given a new size, appropriate for the
> menu-open state.  It reaches the widget, which is asked to resize, and there's
> SizeWindow #2.

From here?
http://lxr.mozilla.org/seamonkey/source/view/src/nsViewManager.cpp#2042
We could just add a hack to disable that on Jaguar. It will lead to increased flicker in a few situations, that's all.

    
    

    
  
(In reply to comment #60)
> From here?
> http://lxr.mozilla.org/seamonkey/source/view/src/nsViewManager.cpp#2042

Not quite.  The stack looks like this:

       nsView::ResetWidgetBounds             nsView.cpp:375
nsViewManager::ProcessPendingUpdates  nsViewManager.cpp:1610
nsViewManager::ProcessPendingUpdates  nsViewManager.cpp:1616
nsViewManager::FlushPendingUpdates    nsViewManager.cpp:4409

> We could just add a hack to disable that on Jaguar. It will lead to increased
> flicker in a few situations, that's all.

I'd rather not do a workaround.  When a dormant already-existing popup menu wants to activate, we're sizing it to the minimum size during the first pass through ResetWidgetBounds (called by nsView::SetDimensions), which is wrong on any platform, but only causes a hang on Jaguar.  The second pass through ResetWidgetBounds is what brings the view size back to what it should be.

Just a sec, I got something for ya.

    
    

    
  


  
This fixes the bug by always reflowing in nsMenuFrame::OpenMenuInternal(TRUE) before calling nsMenuFrame::ActivateMenu(TRUE), whether it needs it or not.  For reference only.  The next patch is probably better.

    
    

    
  


  
This adjusts the existing initial-reflow logic to do the reflow any time the menu is transitioning from closed to open.  That includes the current initial reflow case (when mLastPref.height == -1, mMenuOpen is always FALSE, these are the initial values set in the constructor) as well as the cases that are causing the problem now, when existing-but-closed menus are reaching this point without having been sized back to their "open" size.

        Attachment #207261 -
        Flags: superreview?(sfraser_bugs)

        Attachment #207261 -
        Flags: review?(roc)

    
    

    
  
P.S. Happy new year, roc!  :)

    
    

    
  
Thank you Mark.
Kicking a gift horse right in the teeth, does anybody have an ETA for the next dot release?

    
    

    
  
blocker per drivers
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1+

    
  
Keywords: regression

    
    

    
  
Comment on attachment 207261 [details] [diff] [review]
Reflow when opening a closed menu

Still needs review

        Attachment #207261 -
        Flags: superreview?(sfraser_bugs)

        Attachment #207261 -
        Flags: superreview+

        Attachment #207261 -
        Flags: review?(roc)

        Attachment #207261 -
        Flags: review+

    
    

    
  
Checked in on trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
  

        Attachment #207261 -
        Flags: approval1.8.1?

        Attachment #207261 -
        Flags: approval1.8.0.1?
Keywords: qawanted

    
    

    
  
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060109 Firefox/1.6a1

I'm currently testing the latest trunk on Mac OS X 10.2.8, and the bug seems indeed to be fixed.

I could see the extra reflow in a few places, like when the chevron appears (when the toolbar is too large for the display) : the menu popups up with an incorrect size, then jumps to the new position while resizing. Nothing bad though, it's only the first time.

    
    

    
  
Looks good using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060109 Firefox/1.6a1. Verifying fixed on the trunk.
Status: RESOLVED → VERIFIED

    
    

    
  
I guess setting mMenuOpen later wasn't an option?

    
    

    
  
No, mMenuOpen is used when computing the size.
Keywords: qawanted

    
    

    
  
Comment on attachment 207261 [details] [diff] [review]
Reflow when opening a closed menu

a=dveditz for drivers

        Attachment #207261 -
        Flags: approval1.8.1?

        Attachment #207261 -
        Flags: approval1.8.1+

        Attachment #207261 -
        Flags: approval1.8.0.1?

        Attachment #207261 -
        Flags: approval1.8.0.1+

    
    

    
  
Fixed on 1_8 and 1_8_0.
Keywords: fixed1.8.0.1, 
          
            fixed1.8.1

    
    

    
  


  
The original patch did not apply cleanly due to context.  This patch contains context matching the branches.

    
    

    
  
(In reply to comment #70)
> I'm currently testing the latest trunk on Mac OS X 10.2.8, and the bug seems
> indeed to be fixed.
> 
> I could see the extra reflow in a few places, like when the chevron appears
> (when the toolbar is too large for the display) : the menu popups up with an
> incorrect size, then jumps to the new position while resizing.

FWIW, this was already happening anyway (on 10.3.9 at least).

    
    

    
  
There are a couple of reports that this isn't fixed in 1.5.0.1:

http://forums.mozillazine.org/viewtopic.php?t=367282

Can someone QA this on Jaguar and verify it on the branch?  (Jo?)
Keywords: qawanted

    
    

    
  
(In reply to comment #78)
> There are a couple of reports that this isn't fixed in 1.5.0.1:
> 
> http://forums.mozillazine.org/viewtopic.php?t=367282
> 
> Can someone QA this on Jaguar and verify it on the branch?  (Jo?)
> 

Since this is fixed, I haven't seen the bug anymore, and I'm using Mozilla at least an hour per day. I'm normally not used formhistory all the time, but I have tested it with it as well.

Could it be a timing issue (I'm on very slow hardware), or related to an extension ? If it was me, I would verify this bug as fixed.

Note that we've had several bugs like this before, maybe it's one of them.


    
    

    
  
*** Bug 318283 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 315982 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 325130 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 325216 has been marked as a duplicate of this bug. ***

    
    

    
  
I just installed the 1.5.0.1 update (running 10.2.8) and I'm still getting the hang on saved form data. The other hangs I was experiencing previously, in the bookmarks dropdown menus and in the browse back dropdown menu, appear to have been fixed. Is there another bug for saved form data that I missed or is this only a partial fix?
Thanks for all the help.

    
    

    
  
(In reply to comment #84)
> I just installed the 1.5.0.1 update (running 10.2.8) and I'm still getting the
> hang on saved form data. The other hangs I was experiencing previously, in the
> bookmarks dropdown menus and in the browse back dropdown menu, appear to have
> been fixed. Is there another bug for saved form data that I missed or is this
> only a partial fix?
> Thanks for all the help.
> 

Exactly the same results here.

    
    

    
  
for those who may have overlooked this there is another seemingly related bug reported, although some of the symptoms may be different (see 
Bug #319747)

    
    

    
  
To note this bug is NOT the same as Bug 319747 as it has nothing to do with minimization or loss of focus. it also is unaffected by the carret or cursor. I can confirm after testing further, the Bug is still alive and well and is planning  to set up home having decided that it is happy living in the depths of the firefox code and feals there is little reason to move on anytime soon... ok so i am going a little nuts, but this bug seems to keep reoccuring, having been with us for a LONG time and a fix is some way off (given the evidence).

Oh and to the suggestion it has anything to do with slow or idling machines, processes, or hardware components... i have news... no it isnt anything to do with that at all.

NB: can we get this bug reopened or move this thread over to Bug 318283

    
    

    
  
I dont see why this bug is dependent on bug 282940, they seeme to de related only tenuously. bug 282940 being related to timing and event handeling?! or am i misreading/misunderstanding. also why should this bug block bug 319747... an open bug that is still withus dispite this bug report being closed!? anyone?

    
    

    
  
Additionally with recent upgrade to FF Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 form fills with drop down as you type ability cause similar results as drop down as reported [Bug 325216] (eg. utilizing Google to perform search autofill drops with blank results that causes firefox to hang indefinately) on Mac OS 10.2.8

    
    

    
  
This bug should probably be reopened.  After switching to the latest release candidate, the problem is indeed fixed in the bookmarks toolbar, but it still occurs in search boxes or whenever a form-autofill dropdown occurs for the second time.

    
    

    
  
Go to bug 318283.

    
    

    
  
*** Bug 322431 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 327734 has been marked as a duplicate of this bug. ***

    
    

    
  
If you've been directed to this bug because Firefox is hanging for you under 10.2, and you upgrade to 1.5.0.1 and still find that it hangs, you're proabably hitting bug 318283, fixed for 1.5.0.2.

    
    

    
  
Why is this closed?  If ff is not compatible with 10.2 then the system requirements page (http://www.mozilla.com/firefox/system-requirements.html) need to be changed.  If this is "fixed" in 1.5.0.2, which as of 06 Mar 06 has not been released, shouldn't this still be an open bug?  Where is 1.0.7 archived?  That was I can switch back to a browser that work...

    
    

    
  
*** Bug 326099 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 332469 has been marked as a duplicate of this bug. ***

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: