660780 - Offer a way to access unwrapped DOM nodes in content script

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P1)

Description

[Alexandre Poirot [:ochameau]]

We are going to block access to unwrapped DOM nodes from content script in bug 601295.
Nevertheless, we should provide such raw access in order to be able to customize webpages that:
- store usefull data in JS values,
    For example, facebook chat.
- offer custom JS API to interact with.
    For example, gmonkey object in gmail:
    http://code.google.com/p/gmail-greasemonkey/wiki/GmailGreasemonkey10API

We don't have enough time to introduce properly such access as we need some time to figure out uses, security and review strategies.

Here is two way to offer such access:
1/ Add an `unsafeWindow` in content scripts globals that gives raw access to document's `window` object.
2/ Add an `unsafe` attribute to page-mod, page-worker, ... i.e. all worker APIs that execute content script without any wrapper while being set to `true`.

Comment 1

[Naohiro Koriyama]

I like 'unsafeWindow' way like Greasemonkey.
So +1 for #1.
#2, I think it is overkill to access freely.

Anyway, I want to access functions/values defined in the document by some way, if it is not so dangerous.

Comment 2

[Alexandre Poirot [:ochameau]]

Naohiro: Can you tell us what sort of JS values or functions you want to access?
Having some usecase examples of unwrapped values would be good to know.

Comment 3

[Hernán Rodriguez Colmeiro (:peregrino)]

I have a usecase here. My addon is a remote control for a web based player, letting you play/pause/change track, etc without actually focusing the webpage. I did a pagemod that basically runs the same code that the callbacks on the actual buttons on the page, running some methods on a global Player object.
Not having raw access to the page window means I can't reach that Player object, rendering the whole addon useless :) 
By the way, right now the addon has ~3k daily users.

Comment 4

[Alexandre Poirot [:ochameau]]

Attachment: First proposal: add `unsafeWindow` in content script globals

So here is the simple implementation of `unsafeWindow`.
It's a first step to show how easy it is to add.

Comment 5

[Christoph Dorn]

Another use-case. My extension loads a UI in a window that I need to communicate with. The contentScript must bridge the communication channel between the worker from the extension side and the comm API on the loaded web page. This means from a contentScript I need to be able to:
 1) Call a method on window passing the message payload
 2) Set a function on window so page can send message to extension
The `unsafeWindow` patch will work for me.
#1 +1
#2 -1 also think that is overkill and will make transition later harder

Comment 6

[Myk Melez [:myk] [@mykmelez]]

This late-breaking change seems to have broken a bunch of existing addons.  We still don't know quite how to implement this feature, but it seems worth keeping those addons working while we figure it out, so drivers has agreed to land an experimental fix that folks can use while we figure out what to do in the long term.  Marking the bug blocking accordingly.  The patch still needs review to land, however.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 539497 [details] [diff] [review]
First proposal: add `unsafeWindow` in content script globals

>diff --git a/packages/api-utils/lib/content/worker.js b/packages/api-utils/lib/content/worker.js
>+      // Use greasemonkey naming convention to access unwrapped window object
>+      // so that content script can access document javascript values

Make this comment read as follows:

      // Use the Greasemonkey naming convention to provide access to the
      // unwrapped window object so the content script can access document
      // JavaScript values.
      // NOTE: this functionality is experimental and may change or go away
      // at any time!

r=myk with that change.

Comment 8

[Alexandre Poirot [:ochameau]]

Landed:
https://github.com/mozilla/addon-sdk/commit/1ba67c35a73e26e1fe81be1cfc85db26f403419d

Comment 9

[Myk Melez [:myk] [@mykmelez]]

Resolving this bug fixed, since we've provided a fix, even if it is undocumented and experimental.  We'll iterate on the design here and then file additional bugs as needed for the work we determine is necessary.

Comment 10

[Jonathan Mayer]

Another use case: instrumenting parts of the JavaScript API with __defineGetter__ and __defineSetter__.  While an unsafe attribute for page-mod etc. would be a bit tidier, wrapping code in

let(window = unsafeWindow)

is already fairly elegant.