Closed Bug 400935 Opened 12 years ago Closed 12 years ago

Opening the identity box shouldn't select the address

Categories

(Firefox :: Address Bar, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 3 beta1

People

(Reporter: dao, Assigned: dao)

References

Details

Attachments

(2 files)

Attached patch patchSplinter Review
The current behaviour looks broken; there's too much unrelated stuff happening at the same time. Opening the identity box by clicking the favicon shouldn't select the address.
Attachment #285984 - Flags: review?(mconnor)
Note that people start to look for workarounds:
- bug 395174
- http://forums.mozillazine.org/viewtopic.php?p=3108225#3108225

IMHO none of the proposed solutions or current workarounds is good enough. If your goal is to select / replace the address, the identity popup shouldn't show up in the first place. If your goal is to open the identity popup, selecting the address might not be a deal breaker, but it's a little bit odd / unnecessarily distracting at least.
Flags: blocking-firefox3?
IMO the right behavior should be not opening the identity popup and selecting the adress. This is the only shure way of selecting the adress in the UI. This should not be broken. There is confusion that is right.
I think the identity pop-up is a nice feature but not that _very_ important that people should change their habits, developed for good reasons over years, entirely. Maybe for some people the info is important, but my surfing is usually without any risk :).
It's the same like changing the function of the Enter key.
Personally I don't care that the pop-up appears when I want to type, as long as it disappears after the first keystroke. 
Maybe it should have its own icon. In that case the statusbar would be a good place for it.
Flags: blocking-firefox3? → blocking-firefox3+
This bug should be clicking favicon should not open identity popup ! A lot peoples, not advanced users, I know use the favicon to select address bar for shure. This is really the behavior that is associated with it. Don't break this.
On Windows you can select the address with a single click anyway. On Linux it's a double click.

(In reply to comment #4)
> This bug should be clicking favicon should not open identity popup !

For that we'd need a new way to open the Identity popup. If you have a concrete idea, please file a new bug.
Keywords: uiwanted
(In reply to comment #5)
> On Windows you can select the address with a single click anyway. On Linux it's
> a double click.
> 
The safest way is triple-click, but not always. Sometimes this has the opposite result. I once filed Bug 352336 for the issue, but although the problem is unchanged (at least), I could not reproduce the testcase anymore.
FYI: In addition, when clicking the identity box and the address becomes selected,clicking elsewhere (window, menu bar, title bar, etc. does not unselect the address.

It also appears it may be intermittent. When I clicked in the address urlbar to unselect the address and then clicked the identity box again, the address did not select. I tried repeating that in other tabs and the address did not select in them either.

No errors showing error console.
(In reply to comment #5)
> On Windows you can select the address with a single click anyway. On Linux
> it's a double click.

Except that double clicking the location bar will replace the contents of the X11 selection, which clicking on the favicon won't do. This can actually be quite handy sometimes when you need a fast way to clear the location bar to replace it with a slightly edited version of a URL selected elsewhere (click favicon, press DEL, middle click paste into URL bar, edit, press enter).

Not sure what the best solution is here.
Comment on attachment 285984 [details] [diff] [review]
patch

has ui-r from beltzner and I already from triage

we should get this for b1, IMO.
Attachment #285984 - Flags: review?(mconnor)
Attachment #285984 - Flags: review+
Attachment #285984 - Flags: approvalM9?
Comment on attachment 285984 [details] [diff] [review]
patch

a=endgame drivers for M9
Attachment #285984 - Flags: approvalM9?
Attachment #285984 - Flags: approvalM9+
Attachment #285984 - Flags: approval1.9+
Keywords: checkin-needed
Checking in browser/base/content/browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.880; previous revision: 1.879
done
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 M9
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; es-ES; rv:1.9a9pre) Gecko/2007110518 Minefield/3.0a9pre.  

Location bar no longer highlighted.
Status: RESOLVED → VERIFIED
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110523 Minefield/3.0a9pre

Is still selecting the address field, but not always. Also with a new profile.

There are problems with this patch.
Happens always after startup, sometimes after opening new tab, and when it is selected it is not possible to remove the selection with a click in the page.
When it is selected and you click in the URL field it deselects briefly and selects it once more. When it is selected it is not possible to type a URL.

Status: VERIFIED → REOPENED
Resolution: FIXED → ---
That's a different and deeper focus bug, which is technically unrelated to this one.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
(In reply to comment #14)
> That's a different and deeper focus bug, which is technically unrelated to this
> one.
> 

What is the bug number?
In case that's a Core bug, it's probably already filed, but I don't have a number handy. I guess it would make sense to file a new bug specifically for the Location bar.
Ok, this is not as unrelated as I thought it would be. It's happening because the click event bubbles from the identity box to the textbox. Not sure why this only selects the address on the first click, but let's handle it here anyway.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Attached patch follow-upSplinter Review
Attachment #287530 - Flags: review?(gavin.sharp)
Flags: in-litmus?
Comment on attachment 287530 [details] [diff] [review]
follow-up

why are we eating all clicks here?  Shouldn't we only eat the events that we're actually not ignoring?
The textbox click handler proceeds regardless of the mouse button. For example, a right click selecting the address will look similarly broken, imho; the context menu that will be opened is the generic toolbox one rather than the context menu for the input field.
Attachment #287530 - Flags: review?(gavin.sharp) → review+
mozilla/browser/base/content/browser.js 	1.882 
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Attachment #287530 - Flags: approvalM9?
Attachment #287530 - Flags: approval1.9?
Comment on attachment 287530 [details] [diff] [review]
follow-up

a=beltzner for M9 post-hoc :)
Attachment #287530 - Flags: approvalM9?
Attachment #287530 - Flags: approvalM9+
Attachment #287530 - Flags: approval1.9?
Attachment #287530 - Flags: approval1.9+
verfiied with nightly builds on Win XP and Mac
Status: RESOLVED → VERIFIED
https://litmus.mozilla.org/show_test.cgi?id=5011

in-litmus+
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.