Comments on .menu

[Aza]

Hi Drew,

I've continued to play around with Jetpack.menu. I still think it is rocking awesome. A couple thoughts though:

* Why is there a jetpack.menu.context.set but no jetpack.menu.popup.set? In general, there seems to be this odd break in symmetry between context menus and popup menus. [I'm trying to get the Tab Graph Jetpack demo to have a menu, but I've only successfully made a context menu]
  - Just like we have jetpack.menu.context.page.on("a") we should also have jetpack.menu.popup.on("a")?
* For context menu's on object's the context's document and window properties should, be default, return the wrappedJSObject version of themselves

-- aza | ɐzɐ --

[Drew Willcoxon]

> * For context menu's on object's the context's document and window
> properties should, be default, return the wrappedJSObject version of
> themselves

Atul should weigh in here, but this is where security fights usability.
wrappedJSObject exists because those objects are wrapped by
XPCNativeWrapper so that malicious content can't easily inject code into
chrome [1, 2, 3]. Returning wrappedJSObject would make Jetpack less
safe by default, but hopefully Atul has some thoughts. There are larger
issues not specific to menu of passing code between chrome and content.

> * Why is there a jetpack.menu.context.set but no jetpack.menu.popup.set?

I've had the same thought myself. OK, filed bug 527951 [4].

[1]
https://developer.mozilla.org/en/Safely_accessing_content_DOM_from_chrome
[2] https://developer.mozilla.org/en/XPCNativeWrapper
[3] https://developer.mozilla.org/En/WrappedJSObject
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=527951

Drew

[Aza]

Atul should weigh in here, but this is where security fights usability.
 wrappedJSObject exists because those objects are wrapped by
XPCNativeWrapper so that malicious content can't easily inject code into
chrome [1, 2, 3].  Returning wrappedJSObject would make Jetpack less
safe by default, but hopefully Atul has some thoughts.  There are larger
issues not specific to menu of passing code between chrome and content.

My understanding here was that Blake is working on wrappers (COWs) that mean we won't have to worry about that sort of privilege escalation.
 

 > * Why is there a jetpack.menu.context.set but no jetpack.menu.popup.set?

On another tack, Daniel Glazman had an interesting thought on the menu API:

http://www.glazman.org/weblog/dotclear/index.php?post/2009/11/13/Just-one-minor-note-on-Jetpack

Drew, what are your thoughts on this?

[Drew Willcoxon]

> On another tack, Daniel Glazman had an interesting thought on the
menu API:

What do other people think about what he says? Which is:

-----

I like Jetpack. Not sure I am going to use it myself but I like it. What
I'm not sure to like is the following line, taken from Jetpack Image
Editor (from Aza's blog):

jetpack.menu.context.page.on("img").add(...)

I clearly see an attempt at approaching natural language here. But it's
inside code that's supposed to be object-oriented. And I find it a bit
puzzling. If I read one word after another, it's not natural and not
even hierarchical. I think something like
jetpack.page.foreach("img").contextmenu.add(...) is more readable, more
instantaneously understandable. And then better tailored for the target
of Jetpack, people who are not XUL experts nor commonly versed into
add-on authoring.

-----

My thoughts are:

1. jetpack is an object. jetpack.menu is an object.
jetpack.context.page is an object. jetpack.context.page.on("img") is an
object. They're all objects. You can stop at any of those objects and
do anything you want with them.
2. How is it not hierarchical? You're going from the least-specific
menu object to the most. It's very plain.
3. What does that line of code have to do with XUL or add-ons experts?
That's a non sequitur.

I think Daniel's proposed code is fine, but it's just another way of
looking at it, and none of the English around it is relevant. It does
introduce the idea of jetpack.page, though, which is interesting. What
else would live there?

> My understanding here was that Blake is working on wrappers (COWs) that
> mean we won't have to worry about that sort of privilege escalation.

AIUI, COWs prevent content from accessing properties on chrome objects,
but they don't prevent chrome from accessing potentially dangerous
properties on content objects.

Drew

[Aza]

Daniel,

I really like the .page idea. You are right that it is a concept missing from Jetpack as it stands.

Currently we have two types of ways of doing something to the current page:
* jetpack.tabs.focusedTab.contentDocument
* jetpack.tabs.onReady() and jetpack.pageMod()

The first type is a modification to the page as it stands now, the second type modifies all pages (with some filter) as they load. What we are missing is a way of modifying all pages (or pages that match some criteria) as an invariant.

Would you mind taking a stab at a JEP?

-- aza | ɐzɐ --

On Sat, Nov 14, 2009 at 12:54 AM, Daniel Glazman <daniel....@disruptive-innovations.com> wrote:

Drew Willcoxon wrote:

jetpack.page.foreach("img").contextmenu.add(...) is more readable, more instantaneously understandable.

With Jetpack, in each page, for each "img"'s contextmenu, add...

My 10 years old son got it instantaneously. He did not understand at all
the form from Image Editor currently I quoted in my article...

</Daniel>