Closed Bug 184890 Opened 22 years ago Closed 21 years ago

hangs when help window opened and minimized twice

Categories

(SeaMonkey :: Help Documentation, defect)

Product:
SeaMonkey
Component:
Help Documentation
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.6alpha

People

(Reporter: scowie, Assigned: rjkeller)

References

Details

(Keywords: fixed1.4.2, hang, Whiteboard: [adt3])

Attachments

(1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 If I open the Mozilla Help window via the menu (Help-->Help Contents), and then I minimize it, then restore it, then minimize it again, Mozilla will hang. In fact, my whole computer will be frozen until Mozilla is shutdown (via ctrl+alt+delete). This also results in an Explorer error. Reproducible: Always Steps to Reproduce: 1. in menu select Help-->Help Contents 2. minimize the help window 3. restore the help window (by clicking it on the task bar) 4. minimize the help window a 2nd time Actual Results: Mozilla stops responding Whole system stops responding until Mozilla is shutdown Explorer error (often causing system tray icons disappearing) Expected Results: um, not crashed :o)
Keywords: hang
Confirmed with build 2002121308 on Win98, following the steps described by the reporter. When I close Mozilla via Ctrl+Alt+Delete I get no Talkback alert, only this error, EXPLORER caused a general protection fault in module USER.EXE på adress 0006:000038e8. <snip>. There is some strange focus-issue here. When I minimize Help by clicking the "Minimize" icon the first time, the keyboard and mouse focus goes back to main Mozilla window which also get Windows active title bar colour, but any other applications inactive windows that I have open is painted on top of the Mozilla window, even though they have inactive title bar colour and no focus. With a small inactive window on top, I can still use the browser to click on links and type in new adresses, but it remains below any inactive window. If I minimize and restore Help by clicking on the button on Windows taskbar I don't get this hang. This bug is not present in 1.2alpha but it is there in 1.2beta so it could be related to bug 136647.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030202 found this bug today when I wanted repeatedly to minimize to change view between help & preferences, so this bug can easily be found by anyone looking for help. tested with talkback-eneabled zip unzipped into fresh directory, and with freshly created profile. Mozilla was hanging, or crashing explorer.exe, in file user.exe.
Flags: blocking1.3b?
Since the preferences window per definition is a dialog and can't be minimized, one shouldn't be able to minimize the help dialog either. (Windows specific)
too late, no patch, no evidence anyone's working on a patch, not a common action: really doesn't fit the definition of a 1.3b blocker
Flags: blocking1.3b? → blocking1.3b-
Bug 177622 crash if I minimize the help window while at an about: screen - has no comments - could be related to or a dupe of this one ?
No problems here, could you try telling what other XUL windows are open and their top to bottom layout and how focus changes with each minimization.
*** Bug 193898 has been marked as a duplicate of this bug. ***
Is anyone seeing this on NT/2000/XP or Linux or anything else? It might be a Win 9x-only bug.
Keywords: nsbeta1, qawanted
*** Bug 200677 has been marked as a duplicate of this bug. ***
adt: nsbeta1+/adt3 Ian, will you be able to get to this? If not, can you please reassign to an appropriate engineer? Thanks.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3]
I am not seeing this on WinXP/NS build 2003042308 or on Linux/Mozilla build 20021003.
This must be a win9x problem. It is still happening to me with Mozilla 1.4b (20030507) under win98. I guess a quick fix would be to not allow help to be minimized as suggested in #3.
*** Bug 211606 has been marked as a duplicate of this bug. ***
Bug still seen on Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 I can either press Ctrl-Alt-Del twice to reboot, or press it once, and kill Mozilla, and then Explorer crashes, producing a Exception 0d General Protection Failure in Module User.exe. In each case I´ve got to reboot, so this freeze is more annoying than a crash. With a crash I can reboot instantly, here I´ve got to produce the crash myself. Bug 211606 was Moz 1.2.1 on Win95, so bug seems to be Win9x-specific.
comment #1 assumes this bug could be from the fix of Bug 136647 Make Help window float in front of other windows The patch there is very short, only adding one parameter to a fucntion call: http://bugzilla.mozilla.org/attachment.cgi?id=96315&action=view RCS file: /cvsroot/mozilla/extensions/help/resources/content/contextHelp.js - window.open(MOZ_HELP_URI + "?" + encodedURI, "_blank", "chrome,menubar,toolbar,dialog=no,resizable,scrollbars"); + window.open(MOZ_HELP_URI + "?" + encodedURI, "_blank", "chrome,menubar,toolbar,dialog=no,resizable,scrollbars,alwaysRaised"); Can somebody check ( on Win9x ) if removal of the parameter ,alwaysRaised will cure that problem?
I believe that this bug is not describing the problem properly and may be misleading some people (e.g. Comment #3). I believe there to be a difference - two distinctly different buttons on the Titlebar. Unless we are discribing two different bugs? (Ref. Bug 211606 - marked duplicate) The problem is _not_ with minimizing/maximizing of the Help Screen, which works perfectly well for me. The problem is with "Saving (the Help Screen) to the Taskbar" and "retrieving (the Help Screen) from the Taskbar".
yup, that appears to be the problem http://bugzilla.mozilla.org/attachment.cgi?id=96315&action=view I compiled with this change taken out and it seems to be fixed. Ian, do you think we should back this out? I do. Anyway, I don't think that the help menu in any other apps actually stays on top (at least not in notepad :)).
moving stuff over to an outside-the-firewall email for the time being, looking for people to pick these Help and doc bugs up for me.
Assignee: oeschger → oeschger
mass reassign of all of Ian Oeschger's bugs to me (R.J. Keller).
Assignee: oeschger → rlk
Can anyone reproduce this?
Brant, can you reproduce this bug? I don't see this problem.
I just retested with latest trunk, BuildID 2003091704 on Win98 Opening Mozilla Help, minimize, maximize and minimize again freezes windows. I´ve got to use the Reset Button, with the following long boot. I don´t want to retest on other mozilla versions, maybe I´ll test tomorrow on a faster Win98SE system. Could you do me a favour, check this in, as there are some people who would like to tell me about this horrible mozilla bug, if they only knew. Seems to me, that this simple fix won´t break anything, but I´m not a developer. re comment #16: minimize/maximize When I wrote about minimizing/maximizing of the Help Screen, of course I meant "Saving (the Help Screen) to the Taskbar" and "retrieving (the Help Screen) from the Taskbar", using the leftmost button of the three buttons at the right of the titlebar, not the middle button which switches between Full Screen and some other display size, not always less than the full screen. Feel free to reopen your bug, if this bug is fixed, and bug 211606 is not.
Flags: blocking1.5?
Flags: blocking1.4.2?
Flags: blocking1.4.1?
Reason for demanding blocking 1.4.x and 1.5 Most simple fix suggested in comment 15 and tested in comment 17 this bug is annoyingly visible for everybody using win9x who uses help to read about some preferences, and sends help to the taskbar, edit some pref, restores help to read some more, and sents it back to the taskbar.
hhschwab@t-online.de: Actually, this appears to have went away on my end. This patch didn't seem to cause the problem like I thought. Since I can't reproduce this any longer, maybe this should be reassigned to someone who can. Don't think that this is going to block any milestone other than 1.6b maybe.
Keywords: helpwanted
R.J., as this bug has been seen on win9x only, did you test on win98? Is there a chance I can download a build compiled without this patch from somewhere? Mail me, if you got one for me.
Hermann, I'll compile a build without the patch for you and I'll email you about it when it's done.
Thanks RJK, it is working with your build, no hang. Unzipped in new folder, created new profile, tested, ok. Changed profile to my default profile, tested, o.k. Before installing this build I tested 1.5 RC1, got a hang. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20030916 Win98SE, XP1600+, 512 MB. Will retry later on a slower Win98 system with less RAM.
re comment #22 (referring to my comment #16) Hermann, Thanks for letting us know what you meant by what you said. Better to clearly say what you mean. Sorry if you feel that I rained on your parade. My intent was to clarify in order to avoid any confusion. I'm content as long as the bug is fixed. -- Gus
tested RJK´s build on my Win98 system, Celeron333 96 MB ram, it is working too. So backing out http://bugzilla.mozilla.org/attachment.cgi?id=96315&action=view seems to fix the thing. That one-line-only patch of Bug 136647 Make Help window float in front of other windows added only the parameter "alwaysRaised" to the third parameter of window.open: "chrome,menubar,toolbar,dialog=no,resizable,scrollbars,alwaysRaised" reversing this fixes that crasher bug on Win98 and Win98SE. Tested with a zip-build from RJK, using my default profile. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030918 Can backing out this parameter break anything on windows other than Win9x ?
Too late for 1.4.1. Not going to block 1.5 for this but we'd consider approving a reviewed and tested patch if it happens in time for 1.5
Flags: blocking1.5?
Flags: blocking1.5-
Flags: blocking1.4.1?
Flags: blocking1.4.1-
Patch removes the alwaysRaised that seems to be causing the problem. Note that super-reviews for the help component are VERY slow, so this will probably not make 1.5 (but will probably make 1.6).
Comment on attachment 131777 [details] [diff] [review] removes alwaysRaised from the Help window Neil, can you review this simple patch?
Attachment #131777 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 131777 [details] [diff] [review] removes alwaysRaised from the Help window sr jag? I'm tryin' to speed up the process. We might have a chance of getting this for 1.5.
Attachment #131777 - Flags: superreview?(jag)
Keywords: helpwanted, qawanted
Comment on attachment 131777 [details] [diff] [review] removes alwaysRaised from the Help window Since the problem is specific to Win98 and I know of no one with a development-worthy Win98 system, I doubt the root cause will ever be fixed. So we should take this spackle patch. r=danm
Attachment #131777 - Attachment description: Patch removes alwaysRaised. → removes alwaysRaised from the Help window
Attachment #131777 - Flags: review?(neil.parkwaycc.co.uk) → review+
Comment on attachment 131777 [details] [diff] [review] removes alwaysRaised from the Help window Oh. You know what, I've changed my mind! Sorry. We should find out whether the patch in bug 217012 actually fixes this bug before hacking the problem out. I expect it won't help but it's worth finding out. Let's not check this one in just yet. (That other patch should go in sometime in 1.6a.)
Attachment #131777 - Flags: review+ → review?(neil.parkwaycc.co.uk)
This will not block 1.4.2. The patch to this bug is in bug 217012.
Flags: blocking1.4.2?
Marking dep as that bug seems to fix this one too.
Oops, really marking dep, sorry, mid-air :-(
Depends on: 217012
This bug is critical for win9x users, forces them to reboot windows the hard way, and scandisk takes time, especially on old slow computers running win98. Especially those newbies, who are new to mozilla, and looking at mozilla help, will be hit. This bug doesn´t seem important, as there were not many comments to it, but are newbies commenting in bugzilla? Or do they instantly return to IE, or try Opera? According to http://www.google.com/press/zeitgeist.html, Win98 has 30% marketshare, and WinXP 37%. WinXP users have a shiny new IE with their shiny new OS ;-), what have Win98 users? An unsupported, insecure, bugridden IE 4. I don´t want to claim that IE from WinXP is noticeably more secure ;-) My point is, if users of Win98 systems change now to mozilla, or firebird, what browser will they use, if they buy a new computer? Will they instantly download and install a new browser on their shiny new system? If they are used to mozilla, surely. If they don´t know it, rather not. So if possible, this bug should be fixed as soon as possible in release versions, not in alphas or betas. Of course, the patch doesn´t fix the underlying cause, but it prevents the crash or hang, and a hang is even more annoying than a crash.
Flags: blocking1.4.2?
Actually the patch in bug 217012 does fix the underlying cause.
Oh. But you're suggesting we check in the patch from this bug to the older releases, in lieu of the better but scarier patch in 217012. That's an idea.
Yes, I do want to have this in 1.4.1 and 1.5, as this tiny patch is the reversing of a tiny patch which added ONE parameter only, leading to this hang, see comment 15. Adding of this parameter seemed to be legal, and doesn´t show this bug in other OS than Win9x. I´ve downloaded a zip build from RJK with this patch, and tested it on a win98 system with noname grafics card, and a Win98SE system, with nVidia integrated nForce grafics. Both working fine with this patch, but crashing before, tested with the latest trunk versions of Mozilla. See comment 27, comment 29.
Comment on attachment 131777 [details] [diff] [review] removes alwaysRaised from the Help window I filed bug 219865 to deal with removing alwaysRaised.
Attachment #131777 - Attachment is obsolete: true
Attachment #131777 - Flags: superreview?(jag)
Attachment #131777 - Flags: review?(neil.parkwaycc.co.uk)
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20030926 fixed starting BuildID 2003092504 with checkin for Bug 217012 browser window won't come to foreground with help window open
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Flags: blocking1.4.2?
It's a pity this wasn't fixed in 1.5 :(
requesting fix for 1.4.2, was fixed in trunk starting BuildID 2003092504 This bug crashes every Win9x, if a user wants to do something step for step and reading help, like going over the preferences. I successfully tested a build R.J. Keller built with the patch in this bug, on a system running Win98 and a different modern hardware running Win98SE, have a look at comment 42. So this patch here was working, but he preferred another one: actually this bug was fixed with checkin for Bug 217012 browser window won't come to foreground with help window open
Flags: blocking1.4.2?
This bug was rejected for 1.4.1 and 1.5 about a month ago. Still I suppose it's fair to reintroduce it for 1.4.2. If lawyers are allowed to keep trying until they win, anyone should be. It's no surprise that the patch in this bug fixes the problem. I'd classify it as a workaround because it removes the problematic feature of the Help window that's the cause of the problem. The other candidate is the patch in bug 217012 which fixes the root cause of the problem without removing the feature. (Note also related bug 216426, which provides for a user override of the feature. There's a whole ant's nest of fun to be had here, with a little digging.) The issue with removing the feature stems from bug 136647, where the Help window was first made alwaysRaised. That bug mentioned user studies which found that the alwaysRaised Help window was a boon to novices, and I've argued long and long in bug 219865 comment 7 that the feature shouldn't be removed, mostly because of the aforementioned bug 136647. That said, either patch would solve a nasty Win98 hang. The 217012 patch has been in the trunk for nearly a month without complaint. It seems safe. drivers have been unresponsive to email asking for clarification.
You should go to bug 217012 for this. You also set the 1.4 flag on the patch and NOT the bug if you want it for that release. alwaysRaised will never be removed from help. See bug 219865 for info on that.
Flags: blocking1.4.2?
Thanks for the quick reaction, and fixing that bug. I don´t care which way this bug is solved in 1.4.2, as long as it gets fixed, because imho 1.4.x will stay longer than 1.7. I´ve been thinking if the full solution in the other bug wouldn´t get approval because of changes of features, this one here would suffice as a work-around.
Keywords: fixed1.4.2
Target Milestone: --- → mozilla1.6alpha
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: