Context menu API has a a notion of content scripts which are pretty exceptional, which is both problematic and incompatible with whatever we may end doing in a future. 1. Unfortunately context menu API needs to pass actual DOM nodes instead of serializing / parsing messages as all other uses of the content scripts. This implies some security risks for the very least. 2. Context menu's need to emit events synchronously which is incompatible with any kind of E10S we may ever have since chrome is not supposed to block content. 3. As far as I can tell same API can not be even implemented on Fennec and likely this will be the case for any new platform we will consider supporting. 4. Chrome's context menu APIs don't have such flexibility and they're doing just fine. If we'll need more flexibility we can always implement more flexible, but declarative context selectors. I think it would be the best to deprecate this feature and remove it in a future no matter how bad that sounds.
Oh yeah I almost forgot that we have a exceptional code path in event dispatch to let them aggregate return values from the listeners :(
+1000! No-one actually likes this pattern. We do need to consider all the use cases implied by being abjle to have a content script ( fairly open-ended ) and see how we can cover the most common ones.
Jeff, want to look into who is using this currently?
Priority: -- → P2
Depends on: 773914
Coming here from bug 825077, I just wanted to mention that the main use-case that I have is being able to work on the DOM node that was clicked: get its contents, various attributes, walk up the DOM hierarchy if needed, etc. As long as we're given a unique way to reach the node that was clicked (e.g. unique CSS class name), I'm pretty sure anyone will be fine with dropping that weird feature from the context-menu script :)
I believe Mossop is looking into Bug 773914 that would allow us to deprecate this at some point. I suggested to pass same data as chrome, but that clearly won't address your use case. Adding unique css class names feel little hacky and will be observable by a pages that add-on work. Alternatively on click event may contain 'css' selector that can be used to select node that was clicked. I believe selector could be generated walking up the node hierarchy until reaching parent with id or a document root. Although it maybe a good idea to add options to enable specific event properties so we don't tax everyone regardless if they use feature or not.
Correct, having an observable side-effect of the sdk doesn't seem like an excellent idea. However, I still feel like having an escape hatch in case the default sdk-provided context" attributes are not enough would be worthwhile :). The CSS selector seems right, although it may prove expensive to querySelector it, and in case the element is inside an iframe, I don't think a CSS selector will be enough...
(In reply to Jonathan Protzenko [:protz] from comment #6) > Correct, having an observable side-effect of the sdk doesn't seem like an > excellent idea. However, I still feel like having an escape hatch in case > the default sdk-provided context" attributes are not enough would be > worthwhile :). The CSS selector seems right, although it may prove expensive > to querySelector it, and in case the element is inside an iframe, I don't > think a CSS selector will be enough... It will be css selector that would run on the document in the iframe.
OS: Mac OS X → All
Hardware: x86 → All
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1070952
You need to log in before you can comment on or make changes to this bug.