Open
Bug 104794
Opened 23 years ago
Updated 2 years ago
Sloppy focus and open url window misbehave.
Categories
(Core :: DOM: UI Events & Focus Handling, enhancement)
Tracking
()
NEW
People
(Reporter: dothebart, Unassigned)
References
(Blocks 1 open bug, )
Details
Use an X11-Version of Mozilla. Make your window-Manager use 'sloppy Focus'
press <ctrl><shift> + <l>, the open url window pops up.
Now if the mouse-Pointer does happen not to be over the pop-up, the following
happens:
Type 'www' and the history list drops down in a new Window. If you go on typing
something that doesn't match the History, the Drop-down is closed. And now the
Focus is givven to that window where the mouse-Pointer is over.
(I think this will happen to the usual url line too, but usualy noone accesses
it without placing the mouse over it)
Solutions:
* Move the mouse pointer automatically over the open url window
* Pop up the Window under the mouse pointer?
* not close the 'history' - window, but rezize it to zero or one pixel
(I think this would be the best one.)
Sorry I didn't use latest mozilla, but I think this issue is relevant to all
newer stuff to.
BTW, in the os section, wouldn't be an X11-general appropriate to? 'caus I do
think that any other X11-Implementation has the same problems....
Comment 1•23 years ago
|
||
Forgive me, what's sloppy focus?
-> Akkana, UNIX keyboard nav
Assignee: aaronl → akkana
Comment 2•23 years ago
|
||
Sloppy focus is the following focus model (common with Unix windowmanagers):
When the mouse pointer enters a window that window is focused (though not
necessarily raised). When the pointer exits the window, the window does _not_
lose focus (hence sloppy).
As for the suggestions:
> * Move the mouse pointer automatically over the open url window
This would be incredibly and utterly annoying. Please do not.
> * Pop up the Window under the mouse pointer?
Isn't this the windowmanager's job? :)
> * not close the 'history' - window, but rezize it to zero or one pixel
me too, as you can tell. :)
Comment 3•23 years ago
|
||
I'm seeing this same problem in 2001101212 on linux with windowmaker.
Reporter | ||
Comment 4•23 years ago
|
||
Under windows you might get some similar happenings installing the 'microsoft
power toys' especialy a tool called 'TWEAK UI' It appears in system control with
some gears as Icons. In it there will be some where a Check-Box calling
'X-Mouse' (in winDOS not NT there is a special Programm making the mouse behave
that way.)
The basic behaviour of Sloppy-Focus is, that if you move the mouse, the window
you at least passed with the pointer gets the Focus. The root window is not
allowed to receive Focus via mouse-movement in Sloppy-Focus.
The opposit of sloppy Focus (what you might be used to) is ClickToFocus, which
means if you want to change the focus onto a Different Window, you have to click
into it.
The advantage of SloppyFocus is, that you can activate a window without raising
it.This enables you to put Windows over each other, in opposit of sorting the
windows that they tile the screen.
Comment 5•23 years ago
|
||
It's a focus issue, not a keyboard nav issue (it affects keyboard nav, but the
focus manager is what controls which windows affect focus). Sounds like the
dropdowns are doing something bad to focus when you type something that doesn't
match.
Component: Keyboard Navigation → Event Handling
Comment 6•23 years ago
|
||
Whoops, forgot to click the button to reassign to the focus folks.
Assignee: akkana → saari
Comment 7•23 years ago
|
||
Yes, this definitely happens (2002021412 Linux) and it's definitely not right,
but enhancement is a fair enough Severity level I suppose. Confirming NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think this still happens (2002031416 Linux).
This is a general problem, not only related to the open url window, but also
related to all dialogue windows which contain those dynamically created and
destroyed widgets, every one of which has a X window. For example "open file",
"save as" and other dialogues have the same behaviour.
Obviously it's a focus problem. Many other applications has the same problem
such as gnome-terminal.
I think the ideal solution is from windowmanager. the windowmanager give a
focus config option as those Wilfried Goesgens suggested
* Move the mouse pointer automatically over the new popup window.
* Pop up the Window under the mouse pointer.
When someone select 'sloppy focus' mode, they enable one of the above two
options too.
But now we cann't expect those windowmanager having these features, so maybe
we'd better do those things in mozilla.
As contrasts, 'gvim' and 'gedit' adopted the second way to avoid the problem.
Whenever they pop up a window under the mouse pointer. But sometime the
pop-window maybe display partly out of desktop, so personally I think,
especially taking account of accessibility, the fisrt way is better for mozilla:
move the mouse pointer automatically over the new popup window.
How do you think about that? Pls give your comments.
Updated•23 years ago
|
Updated•15 years ago
|
Assignee: saari → nobody
QA Contact: bugzilla → events
Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•