193799 - click+hold on a link brings up wrong context menu

Status: RESOLVED FIXED

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

Description

[Bjarne D Mathiesen]

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)

Comment 1

[Bjarne D Mathiesen]

Attachment: click+hold on link in browser

Comment 2

[Bjarne D Mathiesen]

Attachment: clik+hold on link in Mail/News

also note, the displaced position of the context menu

Comment 3

[saari (gone)]

->jkeiser for regression investigation 

Comment 4

[Boris Zbarsky [:bzbarsky]]

*** Bug 194023 has been marked as a duplicate of this bug. ***

Comment 5

[Asa Dotzler [:asa]]

Yep, gotta fix this before we ship. 
Adding to the blocker list. 

Comment 6

[John Keiser (jkeiser)]

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.

Comment 7

[John Keiser (jkeiser)]

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.

Comment 8

[John Keiser (jkeiser)]

Attachment: Patch

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.

Comment 9

[Johnny Stenback (:jst)]

Comment on attachment 115655 [details] [diff] [review]
Patch

sr=jst

Comment 10

[saari (gone)]

Comment on attachment 115655 [details] [diff] [review]
Patch

r=saari, We so need to fix this fundamentally...

Comment 11

[Asa Dotzler [:asa]]

Comment on attachment 115655 [details] [diff] [review]
Patch

a=asa (on behalf of drivers) for checkin to the 1.3 branch.

Comment 12

[John Keiser (jkeiser)]

Checked in to 1.3 and trunk.