[PP] Mouse click events improperly handled (selection)

VERIFIED DUPLICATE of bug 14804

Status

()

P3
normal
VERIFIED DUPLICATE of bug 14804
19 years ago
19 years ago

People

(Reporter: elig, Assigned: joki)

Tracking

Trunk
PowerPC
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
* TITLE/SUMMARY
[PP] Mouse click events improperly handled (selection)

* STEPS TO REPRODUCE
0) Launch Apprunner
1) View www.netscape.cdom
2) Using the "Search the Web with" text field, alternate clicking on "Search" and
"the" three times.

* RESULT
 - What happened

The clicks are "compounded"; e.g. after clicking "Search", "the", and "Search",
the word "Search" will be selected. Clicking again on "the" results in the entire
line being selected.


 - What was expected

Behavior equivalent to Win32/Linux builds.


* REGRESSION

 - Occurs On
        Mac OS Apprunner (1999092208 optimized build)

 - Doesn't Occur On
        Win32 Apprunner (1999092208 optimized build [NT 4, Service Pack 3])
        Linux Apprunner (1999092208 optimized build)




* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
(Reporter)

Updated

19 years ago
QA Contact: janc → elig

Comment 1

19 years ago
adding myself to the cc list

Comment 2

19 years ago
Eli--how fast are you clicking?  Do you think that the clicks are being
misinterpreted as double or triple clicks?  Also, is the expected behavior
"placing the caret" or "selection of one or more characters"?

Thanks!
(Reporter)

Comment 3

19 years ago
I've typically clicked with at least 1 second in between clicks.

In this particular example, I believe that nothing should happen that's visible
to the user; the invisible editing caret should be placed upon each click.

Since the shift key isn't being held down (nor is a drag-selection being
performed), the clicks shouldn't be joined to form a selection.

Hope that helps.

Comment 4

19 years ago
Eli--This seems to work in my build right now.  I think Simon fixed it.  You
should be able to tell from today's build.  If it isn't fixed for you, please let
me know because I have a very simple straight-forward fix that will fix it if for
some reason Simon's fix doesn't fix all of the problem.  Thanks!
(Reporter)

Comment 5

19 years ago
Still present in today's build (1999092408, Mac OS only, of course.)

Comment 6

19 years ago
Eli--Ask to check this bug on Simon's development Mac. He has a simple fix which
might improve this for you.  If it's the fix, we can check it in and resolve this
bug.  If not, I'll look some more on Monday.

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 7

19 years ago
I think this is now a dup of bug 14804, which I fixed yesterday.


*** This bug has been marked as a duplicate of 14804 ***
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 8

19 years ago
Verified that 14804 is a duplicate of this bug.

This is too weird. I reproduced the problem using today's builds this morning. I
can't reproduce it today, even after trying for 15 minutes. There must be some
trigger.

Will re-open this bug or 14804 if I can reproduce it. Or, better yet, I'll just
go Simon's cubicle and drag him by the scruff of his BBEdit T-shirt... ;)
You need to log in before you can comment on or make changes to this bug.