Closed Bug 193799 Opened 22 years ago Closed 22 years ago

click+hold on a link brings up wrong context menu

Categories

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

PowerPC
macOS
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: mozilla, Assigned: john)

References

Details

(Whiteboard: fixed1.3)

Attachments

(3 files)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; da-DK; rv:1.3b; MultiZilla v1.1.34 (c)) Gecko/20030217 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; da-DK; rv:1.3b; MultiZilla v1.1.34 (c)) Gecko/20030217 click+hold on a link brings up the same context menu as if one had just cliced on no content. ctrl+click brings up the correct context menu Reproducible: Always Steps to Reproduce: 1. clik+hold on a link Actual Results: the default context menu appeared. see screenshots Expected Results: brought up the context menu related to having selected a link mac-only issue ??? regression - not present i 2003-02-14 reason for major: most normal users on the mac uses click+hold instead of ctrl+click. I don't know what right-clicking will do, as I haven't got a multi-button mouse to test with. But right-clicking ought to bring up the context-menu for a link too. !!!NOTE!!! : This behaviour is also present in Mail/News (screenshots)
Attached image click+hold on link in browser (deleted) —
Attached image clik+hold on link in Mail/News (deleted) —
also note, the displaced position of the context menu
->jkeiser for regression investigation
Assignee: saari → jkeiser
*** Bug 194023 has been marked as a duplicate of this bug. ***
Flags: blocking1.3?
Blocks: 185889
Yep, gotta fix this before we ship. Adding to the blocker list.
Flags: blocking1.3? → blocking1.3+
OK, the code that handles the click-hold is in nsEventStateManager (see CreateClickHoldTimer). I somewhat suspect us of not clearing mCurrentTargetContent when we clear mCurrentTarget, but I'll have to get to my Mac to confirm.
OK, I haven't tracked this down completely yet, but the source of the problem is that for whatever reason the NS_CONTEXTMENU even is getting targeted at the nsHTMLDocument.
Attached patch Patch (deleted) — Splinter Review
The problem is that for people that just set the frame in ESM (and not in PresShell) we don't try to resolve the frame. This is one of the many boneheaded mistakes one can make when the target is stored in three freaking distinct places.
Attachment #115655 - Flags: review?(saari)
Attachment #115655 - Flags: review?(saari) → review?(bryner)
Attachment #115655 - Flags: review?(bryner) → review+
Attachment #115655 - Flags: superreview?(jst)
Comment on attachment 115655 [details] [diff] [review] Patch sr=jst
Attachment #115655 - Flags: superreview?(jst) → superreview+
Attachment #115655 - Flags: approval1.3?
Comment on attachment 115655 [details] [diff] [review] Patch r=saari, We so need to fix this fundamentally...
Comment on attachment 115655 [details] [diff] [review] Patch a=asa (on behalf of drivers) for checkin to the 1.3 branch.
Attachment #115655 - Flags: approval1.3? → approval1.3+
Checked in to 1.3 and trunk.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: fixed1.3
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: