Selection should only start after mouse down + mouse movement threshold

VERIFIED WORKSFORME

Status

()

P3
normal
VERIFIED WORKSFORME
19 years ago
15 years ago

People

(Reporter: dbaron, Assigned: mjudge)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {helpwanted})

Trunk
Future
helpwanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

DESCRIPTION:  When you click on the HR element in the above URL (the horizontal
rule), it gets a blue border around it.

STEPS TO REPRODUCE:
 * Load above URL ( http://asp1.sbs.ohio-state.edu/text/severe/atltrop/ )
 * click on horizontal line just below column headers

ACTUAL RESULTS: horizontal line gets a blue border

EXPECTED RESULTS: no blue border

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, build from source 1999-08-28, 12:15 PDT

ADDITIONAL INFORMATION:
I was thinking there was a problem in ua.css causing this, but I couldn't find
one.

Comment 1

19 years ago
Pushing off non-beta 1 issues
I am 99% sure this is a Text Selection thing. When you select text, it gets an
xored rectangle behind it. Well, HRs get this blue border. You can prove this
be selecting text either side of an HR - the HR gets blued.

Updated

19 years ago
QA Contact: chrisd → elig

Updated

19 years ago
Assignee: peterl → mjudge
Status: ASSIGNED → NEW
Component: Style System → Selection

Comment 3

19 years ago
Maybe a threshold on is needed on the minimum mouse movement needed to start
selection after the left mouse button is pressed down.

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 4

19 years ago
This can wait till after beta push, setting to M15.

Updated

19 years ago
Summary: HR gets blue border when in active state → Selection should only start after mouse down + mouse movement threshold

Comment 5

19 years ago
*** Bug 16505 has been marked as a duplicate of this bug. ***

Comment 6

19 years ago
*** Bug 16053 has been marked as a duplicate of this bug. ***

Comment 7

19 years ago
I agree with the threshold thing. It's too easy to accidentally select one 
character in the location bar when you're just trying to place the insertion 
point.

Updated

19 years ago
Target Milestone: M15 → M16
(Assignee)

Comment 8

19 years ago
*** Bug 27528 has been marked as a duplicate of this bug. ***

Comment 9

19 years ago
moving to M17
Target Milestone: M16 → M17
(Assignee)

Comment 10

18 years ago
per beppe moving to future.
Target Milestone: M17 → Future

Comment 11

18 years ago
adding help wanted to the keywords
Keywords: helpwanted

Comment 12

18 years ago
*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
elig@netscape.com to BlakeR1234@aol.com.  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...
QA Contact: elig → BlakeR1234
(Assignee)

Comment 13

17 years ago
*** Bug 21090 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
I see this on WinNT:

(a) Mouse down on the location bar and move the mouse a tiny bit.  Only the part
of the URL to the left of the cursor is selected.
(b) Double-click on a word in a web page and then move the mouse a tiny bit. 
Only the part of the word to the left of the cursor is selected.
(c) Mouse down in the middle of a letter on a web page and move the mouse left
or right one pixel.  The letter is selected.
Note that (a) would probably be fixed by fixing bug 62495, making
clickSelectsAll trigger on mouseup rather than on mousedown.
Blocks: 62496
OS: Linux → All
Hardware: PC → All

Comment 15

17 years ago
(a) from my previous comment is bug 97822, "Click on URL bar selects only first 
half of URL".

Comment 16

17 years ago
changing selection qa to tpreston.
QA Contact: blaker → tpreston

Comment 17

16 years ago
The URL address at the top of this bug report no longer exist...  I had been
brought to this bug report by bug #163594 from vdvo@vdvo.net.  

Dbaron or reporter, can you verify if bug #163594 is a duplicate bug?  Since
that the URL of this bug report does not exist, so no idea of what that bug is like.

However, bug #163594 showed the guilty party for that bug is due to bug #159207
and this bug report exist way before bug #159207 which make it unlikely that bug
#163594 is a duplicate bug of this one...

Comment 18

16 years ago
Judging by this bug's description (comment 0), it's a direct dupe. Judging by
this bug's summary (which is more up-to-date), it's not, in fact, a dupe, but
fixing this would also fix the other bug. Pick your choice.

Updated

16 years ago
Depends on: 195966

Comment 19

15 years ago
this seems to be fixed. I cannot reproduce the bug in comment 0 on build
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.5) Gecko/20030925

Comment 20

15 years ago
As there is no testcase for a long time I close it as Invalid.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID

Comment 21

15 years ago
I'm not quite sure that everyone will agree with the INVALID resolution. Either
this bug is just about the HR selection issue described in comment 0, and then
this is a duplicate of bug 163594 and should be marked as such. Or it's a more
general issue, and then it's valid (though perhaps actually an RFE) and not fixed.

As far as I'm concerned, though, I don't particularly care. :-)
Changing URL to an equivalent page (it was just a standard apache generated
directory listing).
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
and marking worksforme, which is true.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → WORKSFORME

Comment 24

15 years ago
For me too.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.