416937 - After clicking site button and clicking elsewhere focus goes to address bar

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Gabriel Chadwick]

The focus after dismissing site button stays on address bar and selects address when it should not select the address. This behaviour can lead to unwanted editing of addresses. Confusing to me.

Steps to reproduce :

1. Click on site button.
2. Click elsewhere in Firefox window. (Not on identity popup or address bar).

Actual behaviour :

Address in address bar is selected.

Expected behaviour :

Dismiss identity popup only. To not select the address.

Comment 1

[[:Cww]]

This doesn't happen on 3.0b2.  What version are you reporting for?

Comment 2

[[:Cww]]

Let me edit that, this doesn't happen for me on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

Comment 3

[Gabriel Chadwick]

Using trunk nightly Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9b4pre) Gecko/2008021104 Minefield/3.0b4pre ID:2008021104. Would be a regression then. If someone is interested I can find a regression range.

Comment 4

[Ria Klaassen (not reading all bugmail)]

It doesn't bother me, although it is too laborious to use this as a new way to select the locationbar. It regressed somewhere in the last two weeks of Jan 2008.

Comment 5

[Ria Klaassen (not reading all bugmail)]

Although it takes two clicks, it is a good way to select the locationbar because it selects on mousedown. In fact is is a fix of Bug 403981. 

Comment 6

[Gabriel Chadwick]

(In reply to comment #5)
> Although it takes two clicks, it is a good way to select the locationbar
> because it selects on mousedown. In fact is is a fix of Bug 403981. 
> 

I don't think that clicking on the search field after clicking on the site button is a good way to select address bar. It should select the clicked item. Or at least only dismiss the popup and not select the address bar. Very confusing.

It does look like it fixes Bug 403981. But I think we should have a more coherent behaviour here.

Comment 7

[Ria Klaassen (not reading all bugmail)]

In fact clicking on anything outside Larry (titlebar, chrome, page) selects the locationbar. It's just the opposite behaviour. It may cause problems on sites with an input field like www.google.com. Former behaviour was to keep the cursor in the input- or text field after clicking on Larry.

It's also causing selection problems and wrong context-menus, at least using my default profile. 

Comment 8

[:Gavin Sharp [email: [e-mail]]]

This was caused by an intentional change to Larry's onpopuphiding handler from bug 407359.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Not going to block on this, but I agree that if the user clicks somewhere other than the location bar or the site identity button, we should be putting focus in that other place.

Johnath, are you the right person to take this?

Comment 10

[Gabriel Chadwick]

Since the identity button is a very important feature in Firefox 3 I really think some energy should be put towards fixing this bug. People that will use the button will find this behaviour very annoying. In other minor bug the address bar was considered as an important area for polish and this issue definitely needs some love. I would volunteer for testing if needed.

Comment 11

[Dão Gottwald [:dao]]

Bug 407359 comment 59 is wrong or doesn't apply anymore. Shift+Tab focuses the identity button, clicking doesn't.

Comment 12

[Dão Gottwald [:dao]]

Attachment: patch

We should also remove support for norestorefocus. It's only used in a test, which is probably bogus.

Comment 13

[Dão Gottwald [:dao]]

Attachment: patch

without the popup.xml changes

Comment 14

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #11)
> Bug 407359 comment 59 is wrong or doesn't apply anymore. Shift+Tab focuses the
> identity button, clicking doesn't.

As far as I can tell it's still true, at least on Mac and Linux. With this patch applied, if I focus the location bar, and then click the button, and dismiss the popup (either by pressing Esc or clicking the URL bar again), the focus stays on the button and I have to Tab to the location bar. It also keeps focus if I dismiss the popup by clicking on a text field in content (though that's no different than what we currently do apart from where focus ends up).

Comment 15

[Dão Gottwald [:dao]]

(In reply to comment #14)
> (In reply to comment #11)
> > Bug 407359 comment 59 is wrong or doesn't apply anymore. Shift+Tab focuses the
> > identity button, clicking doesn't.
> 
> As far as I can tell it's still true, at least on Mac and Linux. With this
> patch applied, if I focus the location bar, and then click the button, and
> dismiss the popup (either by pressing Esc or clicking the URL bar again), the
> focus stays on the button and I have to Tab to the location bar.

Bug 407359 comment 59 refers to the patch that made the identity button always focusable. That's not the case anymore. It's only focusable if the location bar has already focus, which is a) a less likely workflow and b) less strange and annoying than focusing and selecting the address when the panel is dismissed, regardless of where the focus was before.

> It also keeps
> focus if I dismiss the popup by clicking on a text field in content

I don't see this. What I see is that clicking a text field, like clicking anywhere else, gives focus to where it was before, because we consume the rollup event.

Comment 16

[Gabriel Chadwick]

Ping Gavin

Comment 17

[:Gavin Sharp [email: [e-mail]]]

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

OK, that makes sense. We'll have to mark bug 403981 WONTFIX when this lands though.

http://mxr-test.konigsberg.mozilla.org/addons/search?string=focusandselecturlbar has only two hits, one is a copy of browser.xul named browser3.0.xul, and the other is safeguarded by an if (window.focusAndSelectURLBar) check, so I guess we're probably OK to remove it even though we shipped it in 3.0.

Comment 18

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/0e067665df55

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

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

a191=beltzner

Comment 20

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/91f43293a9ef

Comment 21

[:Gavin Sharp [email: [e-mail]]]

I would have preferred we not remove focusAndSelectURLBar on the branch, despite comment 17...

Comment 22

[Dão Gottwald [:dao]]

(In reply to comment #21)
> I would have preferred we not remove focusAndSelectURLBar on the branch,
> despite comment 17...

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/4d2253d3fcf0

Comment 23

[Aakash Desai [:aakashd]]

verified FIXED on builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090507 Minefield/3.6a1pre ID:20090507032833

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090507 Shiretoko/3.5b5pre ID:20090507034334

Comment 24

[Alex Faaborg [:faaborg] (Firefox UX)]

This bug's priority relative to the set of other polish bugs is:
P1 - Polish issue that appears in the main window, or is something that the user may encounter several times a day.

effected the main window.