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: