Shift click and click and hold on links don't bring up menu

VERIFIED DUPLICATE of bug 18726

Status

()

P1
normal
VERIFIED DUPLICATE of bug 18726
20 years ago
19 years ago

People

(Reporter: bam, Assigned: mikepinkerton)

Tracking

Trunk
PowerPC
Mac System 8.6
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

20 years ago
Doing a shift-click or a click-and-hold on a link should bring up a popup menu
as in Navigator. Mozilla does not currently appear to have this functionality.

Updated

20 years ago
Assignee: don → joki
Component: Apprunner → Event Handling
QA Contact: leger → janc

Comment 1

20 years ago
janc, is this one already written up.  Dup?

Updated

20 years ago
Assignee: joki → hyatt

Comment 2

20 years ago
hyatt, I'm going to give this to you for now since you own context menus.  We
can still have our further discussions of embedding api stuff.

Updated

20 years ago
Status: NEW → ASSIGNED
Target Milestone: M10

Updated

19 years ago
Blocks: 12670

Updated

19 years ago
Assignee: hyatt → don
Status: ASSIGNED → NEW

Comment 3

19 years ago
reassigning to don, infrastructure is in place

Updated

19 years ago
Assignee: don → law
Severity: enhancement → normal
Priority: P3 → P1
Target Milestone: M10 → M12

Comment 4

19 years ago
Bill, we need to get to the Mac-specific context menu stuff before beta ...

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 5

19 years ago
First, I need some clarification.

Shift-click on a link in Navigator does not bring up a menu (on Windows, at
least).  It is a shortcut for "Save link as..." on Windows.

My guess is that the 5.0 mouse event handling treats button down as "click" so
holding it down doesn't produce a context menu (on the mac, it never did/should
do this on other platforms, correct?).

So I think we need to:
1. Define precisely how we want this to work (on each platform).
2. Decide which problem (deviation from expected behavior defined in step 1)
*this* bug is for and assign that bug appropriately.
3. Open and assign new bugs for any other deviations from the behavior described
in step 1.

I don't think any of those bugs will ultimately be assigned to me or my xpapps
friends, but I'm willing to keep this one till an appropriate assignee can be
identified.

Comment 6

19 years ago
Still waiting for clarifications.

Updated

19 years ago
Assignee: law → joki
Status: ASSIGNED → NEW

Comment 7

19 years ago
OK, since I don't really have any control over the event handling that
determines a context menu has been summoned, I'm going to attempt to reassign
this to those who do (back to the owner of the "event handling" component).
On MacOS, the standard combination for bringing up the context menu is Ctrl-
click, not Shift-click. (See URL.) Shift-click-and-hold should work, but only
because the Shift is ignored and it's assumed to be the same as a normal
click-and-hold (the context menu appears after a delay of about 0.5 seconds).

Does Ctrl-click work? (I don't have a working current build.) If not, the Summary
should be changed.

Comment 9

19 years ago
control-click does work.  It brings up a contex menu.

Comment 10

19 years ago
Moving to m13 because Joki seems to be distracted.

Updated

19 years ago
Assignee: joki → saari

Comment 11

19 years ago
Somebody dealing with context menus can have this one.  Saari?

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M13 → M15

Comment 12

19 years ago
M15
(Assignee)

Updated

19 years ago
Assignee: saari → pinkerton
Status: ASSIGNED → NEW
(Assignee)

Comment 13

19 years ago
Taking menu/popup bugs.
(Assignee)

Updated

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

Comment 14

19 years ago
*** This bug has been marked as a duplicate of 18726 ***

Comment 15

19 years ago
verified dup
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.