89214 - Caret in URL Bar is left visible without focus

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect, P4)

Description

[jamacht]

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

There is a trailing URL Bar caret when the Search SideBar tab is opened. Trying
to type shows that the URL Bar does not have focus. The URL Bar caret should be
removed when the URL Bar does not have focus.

You may have to perform the following steps a number of times for the bug to be
visible since the caret is blinking in the URL Bar, although if your timing was
good you could probably reproduce every time.

 

Reproducible: Always
Steps to Reproduce:
1. Show the SideBar.
2. Hide the Search SideBar tab.
3. Click in the URL Bar and notice a blinking caret.
4. Show the Search SideBar tab using Tabs->Search
5. Try typing.
6. Click in the URL Bar at a position different from the position in step 3.

Actual Results:  The caret is visible while the URL Bar does not have focus
(shown by typing in step 5). This superfluous caret will remain while a second
one appears (after step 6).

Expected Results:  The URL Bar caret should not be visible when the URL Bar does
not have focus. The URL Bar should not have caret trails.

Comment 1

[Dwayne]

Confirming on Build 2001-07-04-04, Win2k sp2, but with one difference:

Clicking into the sidebar will leave the caret in the URL bar, but when I go
back to click, it automatically selects the entire URL (as it should) which
wipes out the caret.

OS should be changed to All.

Comment 2

[rubydoo123]

I don't see this using the build from 2001070504, can you try it using a build
from today (trunk opt build)

Comment 3

[sujay]

I see ths issue on windows where the caret is sometimes stuck next
to the URL when you give focus to another area(sidebar).
but after you click on the URL again(it higlights) and then
that stuck caret is gone and back to normal.

Comment 4

[rubydoo123]

hmm, i never see the phantom caret -- when you select in the url, is the url
completely selected and then you go somewhere else, or have you specifically set
the caret somewhere in the url bar? either way with me, I don't see it

Comment 5

[sujay]

its a very minor issue....but I see the frozen caret
and then clicking back on the URL bar makes it go away...

Beth, AIM me if you want me to show you...

Comment 6

[jamacht]

I have just verified that this (admittedly super minor) issue still exists, 
using: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010705, build 
2001070506

Also, the above comment from sujay implies but does not explicitly state 
confirmation. Reopening.

Comment 7

[rubydoo123]

not exactly sure if this goes to mike, joe or simon -- starting with mike

Comment 8

[Henrik Lynggaard Hansen]

This bug is targeted for mozilla 1.0.1 (out now) but have not been touched since
2001-07-06

Could someone please verify if this is still a problem, or close the bug if the
problem is gone

Comment 9

[Aaron Leventhal]

I am unable to reproduce the original report at this time.

Comment 10

[Brian Ryner (not reading)]

I think I have a fix for this.

Comment 11

[Brian Ryner (not reading)]

I was able to reproduce this using a different series of steps:

- set your prefs to open new browser windows to a blank page
- open a new browser window. focus should be in the URL bar.
- click a link from a mail message
- switch to the browser window (I did so by clicking on the gnome panel icon for
the window)
- click in the page content 

I've got a patch to fix this case and I'm suspecting that it fixes the other
cases as well.

Comment 12

[Brian Ryner (not reading)]

Attachment: patch

This patch does two things:

- Manually update the focus controller to mCurrentFocus after firing the focus
event at the content, on activation.  This is important because the latent
focus could be set to an element such as a xul textbox, which focuses inner
content in response to a focus event.

- Update both the focused window and focused element in navigator.js - the
focus controller doesn't enforce that the focused element is within the focused
window, but we assume that elsewhere.  (I'm planning to fix that at some
point).

Comment 13

[Johnny Stenback (:jst)]

Comment on attachment 123204 [details] [diff] [review]
patch

sr=jst

Comment 14

[Brian Ryner (not reading)]

checked in.

Comment 15

[[e-mail]]

Surely that patch breaks this line:

setTimeout(WindowFocusTimerCallback, 0, _content);

Comment 16

[Brian Ryner (not reading)]

I couldn't find any scenarios where focus didn't end up in the content area as
it should.  However, I can do a follow-up patch to make this work more explicitly.

Comment 17

[Brian Ryner (not reading)]

Attachment: follow-up patch

Ok, I think this should handle both cases correctly.

Comment 18

[[e-mail]]

Comment on attachment 125351 [details] [diff] [review]
follow-up patch

Great, thanks.

Comment 19

[jag (Peter Annema)]

Comment on attachment 125351 [details] [diff] [review]
follow-up patch

sr=jag

Are there other places in our code that need similar patching?

Comment 20

[Brian Ryner (not reading)]

checked in, for seamonkey and firebird (I don't think any other places need fixed).