548486 - about:config context menu no longer appears

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: General, defect, P3)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

In 1.9.2-based builds, the recently-added (bug 306613) about:config context menu no longer appears.

hendy mentioned on irc the other day that the whole event flow has changed in 1.9.2; in particular, there's no longer a popupshow event we can listen for.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

hendy: what happens now is that gecko gives us a context menu event (i forget 
       what it's called), so showing the menu is OK, but doesn't fire the 
       popupshowing event
hendy: config.js listens for the latter event and hides/disables certain of the 
       menu items
hendy: so without that event firing, the menu looks pants
sauron: how does it work in Firefox, then, if the event is not fired; config.js 
        can't see a non-existant event 
hendy: dunno.
hendy: i just thought though: maybe before creating our NSMenu, we could 
       synthesize a popupshowing event and give it to gecko
sauron: ooh
hendy: that may work
hendy: i'll think about it some more and have a play later

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Moving the priority from the 2.1 planning document to this bug.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Where I'm confused still about comment 1 is that instead of getting an about:config menu with lots of stuff not disabled, we're back to getting the standard "selected text" browser context menu.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Some gdb output

I played around with this a little last night/today, and I'm still confused.

I broke on CHBrowserListener::HandleXULPopupEvent in 2.0.6pre and got the backtrace, and then I broke on various things in 2.1a1pre.  It seems like in 1.9.2 we never get anything after nsXULPopupListener::PreLaunchPopup, and I failed to track down anything concrete on how XUL popup showing had changed.

Then I logged eventType in CHBrowserListener::HandleEvent and changed our event-in-question from "popupshowing" to "contextmenu" in CHBL and CHBV.  We do indeed get the "contextmenu" event here (and everywhere else in content, so we'd have millions of spurious events to differentiate, were we to use it; it is what enn suggested originally in bug 306613 comment 13, though).

What I still don't understand, though, is why making that change didn't result in an (even ugly) about:config context menu in about:config, based on comment 1; those are the only two places we look for an event for this codepath, and if we find one, we go off into CHBrowserListener::HandleXULPopupEvent.

OK, we get as far as [mContainer onShowContextMenu:0 domEvent:inEvent domNode:domNodeSendingEvent] in |CHBrowserListener::HandleXULPopupEvent|, but we never hit |menuFromNode:| in NSMenu+Gecko.

Ah, we get as far as |if (nodeName.Equals(NS_LITERAL_STRING("popup")))| in BWC's |-contextMenu|, but that must evaluate to false because we never hit the very next line (NSLog tells me that nodeName appears to be empty).

I have no idea how to debug why nodeName is empty, though.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

cpeterso: do you think you might be able to look at this and maybe get any further than I did in comment 4?

Comment 6

[Chris Peterson [:cpeterson]]

The content menu seems to be thwarted in nsXULPopupListener::PreLaunchPopup() because the nsDOMMouseEvent is flagged as NS_EVENT_FLAG_NO_DEFAULT. If I hack PreLaunchPopup() to ignore the preventDefault flag, then Camino will display the correct context menu.

I'm not sure how to control this preventDefault behavior. All the code to create and dispatch nsUIEvents is in mozilla XUL code.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #6)
> The content menu seems to be thwarted in nsXULPopupListener::PreLaunchPopup()
> because the nsDOMMouseEvent is flagged as NS_EVENT_FLAG_NO_DEFAULT. If I hack
> PreLaunchPopup() to ignore the preventDefault flag, then Camino will display
> the correct context menu.

That's progress :)

Can we determine where/when in the event flow/handling process the event gets the NS_EVENT_FLAG_NO_DEFAULT flag?

Comment 8

[Chris Peterson [:cpeterson]]

Unfortunately, I doubt I will be able to make much progress on this particular bug. The XUL event code is pretty confusing and buried deep in Gecko internals.