Closed Bug 648465 Opened 13 years ago Closed 13 years ago

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


(Firefox for Android Graveyard :: General, defect)

Not set


(Not tracked)

Firefox 6


(Reporter: martijn.martijn, Assigned: mrbkap)


(Keywords: testcase)


(3 files)

Attached file 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.
Presumably this occurs because about: urls are loaded in the chrome process?
(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
Johnny - Does this type of error seem like a compartments issue? Is it expected or not?
This looks a lot like what I saw in bug 608331 (which I never really solved).
Attached patch FixSplinter Review
Every time anyone does 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.
Assignee: nobody → mrbkap
Attachment #525719 - Flags: review?(Olli.Pettay)
Attachment #525719 - Flags: review?(Olli.Pettay) → review+
Keywords: checkin-needed
Flags: in-testsuite+
Keywords: checkin-needed
Whiteboard: fixed-in-cedar
Target Milestone: --- → Firefox 6
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-cedar
The Maemo tests went orange, and this was the only patch which could affect mobile on cedar, so I backed it out:
Resolution: FIXED → ---
This wasn't guilty, relanded:
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
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   :
> Changeset range:
> Changesets:
>    *
>      : Blake Kaplan<>  - Bug 648465 - TabChild::ProvideWindow needs to tell the caller that the window is new; r=smaug
>      :

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)
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.
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.
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.
You need to log in before you can comment on or make changes to this bug.