Closed Bug 12764 Opened 25 years ago Closed 21 years ago

Selection should only start after mouse down + mouse movement threshold

Categories

(Core :: DOM: Selection, defect, P3)

defect

Tracking

()

VERIFIED WORKSFORME
Future

People

(Reporter: dbaron, Assigned: mjudge)

References

(Depends on 1 open bug, )

Details

(Keywords: helpwanted)

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.
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.
QA Contact: chrisd → elig
Assignee: peterl → mjudge
Status: ASSIGNED → NEW
Component: Style System → Selection
Maybe a threshold on is needed on the minimum mouse movement needed to start
selection after the left mouse button is pressed down.
Status: NEW → ASSIGNED
This can wait till after beta push, setting to M15.
Summary: HR gets blue border when in active state → Selection should only start after mouse down + mouse movement threshold
*** Bug 16505 has been marked as a duplicate of this bug. ***
*** Bug 16053 has been marked as a duplicate of this bug. ***
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.
Target Milestone: M15 → M16
*** Bug 27528 has been marked as a duplicate of this bug. ***
moving to M17
Target Milestone: M16 → M17
per beppe moving to future.
Target Milestone: M17 → Future
adding help wanted to the keywords
Keywords: helpwanted
*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
*** Bug 21090 has been marked as a duplicate of this bug. ***
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
(a) from my previous comment is bug 97822, "Click on URL bar selects only first 
half of URL".
changing selection qa to tpreston.
QA Contact: blaker → tpreston
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...
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.
Depends on: 195966
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
As there is no testcase for a long time I close it as Invalid.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
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
Closed: 21 years ago21 years ago
Resolution: --- → WORKSFORME
For me too.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.