SUMMARY Freezes on mouseover of menu bar STEPS TO REPRODUCE 1. Launch Mozilla 2. Move the mouse cursor over and across the different items in the menu bar (ex, File, Edit, Help) EXPECTED RESULT Each item highlights when mouse is over them ACTUAL RESULT After 1 or 2 highlights, the entire build freezes. SYSTEM TESTED Windows 98 SE, 96 MB RAM, AMD K6-2 450MHz BUILD TESTED 2000050708
sounds like recent bug 38136 but that was marked fixed same day (May 4th)
Well it looks like the freeze is only temporary, not a crash type freeze. A minute or two after the freeze it returns to normal, and doesn't exhibit this behavior again, so this isn't as serious. But still, this is an annoying problem, and build 2000050808 still shows this.
Severity: blocker → normal
how big is your bookmarks list? i've never seen it freeze for that long of a time....
Status: NEW → ASSIGNED
Target Milestone: --- → M20
I have rarely ever mess with the bookmarks, so the default stuff that comes with Mozilla. Let me see if I can reproduce this on other computers, but I won't be able to do that until tomorrow (tomorrow = May 9, 2000).
I managed to test build 2000051011 on a Windows 95 Pentium II system but was not able to reproduce this bug. And I can still reproduce this bug regularly on my computer (Win98SE, AMD K6-2). If someone using Win98 on an AMD can test this out, maybe we can see if the AMD has anything to do with this?
If this helps, here's a little bit of info when I tested this bug with the console running: Entry at index 0 is http://www.mozillazine.org/ WEBSHELL+ = 6 WEBSHELL+ = 7 Document: Done (214.32 secs) Document http://www.mozillazine.org/ loaded successfully The 214.32 seconds being now long it seemed to have froze before returning to normal, but this is only from moving the mouse across the menu bar, it was not loading any URL at the time just before the freeze.
(Saw this bug link from the newsgroups) This sounds actually like a system problem. In my time in service, and on my own machine in the past, I've seen this happen with other apps, identical symptoms. Before my last upgrade/overhaul, I had problems with Windows Explorer doing this. I'd have to kill another process to unlock Explorer. It would happen when I'd have been online previously, and disconnected, but RNAAPP was still active on the task list. If I'd kill it, Explorer would unlock. Since I overhauled my hardware AND OS, I've not had the problem. This is a case-by-case problem, usually. I've had clients who've had identical situations with pther apps and combinations. A particularly nasty one was Published and his HP Printer driver software. Who's that for a combination! He'd go to print, but have to kill the printer app to unfreeze Publisher. Sometimes it'd work, sometimes not. What seems to happen, is Windows doesn't seem to switch focus correctly from process to process. I think it's related to GDI.EXE and USER.EXE heap leakage, since I've never (never ever) seen this happen without several apps open, or at least having used multiple apps, and closing them. I bet if you boot up, and open Eudora and Moz ONLY and first, you'll notice no problems. ICQ and AIM tend to leak a lot in certain system configurations. Try recreating this bug on a fresh reboot, without too many apps open (system tray apps too). If you get it quickly after reboot, let me know, I'll see what I can find.
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
Unfortunately Grey, I did that, and still. I rebooted Windows, closed every single program so thing except Explorer was running, launched build 2000052508, and I still get this freeze. Did it a couple times with the exact same frustrating result. This is a wild guess but the only thing that I have not singled out yet is my AMD processor. Most people have Intels, but I haven't been able to find someone with an AMD K6-2 to see if we can finally find the cause of this bug. I updated the summary to be more accurate.
Summary: Freezes on mouseover of menu bar → Freezes on mouseover "bookmarks" in menu bar, or clicking on "bookmarks" in location toolbar.
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.
QA Contact: sairuh → jrgm
AMD processors implement every instruction that Intel processors do, and the K6x series actually performs integer operations faster than the equivalent Intel chip in most cases. You are not going to find a compatibility issue between AMD and Mozilla. I've been testing Mozilla on systems that are strictly non-Intel (no "Intel Inside" for me) and have yet to run into any related problems.
Well it was a rather wild guess, since I crossed out all other possibilities I could think of so far 8P
does this still happen on recent builds, like PR3 or later?
*** Bug 47472 has been marked as a duplicate of this bug. ***
Well, I've never seen this, so ... One thing that could be considered is a particular type of file:// or ftp:// bookmark and the content for it being constructed (although this bug report only says 'hover over' not 'open' the menu. But I believe that RDF has been taught to not be to eager in content creation anymore.
For some reason, when I first filed this bug back in May, I was the only one experiencing it and kept experiencing it until about August. Is anyone else seeing this? Because I don't anymore, and think it's time to finally mark this WORKSFORME if no one else has any complaints.
I think we can take this as a WFM. (But reopen if you see it again). Thanks for following up!
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → REMIND
hrm, this should be wfm, reopening
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
<Insert obligatory, hollow claim that "I didn't really do that, did I?">
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.