in messenger.xul, I have a popup defined as follows (note: there is another bug where you can't define the popup in an overlay): <popup id="emailAddressPopup" popupanchor="bottomleft"> <menuitem value="&AddToAddressBook.label;" oncommand="AddNodeToAddressBook(document.popupElement)"/> <menuseparator/> <menuitem value="&SendMailTo.label;" oncommand="SendMailToNode(document.popupElement)"/> </popup> Now, inside a JS file that gets pulled in from nsMsgHdrViewOverlay.xul, I have implementations of the methods inside the popup: SendMailToNode and AddtoAddressBookNode. when these methods get called, they are being given a null node. So document.popupElement is not being defined when I use the popup menu.

Sorry about this. The code has since been changed. It's "popupNode" and not popupElement.

popNode works for me. We might want to update the xpfe popup document on mozilla.org to use popNode.

unfortunately document.popupNode always returns the last node I added to my xul document that uses the popup and not the node that was used to bring up the popup. i.e. I inserted five titled buttons into the message header pane to represent five addresses. All of these titled buttons use the popup. Regardless of which address button I push, when I select a command from the popup, the node returned by document.popupNode is always the 5th address titledbutton. Hyatt, do you want me to re-open this or file a new bug?

I take it back. This may be related to Bug #21223 where the popup doesn't come up in the right place. As a result, in order to select an item in the popup menu I have to move the mouse down to the middle of the message pane where the popup appeared. I wonder if this mouse movement is causing me to mouse over another titledbutton which shifts the "focus" of the popup such that document.popupNode now returns the wrong node. Or maybe not....

Clearing INVALID resolution due to reopen of this bug.

Taking menu/popup bugs.

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.

Putting on beta1 radar.

bulk accepting xpmenu/popup bugs. sigh.

Putting on PDT+ radar for beta1.

mscott, is there currently any way i can debug this? i know that we're waiting on waterson's fix so the popup menus actually show up on those titledButtons in mail. I checked the code, and it looks like we're doing the right thing. We only set | document.popupNode| on a mouseDown. Maybe it's reset accidentally somewhere, and that's what I'd like to look into, but I need a test case in the product. ;)

adding waterson's popup bug as a dependency.

Pinkerton, first of all, thank you very very much for fixing the popup positioning bug. I just verified that your changes did indeed fix the problem . I talked to waterson about the JS changes I needed to make for my xul elements so the titledbuttons will work again. I'll check those in as soon as the tree opens. You'll just need to pull msgHdrViewOverlay.js in mailnews/base/resources/content. Then you'll be able to see the popupNode returning the wrong element problem. You mentioned that we set popupNode on a mouse down event. I need to mouse down in order to select the popup menu item. Could this mouse down be causing me to pick up the wrong popupNode?

yeah, that's my guess. if you can, set a breakpoint in nsXULDocument::SetPopupNode and see when it gets called as you go through the process. It should be called when you first mousedown, but my guess is that it might be called again when you pick the item in the popup.

SetPopup node was only getting called once. So that wasn't it. I tried it on the same message but clicking on two different titledbuttons. For both cases, XULPopupListenerImpl::MouseDown appeared to be returning the same dom node in mouseEvent->GetTarget( getter_AddRefs( targetNode ) ); I'll investigate some more.

i assume this happens on all platforms.

This is not actually the bug we thought it was, but a bug in the JS in msgHdrViewOverlay.js. Here's the scoop: the JS keeps a var called currentAddressData as an array of objects and tries to use the XULElements that are the address titledbuttons as indices. So when a selection is made from the menu, the code does: var key = document.popupNode; // key is of type XULElement var addrInfo = currentAddressData[key]; However, you just plain can't do this is JS! Arrays can only be indexed by int or by string, so using |key| this way causes key's toString() method to be invoked and the actual index becomes "[object XULElement]" -- certainly not anything that can be used to find the appropriate object! This is probably why the last address added is always being retreived. Something other than the XULElement needs to be used as the key. Changing the Summary, reassigning to mscott (who shouldn't feel stupid, I didn't know any of this either).

Shame on me. Thanks for doing all the detecive work Pink. I changed my code to not index off of dom node. I owe you one. Fix in hand.

I checked in the fix for this. Note add to address book isn't hooked up yet (that's in another bug) but clicking on send Mailto in the popup works. And the one in the commercial build works too =). Just click on an email address in the message pane, then select send mailto. Verify that hte compose window comes up filled with the right address.

marking as fixed for real.

Mozilla Build 2000-02-16-09M14: NT4 Commercial Build 2000-02-16-08M14: Linux Commercial Build 2000-02-16-08M14: Mac Verified Fixed. The correct email address is in the address pane of the new message and it also send the message successfully.