Closed Bug 38457 Opened 24 years ago Closed 24 years ago

Freezes on mouseover "bookmarks" in menu bar, or clicking on "bookmarks" in location toolbar.

Categories

(Core :: XUL, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED WORKSFORME
Future

People

(Reporter: gerbilpower, Assigned: mikepinkerton)

References

Details

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
Closed: 24 years ago
Resolution: --- → REMIND
hrm, this should be wfm, reopening
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
really WFM
Status: REOPENED → RESOLVED
Closed: 24 years ago24 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.