[Bug 77675] Windows steal focus from each other and other apps
Coen Rosdorff
Oliver Schulze L.
I want to say that I'm agree with Dylan. Thats becuase I joined this BUG
discusion, not all the focus issu
About the other focus issues... come on, I think everybody knows how
windows/dialogs/response-windows should work.
Good luck, and happy hacking.
Jacek Piskozub
> New thread for the discussion about this bug.
>
It's a pity that reasonable argument aboutthe UI are not allowed on the
bug page :-(
I wonder when someone will tell us not to spam "production newsgroups".
Yes it happened before :-(
Ad meritum. The comments by Chris (and others) convinced me that the
ficus code is unnecessary. Maybe I stumble in darkness not seeing the
light but stopping the discussion is not a way of converting me back to
the need of Mozilla windows stealing focus from each other.
I believe that the focus stealing is generally confusing (especially to
new users). It mey lead to problems, including data loss, if the focus
is stolen during typing.
That was my .02 zloty.
Jacek
Mike Schiraldi
Should Mozilla ever steal focus?
To stimulate (some would say provoke) debate:
In my opinion, an actual Mozilla window should never jump to the top. Some
are arguing that Mozilla needs to pop up important modal dialog boxes
sometimes, and they need to steal focus. I say that the Mozilla window that
needs to pop up the dialog box should wait until it has focus.
Flame on.
Jacek Piskozub
> I'm new to this BUG.
> I want to say that I'm agree with Dylan.
Maybe a stupid question, but who's Dylan? No one on the bug page uses
the name in the name that is visible (read: searchable) on the page.
This is not nitpicking. I just do not know which side of the discussion
you support.
Jacek
Oliver Schulze L.
I was typing in bugzilla and thendecided to use the newsgroup.
Here are the comments:
------- Additional Comments From Dyl...@bigfoot.com 2001-07-01 18:24
-------
<QA ignore>
I should mention that the reason I am tracking this bug is not because
of the
dialogs (which IceWM happily neuters -- see "Focus dialog window when
initially
mapped only if parent frame is focused"), it is because the browser will
focus
itself on successful load of a page. Across destkops, and interupting
my work.
Page loading done? Yeah, grab that focus! This is especially bad since I
middle click, and alt+tab back to the other window to continue reading
(forking
off a window for each interesting sub link is what I do to not lose my
place).
</QA ignore>
Steve Morrison
>
> Coen Rosdorff wrote:
>
> > New thread for the discussion about this bug.
> >
>
> It's a pity that reasonable argument aboutthe UI are not allowed on the
> bug page :-(
maybe because the arguments had nothing to do with the real bug. i
don't think anyone was arguing the bug was invalid.
-s
Rob Speer
I mostly agree.
However, it sounds like what you're suggesting is that the dialog
shouldn't exist until its parent window gains focus, at which point it
should suddenly pop up. The delay between the window gaining focus and
the dialog appearing could be confusing and might even cause other
problems. I hope that wouldn't be the only way.
Is there any GUI platform where you can't make a modal dialog a "child
window", which will appear on top of its parent but no other windows,
and only block input to the window it belongs to? From the discussion
back in the bug report, it sounds like Konqueror can do this.
If that's not possible, Mike's solution would at least prevent the
problem of Mozilla's messages appearing on the wrong desktop or stealing
focus from typing.
--
Rob Speer
ahmetaa
i believe no window has a right to steal focus because it causes grand
irritation on user. and i think there is a way to solve the problem
1- Dont allow any window to steal focus
2- if there is a notice message, like security, error or helper
application, just blink the tool bar button down like Windows does. i
believe it is possible with Linux and others.
Greg Miller
> Coen Rosdorff wrote:
>
>> New thread for the discussion about this bug.
>>
>
> It's a pity that reasonable argument aboutthe UI are not allowed on the
> bug page :-(
But that argument has nothing to do with the bug in question.
> Ad meritum. The comments by Chris (and others) convinced me that the
> ficus code is unnecessary. Maybe I stumble in darkness not seeing the
> light but stopping the discussion is not a way of converting me back to
> the need of Mozilla windows stealing focus from each other.
Modal dialogs stop other parts of the app from functioning, and not
having them visible could be a real problem. It could be fixed, but not
for free--such changes have to be written and debugged.
--
http://www.classic-games.com/ http://www.indie-games.com/
I've often thought intelligence agencies should recruit idiots, as
idiots seem able to infiltrate any group in large numbers.
Gervase Markham
> bug page :-(
The problem is that heated discussions give us bugs like bug 2800, which
takes several seconds to load over a cable modem. The newsgroups are
better places for heated debate IMO.
> I wonder when someone will tell us not to spam "production newsgroups".
> Yes it happened before :-(
This is a perfectly reasonable argument to have in this group :-)
Gerv
Niko Pavlicek
> New thread for the discussion about this bug.
so, if I understand correctly, there are 3 oppinions in contrary:
1. focusing code is not needed
no window should steal focus from any window, even if it is the parent
window.
2. windows should steal focus as dialogs appear
a window appears in front, if an error exists and a dialog pops up in front.
3. windows should be able to steal focus only from their parent window
a dialog appears in front of its parent window, but doesn't popup in
front, rather it should wait until the user focusses this dialog or its
parent window.
IMO (3) is the correct behaviour, since the user can decide in which
window he works and until there are no errors in the actual window, no
dialog comes up to the front.
if an error (or another important event) happens in another window
(mail/news window, browser window, address book window,...) the taskbar
icon should blink to say: *"hello user, something exiting/important has
happened (page loading has completed, error ##### exists or anything
else)! switch the window to see what's happening and decide what to
do"*. if the user then switches to the affected window he sees the
dialog/result of the event.
Currently there are various issues with focussing:
- dialogs pop up to the front, even if the affected window is in
background and the user doesn't worry about at the moment
- windows steal focus from each other if
a. a news message is loaded
b. browser begins to paint a document
c. some other event happens (?)
I think, all these issues should be solved in one. This lasts a bit
longer, but the problem would be really solved!
And, even if I am no developer and don't have to decide when which
work is going on: fix it until 0.9.3 or at least until 1.0, please. This
is a really annoying problem, a fix would make all users a much happier!
Regards,
Niko!
--
e-mail
: niko_p...@web.de
web
: - http://www.pavlicek.de: private HP
- http://www.html-online.de: Einführung in HTML
- http://www.los-angeles2019.de: Blade Runner Fanpage
----------------------------------------------------------------
Alexey Nogin
> 3. windows should be able to steal focus only from their parent window
> a dialog appears in front of its parent window, but doesn't popup in
> front, rather it should wait until the user focusses this dialog or its
> parent window.
>
> IMO (3) is the correct behaviour, since the user can decide in which
> window he works and until there are no errors in the actual window, no
> dialog comes up to the front.
I agree completely. Mozilla should not bother users with error messages
concerning windows they are not using at the moment.
Alexey
--------------------------------------------------------------
Home Page: http://nogin.org/
E-Mail: no...@cs.cornell.edu (office), ay...@cornell.edu (home)
Office: Upson 4139, tel: 1-607-255-4934
Judson Valeski
>In my opinion, an actual Mozilla window should never jump to the top. Some
>are arguing that Mozilla needs to pop up important modal dialog boxes
>sometimes, and they need to steal focus. I say that the Mozilla window that
>needs to pop up the dialog box should wait until it has focus.
>
I agree. Hi-jacking focus is rude.
Jud
Niko Pavlicek
> Niko Pavlicek wrote:
>
>
>> 3. windows should be able to steal focus only from their parent window
>> a dialog appears in front of its parent window, but doesn't popup
>> in front, rather it should wait until the user focusses this dialog or
>> its parent window.
>>
>> IMO (3) is the correct behaviour, since the user can decide in which
>> window he works and until there are no errors in the actual window, no
>> dialog comes up to the front.
>
>
> I agree completely. Mozilla should not bother users with error messages
> concerning windows they are not using at the moment.
Just seen that this is know filed with bug #88810
(http://bugzilla.mozilla.org/show_bug.cgi?id=88810)... waiting for a fix ;-)
Niko Pavlicek
> Alexey Nogin wrote:
>
>> Niko Pavlicek wrote:
>>
>>
>>> 3. windows should be able to steal focus only from their parent window
>>> a dialog appears in front of its parent window, but doesn't popup
>>> in front, rather it should wait until the user focusses this dialog
>>> or its parent window.
>>>
>>> IMO (3) is the correct behaviour, since the user can decide in which
>>> window he works and until there are no errors in the actual window,
>>> no dialog comes up to the front.
>>
>>
>>
>> I agree completely. Mozilla should not bother users with error
>> messages concerning windows they are not using at the moment.
>
>
> Just seen that this is know filed with bug #88810
> (http://bugzilla.mozilla.org/show_bug.cgi?id=88810)... waiting for a fix
> ;-)
ok, I just read *all* the comments in 88810 and - on Asa's desire - I'll
recomment one in this thread.
Quote from da...@netscape.com (sorry, don't know your name):
"Niko's quote at the beginning of this report is no doubt well-intended,
but impractical. What about prompts from servers that will cut the
connection if the user doesn't respond in a timely fashion?"
Hey, what's the problem? In the affected window a dialog comes up, if
this window isn't in front the taskbar starts to blink (is such a
feature possible in mac os?) and the user, who is e.g. too busy with a
formular, a chat or an online game, can still decide if this window is
important enough to interrupt his current work.
You mustn't domineer over the user, since you don't know if your prompt
is important for _him/her_! Perhaps he doesn't worry about loosing the
connection to a server, rather he worrys much about losing his game.
Another point is:
It's just really annoying, if you type e.g. in the url-bar and suddenly
another window is in front, since it has stopped loading, started
painting or a timeout occured - just show the user, something has
happened with the blinking taskbar icon.
Imagine, instead of the green arrow on the mail icon, the mail icon
suddenly pops up and shows you your latest mail message without giving
the user the chance to decide what to do. Make it the same with dialog
boxes or errors.
Regards,
Daniel Matejka
> this window isn't in front the taskbar starts to blink (is such a
> feature possible in mac os?) and the user, who is e.g. too busy with a
> formular, a chat or an online game, can still decide if this window is
> important enough to interrupt his current work.
Apologies for not reading this whole thread before replying. I'm sure
I'll just be repeating what someone else has said.
Bug 77675 is just a bug. Windows are inappropriately stealing focus.
Wants fixing. Done. Bug 88810 is searching for meaning. Interpreted as a
blanket attempt to remove Mozilla's ability to change window order, we
got problems. Interpreted as a wish that Mozilla did that less often
(modulo such "straightforward" bugs as 77675), sure, it's worth looking at.
Mozilla has the ability to do what you mention -- see
nsIWidget::GetAttention. Each platform implements it somewhat
differently, of course. A quick tour through lxr seems to be telling me
that that method is never, ever used. I think you're on to something
with that. Seems like it would be a good idea to investigate the
feasibility of using GetAttention instead of Focus and/or ShowModal,
where appropriate. Maybe a short, new bug (88810 is already a bit
rambling and ill-defined) is in order.
Echoing Wise Asa, I'd ask that you work out the details (if there are
any more than that) here instead of in the bug report. Speaking for
myself, there's probably nothing at all that makes me more inclined to
ignore a bug report than a requirement that I read forty entries in
twenty directions before I figure out what the problem is.
Randall Parker
thusly:
> Should Mozilla ever steal focus?
If yoy have one Moz winodow and it has focus and something within it opens
another window then that other window should get focus.
However, if the Moz window that opens another window doesn't have focus when
it opens that other window then the new window shouldn't get focus.
Basically, a window that is not the foreground window should not be able to
do something that gives it or another window focus.
Maybe there are some severe error conditions that might be exceptions. But
I'm inclined to say no even there.
Rob Speer
> Maybe there is a choice,
>
> i believe no window has a right to steal focus because it causes grand
> irritation on user. and i think there is a way to solve the problem
> 1- Dont allow any window to steal focus
> 2- if there is a notice message, like security, error or helper
> application, just blink the tool bar button down like Windows does. i
> believe it is possible with Linux and others.
Well, it's not. Under GNOME, it's possible not to even have a toolbar,
and I've never seen anything manage to make it blink anyway. But I don't
really miss the blinking. If I'm loading a page, I'm bound to go back to
look at it eventually, at which point I should see any modal dialogs
that are attached to that window.
--
Rob Speer
Randall Parker
thusly:
> 3. windows should be able to steal focus only from their parent window
> a dialog appears in front of its parent window, but doesn't popup in
> front, rather it should wait until the user focusses this dialog or its
> parent window.
>
> IMO (3) is the correct behaviour,
Niko, I agree completely. Perhaps there should be a configurable option so
that those who want a different behavior can get it. But its the one change
in all apps that I use that I most want to see.
zero the hero
"steal" focus. Rather, they get "given" focus.
This is an important point. It means that a parent window can focus
it's child, rather than the child asserting it's right to focus. A
new window opened by the currently focussed window will be given focus
by the parent window. A new window created by a window which doesn't
have focus, _won't_ be given focus.
IMO, focussing is the job of the window manager, error messages should
be modal for their window, and no window should popup unless the user
or the currently focussed window asks it to.
But since Mozilla seems to want to implement everything all by itself,
it would then need to be able to track z-order of all open windows.
Clicking a window should bring it to the top, and any window-modal
dialogs would be on top of that. A window which requests itself to
focus will no-op. A window that asks that another be given focus, will
only give _its_ focus. The window being given focus appears above
window giving focus, and _no other_. This would comply with the
JavaScript spec, as technically any window which can find another (by
name or by parent-child association) should be able to give it focus.
Plus, the user wont get annoyed with windows popping up all over the
shop.
For more details, see my comment on bug 88810.
Randall, I would happily have a dig at it. Point me to the right file
and I'll hack till I drop.
BTW, I don't think newsgroup posts (or worse, email) are such a good
idea for discussing things like this, as they will inevitably be lost
in the mists of cyberspace by the time the code comes up for review or
the bug crops up in another guise later on.
Which is easier,
a) reading a long bugzilla page,
or b) trawling through a million newsgroup postings about communist
imagery in the mozilla banners
to find important discussions like this?
Which is why I am posting this message to both this NG, and bug 88810.
Randall Parker
thusly:
> Quote from da...@netscape.com (sorry, don't know your name):
> "Niko's quote at the beginning of this report is no doubt well-intended,
> but impractical. What about prompts from servers that will cut the
> connection if the user doesn't respond in a timely fashion?"
>
> Hey, what's the problem? In the affected window a dialog comes up, if
> this window isn't in front the taskbar starts to blink (is such a
> feature possible in mac os?) and the user, who is e.g. too busy with a
> formular, a chat or an online game, can still decide if this window is
> important enough to interrupt his current work.
> You mustn't domineer over the user, since you don't know if your prompt
> is important for _him/her_!
Yes, exactly. Do our machines serve us or do we serve our machines? Or do we
serve the people who create web sites?
Applications that grab focus away from other applications are doing a bad
thing. This should not be allowed. The only exception would be if your app
was a safety or security monitoring app. If you are running in order to be
interrupted and alerted to something important then that is its purpose.
Otherwise it shouldn't be done.
Randall Parker
> But since Mozilla seems to want to implement everything all by itself,
> it would then need to be able to track z-order of all open windows.
> Clicking a window should bring it to the top, and any window-modal
> dialogs would be on top of that. A window which requests itself to
> focus will no-op. A window that asks that another be given focus, will
> only give _its_ focus. The window being given focus appears above
> window giving focus, and _no other_. This would comply with the
> JavaScript spec, as technically any window which can find another (by
> name or by parent-child association) should be able to give it focus.
> Plus, the user wont get annoyed with windows popping up all over the
> shop.
I entirely agree with these comments.
> For more details, see my comment on bug 88810.
>
> Randall, I would happily have a dig at it. Point me to the right file
> and I'll hack till I drop.
There is not a single file. You would have to download the whole source tree
and go searching/grepping thru the source code for the calls that grab focus.
Since they use keywords that are searchable this should be doable. However,
you have to learn a fair amount about Moz's source code before going and
making changes. Plus, you'd better have a compiler and debugger and first
prove to yourself that you can successfully build Moz.
> BTW, I don't think newsgroup posts (or worse, email) are such a good
> idea for discussing things like this, as they will inevitably be lost
> in the mists of cyberspace by the time the code comes up for review or
> the bug crops up in another guise later on.
Well, the Moz developers and not a few of us who read the bug pages disagree
with you. That is why the Moz developers have complained about the
inappropriateness of these sorts of postings being made in Mozilla.
You may like to communicate in that way. But if the listeners do not like
hearing this sort of stuff that way you are not doing anyone any favors by
continuing to post those sorts of messages into Bugzilla.
> Which is easier,
> a) reading a long bugzilla page,
But a bugzilla page gets loaded many times by the same person.
> or b) trawling through a million newsgroup postings about communist
> imagery in the mozilla banners
> to find important discussions like this?
You can just read the subjects you are interested in.
> Which is why I am posting this message to both this NG, and bug 88810.
Look, the Mozilla developers do not want this kind of posting put in the bug
tracking system. They think it decreases their productivity. I think you
should respect that.
zero the hero
> There is not a single file. You would have to download the whole source tree
> and go searching/grepping thru the source code for the calls that grab focus.
> Since they use keywords that are searchable this should be doable. However,
> you have to learn a fair amount about Moz's source code before going and
> making changes. Plus, you'd better have a compiler and debugger and first
> prove to yourself that you can successfully build Moz.
I've been building Mozilla from CVS for about a moth now, and
downloading nightly builds every few days for months before that, but I
couldn't build a debug build until last night (see
http://bugzilla.mozilla.org/show_bug.cgi?id=89302 for details).
What I meant was that I would be happy to work on it, if I knew where to
begin(!)
> Look, the Mozilla developers do not want this kind of posting put in the bug
> tracking system. They think it decreases their productivity. I think you
> should respect that.
Ok. Sorry for spamming unneccessarily.
-Chris
Randall Parker
> I've been building Mozilla from CVS for about a moth now, and
> downloading nightly builds every few days for months before that, but I
> couldn't build a debug build until last night (see
> http://bugzilla.mozilla.org/show_bug.cgi?id=89302 for details).
> What I meant was that I would be happy to work on it, if I knew where to
> begin(!)
There is a patch that seems to fix the problem but not on MacOS. See the bug report. It was posted there as an attachment.
Seems to me that the patch would be a good thing to diff against the current source code to see what sorts of changes they are making to try to fix the problem.
Daniel Bratell
> Seems to me that the patch would be a good thing to diff against the current
> source code to see what sorts of changes they are making to try to fix the problem.
A patch is a diff. Just open the path and you see what's done.
/Daniel