89106 - Open Web Location loses focus when autocomplete stops && mouse not over dialog

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, defect, P3)

Description

[Louis Tool]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2011062823

Netscape has a "clear" button in the Open dialog box.  Mozilla should too.

Netscape binds the Open Web Location box to Alt-L.  This is much more convenient
than Mozilla's default Ctrl-Shift-L.  Mozilla should have a compatibility mode.

The Open Web Location dialog loses focus when autocompletion stops matching and
the pop-down window is withdrawn.  I am using FVWM 2 on Linux with
focus-follows-mouse.

Reproducible: Always
Steps to Reproduce:
1. File -> Open Web Location...
2. Cycle focus to that window in some way other than mousing to the window (i.e.
FVWM's "Prev Focus" or "Next Focus" commands
3. Start typing a url that's in your autocompletion list.
4. Halfway through, type a character that causes autocompletion to not match. 
The popdown window is withdrawn and focus is lost.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Please file one bug per issue.  This should be 3 separate bugs.

Comment 2

[Asa Dotzler [:asa]]

->Component: XP Apps GUI Features

Comment 3

[sairuh (rarely reading bugmail)]

okay, testing with 2001.07.03.18-trunk comm bits [redhat 6.2 w/gnome and
sawmill], this is what i did:

0. moved my mouse pointer to the upper-right part of the browser [still over the
content area], so that the dialog won't appear underneath it in the next step.
1. brought up the Open Web Location dialog [ctrl+shift+L].
2. initially, the focus is in the textfield of the dialog. i start typing a url
that'd make the autocomplete droplist dropdown.
3. enter a character that wouldn't match.

result: focus goes to the URL bar --it's no longer in the textfield of the Open
Web Location dialog.

workaround: move mouse over dialog. or --at least in my current sawmill setup--
i hit alt+tab till the dialog is in focus once again.

tentatively assigning to jag --any ideas why focus is jumping here?

Comment 4

[Louis Tool]

I've submitted the first two bugs in this report as separate bug reports. 
Please consider this bug report as only dealing with the third issue.

Comment 5

[sairuh (rarely reading bugmail)]

louis, what are those other two bug numbers? thx!

Comment 6

[jag (Peter Annema)]

xmouse ("focus follows mouse"). Wheee!

The open location dialog isn't window modal, so you can actually focus the
window "behind" it and do stuff with it. You can see this by opening the Open
Location dialog, moving your mouse over it, then over the window from which you
opened it. (Or use alt-tab, or click it if you don't have xmouse).

When you start typing and the auto-complete box pops up, that's actually a
mini-window (I think). When you type something that causes it to go away, focus
will go back to the most natural place (per your window manager), which in your
testcase is the window behind the dialog, because that's where your mouse is.

We might be able to "fix" this by making the Open Location dialog window modal,
another solution could be to explicitely move focus back to the dialog when the
"matching urls" popup goes away (which would probably cause some flicker while
your window manager and Mozilla are fighting to set focus), a third would be to
not fix this, since this is expected behaviour for xmouse (which luckily I don't
see 'coz I have my window manager set to "click to focus").

Reassigning to xp apps default owner.

Comment 7

[Paul Chen]

Unless someone else wants to tackle this, I don't think I'll get to this one for
a while. Marking p3 and mozilla1.1

Comment 8

[Chris Charabaruk]

See bug 105020 for a similar (?) bug with the URL bar. I thought it was a dup of
this one, now I'm not so sure...

Comment 9

[sairuh (rarely reading bugmail)]

trudelle to triage

Comment 10

[sairuh (rarely reading bugmail)]

moving open bugs pertaining to the Open Web Location dialog to [e-mail]
as qa contact.

to find all bugspam pertaining to this, set your search string to
"GottaGetThisHenOut!"

Comment 11

[Peter Trudelle]

This dialog is modal on Windows, shouldn't it be on Linux?  ->bryner/future

Comment 12

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420