1106271 - [E10S] triggerNode is missing with enabled E10S

Status: RESOLVED WONTFIX

(Firefox :: Extension Compatibility, defect)

Description

[TheRave]

User Agent: Mozilla/5.0 (Windows NT 6.3; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20141129030207

Steps to reproduce:

To get the underlying element where i have opened the context menu, I build a context menu entry in my addon within the bootstrap.js. With E10S triggerNode is missing in the parentNode tree. It works only with disabled E10S. 

menuItem.setAttribute('oncommand', 'console.log("test:" + this.parentNode.triggerNode);');




Actual results:

console output with enabled E10S:
test:null 

console output with disabled E10S:
test:[object HTMLParagraphElement]"


Expected results:

console output with enabled E10S:
test:[object HTMLParagraphElement]"

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey TheRave,

Can you give me a better sense of the structure of your DOM here?

It looks like you have a menuItem element as a child of a <p>?

And can you tell me what the oncommand handler is supposed to do with the triggerNode?

Comment 2

[TheRave]

No my menuItem is no child of this p element...not directly.

What i do here is only a right click on a webpage, to open the standard firefox context menu.

A click on my created menuItem in this fx context menu sends the found triggerNode via an event to my addon, to read out the content of this underlying element. 

My menuItem in context menu does this in non e10s:
menuItem.setAttribute('onclick', 'var event = new CustomEvent("addonMessage", {"detail":{ [this.id] : this.parentNode.triggerNode}}); document.defaultView.dispatchEvent(event);' );

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Ok, I understand, thank you TheRave.

Hey zombie - what is the pattern that the SDK uses for this case, where we want to get a reference to the node that's currently got the context menu opened on it?

Comment 4

[TheRave]

Found a other reference for the target: this.ownerDocument.defaultView.gContextMenu.target

Comment 5

[Tomislav Jovanovic :zombie]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #3)
> Hey zombie - what is the pattern that the SDK uses for this case, where we
> want to get a reference to the node that's currently got the context menu
> opened on it?

i'm only superficially familiar with XUL context menu api, but what i see most is the use of event.target inside the event handler, which should continue to work as a CPOW with e10s. 

solving this "the proper way" (without CPOWs) is fairly involved, and i'm not sure we have a clear understanding today on the best/recommended way for extensions (other than "use the addon-sdk high-level APIs").

TheRave, it looks like you found another approach. if you still have some questions, feel free to ask again, so we can dig-in deeper.

Comment 6

[TheRave]

Due the planed remove of CPOWs i doesnt know, if it makes sense to fix this bug. It's recommended to use triggerNode instead popupNode amd so i was surprised that this was not available. But ok, the other approach is working so this is ok for me, if you classify this bug as a wontfix. A fix of this bug is sure only an additional compatibility shim more.

On the other side, open a firefox context menu will always be chrome code and access to content will be sometimes necessary. At the moment I have planed to setup a click handler in frame script, send a message to chrome variables with the clicked "target content" and do the related action if i click the context menu entry. That's the plan.

Generally, my feeling here is, that we have to do many actions, which should work from alone behind the scenes. This will be done at the moment with CPOWs. Without CPOWs the fx knows also where i click, but there will be much more actions necessary to get to the final result. I understand the concept why all this is necessary, but this is my feeling here.

Comment 7

[:shell escalante]

hi triage team - based on comment 6 it sounds like we can close wont fix.  just put to triage in case there were any more details since then in this area to add to the bug

Comment 8

[Andy McKay]

Marking as won't fix based on the last two comments.