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)

x86
Linux
enhancement

Tracking

()

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....
Forgive me, what's sloppy focus? -> Akkana, UNIX keyboard nav
Assignee: aaronl → akkana
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. :)
I'm seeing this same problem in 2001101212 on linux with windowmaker.
Blocks: focusnav
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.
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
Whoops, forgot to click the button to reassign to the focus folks.
Assignee: akkana → saari
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.
URL: annyany
Blocks: 140346
No longer blocks: 140346
Assignee: saari → nobody
QA Contact: bugzilla → events
Component: Event Handling → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.