[clickSelectsAll] use pointer cursor when hovering over url bar



18 years ago
11 years ago


(Reporter: jruderman, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)




18 years ago
From mpt@mailandnews.com 2001-04-12 08:23 on bug 37587:

[When browser.urlbar.clickSelectsAll is enabled or after it's turned on by 
default and the pref is removed]

(1) If (and only if) the address field does not have focus, hovering over it
    should use {cursor: default}, not the {cursor: text} usually used for text
    fields. This indicates that clicking in the field will behave differently
    from a normal text field.

(2) On mousedown of the primary (e.g. left) mouse button, the cursor should
    change to {cursor: text}. This indicates that text can be selected with the
    mouse down, just as it can be for any other text field.


18 years ago
Blocks: 62496


18 years ago
Priority: -- → P2
Target Milestone: --- → mozilla1.0

Comment 1

18 years ago
This isn't the standard behavior on Windows, at least not Windows 2000 which I'm 
on right now.  Since the Location field is supposed to mimic a combobox, I'll 
use the Start > Run dialog as an example.  If I tab to give focus to the OK 
button, hovering over the Open field changes the cursor to the I-beam.  Clicking 
on the field selects the contents of the field.
Mousing over Internet Explorer 5.0's address field gives the `default' cursor, 
not the `text' cursor, in Windows 95, Windows 98, and Windows 2000.

Even if Internet Explorer didn't do this, I'd still say we should use the 
`default' cursor on unfocused mouseover, for the reasons described in the 
original bug report.

Comment 3

18 years ago
I'm fine with that, actually.  Minor point on #2, using IE again as an 
example.  The cursor doesn't change to an I-beam until either mouseup or 
mousemove.  We should probably do that as well, because it won't make sense to 
click-and-drag when the field doesn't have focus and clickSelectsAll is true.

Comment 4

18 years ago
But it does make sense to click-and-drag to select part of the URL when the URL
bar doesn't have focus.  See bug 62495, clickSelectsAll should not trigger if
you're selecting text.

Comment 5

18 years ago
nav triage team:

Usability improvement, pushing out to mozilla1.1
Target Milestone: mozilla1.0 → mozilla1.1

Comment 6

18 years ago
reassign url bar bugs to new owner..
Assignee: alecf → blakeross
Target Milestone: mozilla1.1 → ---

Comment 7

18 years ago
Joe was dying to have these bugs. Who am I to say no?
Assignee: blakeross → hewitt


18 years ago
Priority: P2 → P4
Target Milestone: --- → mozilla1.1

Comment 8

15 years ago
I agree with comment #4.  IE does not have the ability to click-and-drag to
select part of the URL when the URL bar doesn't have focus.  By using a pointer
cursor when hovering over the URL bar, this functionality is effectively hidden
from the user unless they accidentally happen to discover it.
Assignee: hewitt → location-bar
QA Contact: claudius
Target Milestone: mozilla1.1alpha → ---

Comment 9

14 years ago
I'd like to take back my comment from 3-1/2 years ago and agree entirely with
comment 4 and comment 8.  This is one area where we should differ from IE.

Marking this bug as invalid, as the I-beam cursor indicates to the user that
they can select text by clicking-and-dragging.  This isn't a bug, it's as designed.
Last Resolved: 14 years ago
Resolution: --- → INVALID
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.