648465 - Accessing opened window document triggers "Permission denied to access property 'document'"

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, I'm seeing the error I mentioned in the summary when clicking on the button, using Fennec.
I guess this is a bug in ipc, right?

Bookmarklets use this technique a lot, so they don't work currently in Fennec.

Comment 1

[Josh Matthews [:jdm]]

Attachment: Backtrace from the permission error

Comment 2

[Josh Matthews [:jdm]]

Presumably this occurs because about: urls are loaded in the chrome process?

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #2)
> Presumably this occurs because about: urls are loaded in the chrome process?

about:blank is special cased to open remotely

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

Johnny - Does this type of error seem like a compartments issue? Is it expected or not?

Comment 5

[Wesley Johnston (:wesj)]

This looks a lot like what I saw in bug 608331 (which I never really solved).

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Fix

Every time anyone does window.open() and a new window comes up and works, we should have a party. The problem here is that we grab the correct principal and fire an event to start the about:blank load. That load gives the newly-created window the proper principal. However, in the mean time, we have code that sets the "script opener's principal." But we only set that if the window was newly created (and not, e.g. returned as a result of finding a named window). Because TabChild always creates a new window, we have to tell the window watcher code that it should set the opener's principal.

Comment 7

[(no longer active)]

http://hg.mozilla.org/projects/cedar/rev/877c143cf39a

Comment 8

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/877c143cf39a

Comment 9

[(no longer active)]

The Maemo tests went orange, and this was the only patch which could affect mobile on cedar, so I backed it out:

http://hg.mozilla.org/mozilla-central/rev/1dcfffd2f3db

Comment 10

[(no longer active)]

This wasn't guilty, relanded:

http://hg.mozilla.org/mozilla-central/rev/979b2dace253

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

This did cause a Txul regression, but personally, I'd rather have the bug fixed and try to improve the regression over time:

> Regression :( Txul increase 15.3% on Nokia n900 mobile
> ------------------------------------------------------
>      Previous: avg 1223.181 stddev 107.049 of 30 runs up to revision 1dcfffd2f3db
>      New     : avg 1410.202 stddev 3.574 of 5 runs since revision d492992e2884
>      Change  : +187.021 (15.3% / z=1.747)
>      Graph   : http://mzl.la/e9P6Xv
>
> Changeset range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1dcfffd2f3db&tochange=d492992e2884
>
> Changesets:
>    * http://hg.mozilla.org/mozilla-central/rev/979b2dace253
>      : Blake Kaplan<[e-mail]>  - Bug 648465 - TabChild::ProvideWindow needs to tell the caller that the window is new; r=smaug
>      : http://bugzilla.mozilla.org/show_bug.cgi?id=648465

Comment 12

[Anna (Waverley)]

VERIFIED FIXED on:

Build Id: Mozilla /5.0 (Android;Linux armv7l;rv:6.0a1) Gecko/20110427 Firefox/6.0a1 Fennec /6.0a1 

Device: HTC Desire Z (Android 2.2)

Comment 13

[John Nagle]

May not be fixed for all cases.  See also Bug #715755 and Bug #693345.

I'm getting this from an add-on: 

Timestamp: 5/17/2012 1:33:52 PM
Error: An exception occurred.
Traceback (most recent call last):
  File "resource://551f2920-3c19-11e1-b86c-0800200c9a66-at-jetpack/api-utils/data/content-proxy.js", line 698, in 
    return name in obj || name in overload || name == "__isWrappedProxy" ||
Error: Permission denied to access property 'document'

Firefox 12, add-on SDK 1.6.1.

I've had ongoing problems where a content script is attached to a page and the page is replaced/reloaded while the content script still has timeouts and messages from the add-on pending.  There's a race condition somewhere, and sometimes, a content script continues to be active after the page is replaced by a new page from a different URL.  See Bug #693345 for background.  I suspect that some of these other bugs are a side effect of that one.

Comment 14

[Josh Matthews [:jdm]]

Thanks for the bug report, John. However, I guarantee this existing report has nothing to do with yours, since it has to do with various technologies that aren't in use in desktop Firefox. Would you mind filing a new bug so we can track your issue? It might be best to do so in the Addon SDK product to start with, until we determine that it's a problem in the core engine.

Comment 15

[John Nagle]

OK. The main bug for that problem is Bug 693345, and I've noted this there. The symptoms vary, because the main bug is that sometimes, an add-on content script instance is somehow reused for a new page with a new URL.  That, obviously, can generate a whole range of errors. One of the symptoms looks like this bug, but may well be unrelated.