Closed Bug 298458 Opened 15 years ago Closed 14 years ago
overloading context menu is not working (document
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050620 Camino/0.9a1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050620 Camino/0.9a1 If I am overloading the default context menu with my own function, I am getting both menus the original in foreground and my own in background. This is working fine with Mozilla, Firefox and Safari and on Windows also with IE. Reproducible: Always Actual Results: - Expected Results: show only my own context menu
L. Perone, is this what you describe in bug 192276 comment 14?
J.Doods, yes this is the same bug. > L. Perone, is this what you describe in bug 192276 comment 14? *** This bug has been marked as a duplicate of 192276 ***
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Not a dup. Bug 192276 is explicitly about plugins.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #1) > L. Perone, is this what you describe in bug 192276 comment 14? yes, it is. I'll repost my testcase url here http://www.yellowspace.net/camino_tests/cm.html (control- or right-click on the text "CHAPTER EXAMPLE") Bug still exists in Camino Version 2005072508 (0.9a2+)
*** Bug 305921 has been marked as a duplicate of this bug. ***
This is one of our more serious content issues.
Priority: -- → P2
Target Milestone: --- → Camino1.0
i don't see us getting this working for 1.0. anyone disagree?
Target Milestone: Camino1.0 → Camino1.1
Camino's context menu handling is a little weird. When you right-click, the clicked widget's -menuForEvent: method gets called by Cocoa. We fire off an NS_CONTEXTMENU here. As a consequence, the embedding APIs (nsIContextMenuListener) call the app's OnContextMenu listener. However, rather than showing the context menu then, the app code uses it to just save a ref to the clicked DOM node. We unwind back down to the Cocoa widget call, whcih calls up the NSView hierarchy up the app level, where an implementation of -getContextMenu returns the NSMenu that Cocoa needs to be returned from this method. For embedders, nsDocShellTreeOwner registers a context menu listener. However, its ContextMenu() method always calls PreventDefault() on the event (to fix bug 78396), so context menu events will always have deafult behavior prevented on them (they always return nsEventStatus_eConsumeNoDefault). If the implementor of the oncontextmenu event in the content calls event.preventDefault(), the embedder's OnContextMenu() is not called, but Camino erroneously goes and returns an NSMenu anyway (likely with the wrong node information). That's what we should fix here.
Assignee: mikepinkerton → sfraser_bugs
Status: NEW → ASSIGNED
Target Milestone: Camino1.1 → Camino1.0
Comment on attachment 205578 [details] [diff] [review] Patch to only show the context menu if we got an OnContextMenu callback. r=pink
Attachment #205578 - Flags: review?(mikepinkerton) → review+
Status: ASSIGNED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → FIXED
I still got no contextual menu in the image of the testcase attachment (latest branch build).
(In reply to comment #14) > I still got no contextual menu in the image of the testcase attachment (latest > branch build). That is intended behavior in this case. Before the change, you saw the generic page menu (not the image menu).
Mass move of mis-filed bugs out of obsolete component; apologies for bugspam.
Component: Help → General
You need to log in before you can comment on or make changes to this bug.