[clickSelectsAll] use pointer cursor when hovering over url bar

RESOLVED INVALID

Status

SeaMonkey
Location Bar
P4
normal
RESOLVED INVALID
17 years ago
9 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 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.
(Reporter)

Updated

17 years ago
Blocks: 62496

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.0

Comment 1

17 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.

Comment 2

17 years ago
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

17 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.
(Reporter)

Comment 4

17 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

17 years ago
nav triage team:

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

Comment 6

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

Comment 7

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

Updated

16 years ago
Status: NEW → ASSIGNED
Priority: P2 → P4
Target Milestone: --- → mozilla1.1

Comment 8

14 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
Status: ASSIGNED → NEW
QA Contact: claudius
Target Milestone: mozilla1.1alpha → ---

Comment 9

13 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.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.