Closed Bug 648465 Opened 10 years ago Closed 10 years ago
Accessing opened window document triggers "Permission denied to access property 'document'"
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).
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.
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #525719 - Flags: review?(Olli.Pettay)
Attachment #525719 - Flags: review?(Olli.Pettay) → review+
Target Milestone: --- → Firefox 6
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This wasn't guilty, relanded: http://hg.mozilla.org/mozilla-central/rev/979b2dace253
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 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 : 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<email@example.com> - 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
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)
Status: RESOLVED → VERIFIED
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.