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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mozilla, Assigned: john)
References
Details
(Whiteboard: fixed1.3)
Attachments
(3 files)
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
bryner
:
review+
jst
:
superreview+
asa
:
approval1.3+
|
Details | Diff | Splinter Review |
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)
Reporter | ||
Comment 1•22 years ago
|
||
Reporter | ||
Comment 2•22 years ago
|
||
also note, the displaced position of the context menu
Comment 4•22 years ago
|
||
*** Bug 194023 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Flags: blocking1.3?
Comment 5•22 years ago
|
||
Yep, gotta fix this before we ship.
Adding to the blocker list.
Flags: blocking1.3? → blocking1.3+
Assignee | ||
Comment 6•22 years ago
|
||
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.
Assignee | ||
Comment 7•22 years ago
|
||
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.
Assignee | ||
Comment 8•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Attachment #115655 -
Flags: review?(saari)
Assignee | ||
Updated•22 years ago
|
Attachment #115655 -
Flags: review?(saari) → review?(bryner)
Updated•22 years ago
|
Attachment #115655 -
Flags: review?(bryner) → review+
Assignee | ||
Updated•22 years ago
|
Attachment #115655 -
Flags: superreview?(jst)
Comment 9•22 years ago
|
||
Comment on attachment 115655 [details] [diff] [review]
Patch
sr=jst
Attachment #115655 -
Flags: superreview?(jst) → superreview+
Assignee | ||
Updated•22 years ago
|
Attachment #115655 -
Flags: approval1.3?
Comment 10•22 years ago
|
||
Comment on attachment 115655 [details] [diff] [review]
Patch
r=saari, We so need to fix this fundamentally...
Comment 11•22 years ago
|
||
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+
Assignee | ||
Comment 12•22 years ago
|
||
Checked in to 1.3 and trunk.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•22 years ago
|
Whiteboard: fixed1.3
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•