Closed Bug 14627 Opened 26 years ago Closed 26 years ago

[PP] Mouse click events improperly handled (selection)

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 14804

People

(Reporter: elig, Assigned: joki)

Details

* 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).
QA Contact: janc → elig
adding myself to the cc list
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!
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.
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!
Still present in today's build (1999092408, Mac OS only, of course.)
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.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
I think this is now a dup of bug 14804, which I fixed yesterday. *** This bug has been marked as a duplicate of 14804 ***
Status: RESOLVED → VERIFIED
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... ;)
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.