Closed Bug 285947 Opened 20 years ago Closed 17 years ago

hidden tabs-mode "timeout" alert steals keyboard and mouse focuses, forces user to hard reboot computer

Categories

(SeaMonkey :: General, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: xanthian, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b) Gecko/20050213
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b) Gecko/20050213

[This is almost certainly a more general Mozilla problem.]

In tabs mode, if a bookmarked group of tabs is opened, and
the user clicks on one tab while another tab is putting up
a timeout alert message, bad luck can result in the alert
being hidden behind the Mozilla window. Since the alert has
grabbed both the keyboard and the mouse focus, the user now
has no choice but to hard reboot the computer. Even the
<ctrl-alt-del> task manager hard-wired evocation, while it
does bring up the task manager, does not suffice to dismiss
Mozilla, because the user has no way to interact with the
task manager once it is evoked.


Reproducible: Sometimes

Steps to Reproduce:
The cause of the problem is always there,
but since it is a timing problem between
user clicks on the Mozilla window versus
the Alert box being painted, it takes a
while to reproduce it.

1. Build a tab set that includes some slow, unreliable sites, book mark the
collection of tabs.
2. Open that bookmark.
3. Click among other tabs while the slow one times out.
4. If unlucky, you'll put the Mozilla window in front of the alert requestor.
You have now lost control of your computer, and only a hardware reboot will
suffice.

Actual Results:  
Modal alert stole keyboard and mouse focus, but was hidden behind the main
Mozilla window, thus was not itself selected, so that inputs to dismiss the
alert went ignored.


Expected Results:  
1) Kept the Alert "always in front".
2) Better yet, not grabbed the keyboard and mouse focus for what was after all,
not a crucially important piece of information requiring immediate user response.
3) At minimum, provided a way to bring the alert to front and some indication to
the user that such an alter existed, since it was invisible (it came forward
with but behind the task manager when the latter was evoked, but still didn't
have focus).


Modal alerts are a tool of satan.
maybe fixed by 
Bug 284993  	changing tabs on modal dialog horks url bar

Maybe you can try to reproduce with a current nightly?
(In reply to comment #1)
> maybe fixed by 
> Bug 284993  	changing tabs on modal dialog horks url bar

> Maybe you can try to reproduce with a current nightly?

Well, I tried, but the best you can say when you fail to
re-evoke a timing problem is "I didn't see it again", not
"it isn't there any more". Still, I did try clicking as
fast as I could on the window, while the timeout of the
URL requested in a tab was occurring, and didn't re-encounter
the problem, with the 2005/03/13 nightly, for whatever comfort
that gives.

xanthian.

(In reply to comment #1)
> maybe fixed by 
> Bug 284993  	changing tabs on modal dialog horks url bar

Considering that bug 284993 is marked "FIXED" but
the comments suggest that some other, mutated bug
was fixed instead, probably not. Aside from, that
the term "loss of focus" is mentioned several times
there, I can't even see that bug being especially
related to this one.

This ones main issues are (1) an alert that's not
particularly important, grabbing mouse and keyboard
focus anyway, and (2) an alert that has grabbed the
mouse and keyboard focus being allowed to end up
obscured and thus undismissable, in turn making the
mouse and keyboard focus unrecoverable to the user.

Neither of those issues are mentioned in your
referenced alternative, bug 284993.

Modal alerts really are a tool of Satan. Mozilla is
not even among the first thousand major applications
caught by this problem, nor is MS-Windows unique in
hosting this problem; it used to disable MacOS for
me regularly.

The alert should at most grab focuses from its own
application, not from the whole windowing interface.

Even then, it needs to stay "on top" of its own
application, or the application ends up seemingly
"crashed" despite that it is still otherwise running
fine, just with an alert that can't be accessed by
the user to be dismissed, because some windows are
layered in a fatally inconvenient order.

Really, the bug is a timing problem between Mozilla
and the host windowing interface, caused in part by
using a separate window for the alert, in part by
not making the alert "always on top" in that host
windowing interface.

It is the host windowing interface, I suspect, that
is moving the main application window in front of
the alert "as the alert is being painted".

If the alert were just painted into an embedded box
in the middle of the existing window, the host
windowing interface wouldn't have the option to put
it behind that window and thus cause these problems.

FWIW

xanthian.
Version: unspecified → Trunk
We shouldn't be letting a modal dialog end up below its parent.  How's that
happening?
(In reply to comment #4)

> We shouldn't be letting a modal dialog end up
> below its parent.
> How's that happening?

Well, first because modal dialogs are used at all.

They are a leftover from monotasking days, where
they worked adequately well.

Their very existence in multitasking systems is a
blunder, and they've been locking up computers this
way now for over 18 years, in an amazing variety of
environments and applications, without programmers
having learned to avoid using them ever, at all.

Second, because the modal dialog's separate window
isn't being marked "always on top", quite possibly
(speculating) because "always on top" isn't a
portable construct, so that such an unportable
construct is being avoided, by deliberate developer
choice.

Third, because the modal dialog is in a separate
window, rather than a box embedded in the parent
window, creating the need for a window layer
ordering relationship between the parent window and
the modal dialog window, enabling the rest of the
problem to occur.

Fourth, because you are in a multitasking
environment, and so you create a race condition.

[This race condition is part one of "modal dialogs
are inventions of Satan".]

It is completely possible, and happens:

    For Mozilla to say to the OS "give me a new
    window structure with some screen space _right
    here_ in which to paint my modal dialog".

    Now, somewhere between the OS saying "here is
    your window and associated foremost window
    screenspace, knock yourself out", and the
    browser finishing its task of painting and
    enabling the modal dialog, the OS sees and acts
    on a user mouse click on the parent window (the
    race gets won by the wrong horse).

    The OS notices that "somebody" has reserved some
    screen real estate obscuring the parent window,
    but the user click has just made the parent
    window the active window.

    The OS does its usual "window to front" for the
    active window, shoving the pixels into which the
    browser is painting the modal dialog "behind",
    which really means, to the offscreen cache where
    all other obscured windows and fragments of
    windows live [so that they can still be written
    even while obscured, to avoid deadlocking other
    active applications].

    There you are, the modal dialog is obscured, but
    the browser doesn't know any better than that it
    is still front and center as expected.

    Now that the modal dialog is "ready", the
    browser hands it the keyboard and mouse focus
    (probably at the end of the painting step, since
    it wouldn't be tremendously useful before them).

    Now here is the second "modal dialogs are tools
    of Satan" problem. The browser hands the modal
    dialog the keyboard and mouse focus for the
    _entire OS_, not just for the Mozilla
    application, and now _everything_ is locked out,
    even the windowing system, even the stuff that
    would allow Mozilla to be separately killed as
    an application.

Oops! The computer is now a fancy paperweight and
little else until a hard reboot is done.

FYI

xanthian, former computer graphics guru, and still
able to do really attractive handwaving in the
field, what with knowing where the bits are buried.


This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug report details a huge, crash-and-burn
level problem with Mozilla: the inappropriate
use of modal dialogs, that can be hidden by a
race condition between the dialog being drawn
and the user clicking some other window in
front of it, thus locking the user out of all
control of the computer.

It would be tragic if this fatally flawed design,
one shared with many, many other applications, were
allowed to survive in Mozilla merely because the
original reporter no longer has access to Mozilla.

Please:

1) Turn _off_ automatic resolution of bugs -- that is
moron level thinking. I've received four of these
threats to do automatic bug resolution in a single day,
and in each case that would be a grossly inappropriate
choice. That doesn't speak well for the doubtless
thousands of other similar messages also sent out at
the same time.

2) Turn on "fix this bug using whatever effort level
it takes" thinking instead.

3) If "statistically" not much progress is made if bugs
aren't receiving updates, that is a condemnation of the
management of Mozilla's software maintenance, it has
precisely zero relationship to the importance, validity,
or the repairability status of the original bug.

4) It is also a self-fulfilling prophesy that bugs being
ignored aren't being fixed. It is the "being ignored"
part that is the problem, a problem with Mozilla's management
of bug repairs that doesn't give higher priority the longer a
bug goes unfixed, not the "aren't being fixed" part; that's a
given for bugs which are being neglected.

FWIW

xanthian.

If you want to complain, complain to gerv.  That means cc him.
Kent: a little perspective is called for. This is something you've seen once,
six months ago, and (as I understand this bug) have not managed to reproduce
since. I can think of many bugs which are more important.

This bug has been commented on, so it will stay open.

Gerv
(In reply to comment #9)
> Kent: a little perspective is called for. This is something you've seen once,
> six months ago, and (as I understand this bug) have not managed to reproduce
> since. I can think of many bugs which are more important.
> This bug has been commented on, so it will stay open.
> Gerv

Gerv,

A little intelligence is called for. This ("keyboard and mouse input
grabbing" modal dialogs that can be hidden by a click-race condition
behind other windows, locking the control of the computer away from
the user) is a bone-headedly stupid design choice, one I've encountered
in applications beyond number, since long before Mozilla was born.

Where is the increment of institutional wisdom that should have let
Mozilla developers avoid this design choice immediately? Do we really
have to repeat _all_ the mistakes of our predecessors?

Just because I don't report the bug every time it happens, doesn't
mean it isn't happening.

The _correct_ response is to give this bug the attention given to every
other Mozilla bug that forces the user to reboot to regain control of the
computer, not to natter at reporters because the bug isn't being reported
frequently enough to tickle your fancy.

It isn't even necessary to be able to replicate the bug (race conditions
are hard to replicate on demand); simple logical analysis of the situation
more than suffices to show the problems with this design choice.

You, sir, have no business being in charge of making bug prioritization
decisions, bemused dolt that you are. Deciding to close bugs because the
Bugzilla reports aren't being updated is the choice of a fool who has no
concept how robust code is created and maintained, a beancounter
mentality choice, not a software developer choice. That you have
made this choice despite the protests of wiser heads working on
Mozilla code show that you are not merely a fool, but an invincibly
ignorant one, so sure of yourself when in error that you cannot
even heed wise counsel.

Such persons are best removed posthaste from the gene pool, as
a danger to all and everything around them.

In my expert opinion after 44 years of software development, frequently of
code (cyclone forecasting, nautical hazard depiction, commercial airlines
communication) on which human lives depended, and in which the acceptable
number of known or suspected bugs was exactly zero.

xanthian.

(1) I suspect that the only reason keyboard and mouse focus for the whole OS is
handed over is because Windows98 can hardly be called a multi-tasking OS. 
On any real OS, focus is per-app.

(2) the standard fix for the modal race problem is to grab the apps GUI event
processing queue before calling the OS, ignore any events occuring outside the
modal window, and hold on to the queue until the dialog is dismissed.
(In reply to comment #10)
> 
> The _correct_ response is to give this bug the attention given to every
> other Mozilla bug that forces the user to reboot to regain control of the
> computer, not to natter at reporters because the bug isn't being reported
> frequently enough to tickle your fancy.
> 
> It isn't even necessary to be able to replicate the bug (race conditions
> are hard to replicate on demand); simple logical analysis of the situation
> more than suffices to show the problems with this design choice.

My current Seamonkey build (Gecko/20050910) displays error pages on network
timeouts, not modal dialogues.  ISTM that this bug should either be resolved
FIXED or WFM (based on original report), or morphed into a generic "Modal
dialogues are the spawn of santa" (based on comment #4).
(In reply to comment #11)
> (1) I suspect that the only reason keyboard and mouse focus
> for the whole OS is handed over is because Windows98 can
> hardly be called a multi-tasking OS. On any real OS, focus is per-app.

Perhaps, but with 95% of desktops running MS-Windows, and 50%
of those being of WinOS98SE vintage or before, Mozilla has to
work on "unreal" OSen or lose a big fraction of its potential
audience.

> (2) the standard fix for the modal race problem is to grab
> the apps GUI event processing queue before calling the OS,
> ignore any events occuring outside the modal window, and
> hold on to the queue until the dialog is dismissed.

Yep, and that "standard fix" totally fails to cure the
problem, which is why the _appropriate_ fix is not to
use modal dialogs, at all.

a) Most likely, the modal dialog is hidden from the user
because of the click race pulling the window that evoked
the modal dialog in front of the "layer" on which the
modal dialog is being written, before the modal dialog
is visible at all (allocating resources for a new window
is astonishingly slow, even on modern hardware, and a
perceptible delay before pixels start getting painted is
always there), and, unless the user has an appropriate
level of hard earned paranoia, is unsuspected by the user
to be hiding behind some other window of the main app,
here, Mozilla. The user perception isn't "a modal dialog
is hiding from me", it is "my computer screen interaction
is completely locked up".

b) By "ignoring events outside the modal window", the user is
prevented from closing, minimizing, or moving that obscuring
main app window, so the modal dialog remains hidden and probably
unrecognized as the cause of the lockup.

c) Since the modal dialog is complete obscured, there _are no_
events "inside the modal window".

d) Reboot.

HTH

xanthian.

can this be reproduced on XP with current trunk?
=> incomplete - no response
but please comment if you can repro on current trunk.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.