172261 - [FIX]Permission denied to call JS methods defined in Window after pressing back button

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Ryan MacLachlan]

Scenario:
We are using JavaScript to render a page in a frame. When the user presses the
browser back button, the JavaScript functions defined in the main Window are no
longer visible.

The following exception comes up in the JavaScript console:
Error: uncaught exception: Permission denied to get property Window.gotoPage

BTW: works fine in IE5

Comment 1

[Ryan MacLachlan]

Attachment: Renders pages dynamically, fails after pressing back button..

Demonstrates successfully rendering dynamic pages with JS. Fails after pressing
browser back button.
BTW: works in IE5

Comment 2

[Phil Schwartau]

Confirming reported behavior with Mozilla trunk binary 20020930xx WinNT.
Browser, not engine ---> DOM Level 0.

Here is the testcase of the reporter:

<script>
function w(doc, s) { doc.write(s); }

function gotoPage( num, doc )
{
    doc.open();
    w( doc, '<b>Page ' + num + '</b><br>' );
    w( doc, '<A href="javascript:top.gotoPage(1,document)">page 1</A><br>' );
    w( doc, '<A href="javascript:top.gotoPage(2,document)">page 2</A><br>' );
    w( doc, '<A href="javascript:top.gotoPage(3,document)">page 3</A><br>' );
    w( doc, '<A href="javascript:top.gotoPage(4,document)">page 4</A><br>' );
    w( doc, '<p>click on the links at least once, <br>then press the browser 
back button, <br>click on a link again, <br>view exception in JavaScript 
console..' );
    doc.close();
}
</SCRIPT>


Is it the |doc.open()| that's causing the problem? If so, this would
be related to bug 114461, "document.open() clobbers JS context".

That is, does the document.open() somehow prevent access to the 
earlier-loaded function |gotoPage|? cc'ing Boris on that question -

Comment 3

[Ryan MacLachlan]

i doubt it has anything to do with the document.open() problem you mention.
in fact that line can be removed and it behaves the same..

Comment 4

[Boris Zbarsky [:bzbarsky]]

radha, is this related to the documents not getting the proper documentURI set
in the docshell when going back to a wyciwyg url?  And thus getting the wrong
security context?

Comment 5

[Radha on family leave (not reading bugmail)]

I don't think docshell's uri is an issue here. The wyciwyg page is loaded in the
subframe, top has a regular http url and it is top that is referenced again
after you go back. When you go back, only the subframe changes. It would be good
to know what triggers this exception before we dig deeper on the role wyciwyg
plays. My best guess is, the subframe does not have the right script context or
something like that when you go back. 

Comment 6

[Boris Zbarsky [:bzbarsky]]

to mitch, then.

Comment 7

[Anne-Sofie Nielsen]

This may be related to https://bugzilla.mozilla.org/show_bug.cgi?id=301510

Comment 8

[Boris Zbarsky [:bzbarsky]]

Indeed, it is.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Comment 11

[Johnny Stenback (:jst)]

Comment on attachment 252685 [details] [diff] [review]
Proposed fix

r+sr=jst

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.

Comment 13

[Jeff Walden [:Waldo]]

http://lxr.mozilla.org/mozilla/source/testing/mochitest/tests/test_bug172261.html

Comment 14

[Boris Zbarsky [:bzbarsky]]

So from what I understand, this bug is a PITA for people trying to do AJAX history navigation stuff, because they can't touch their iframes once people go back.

We could consider hacking principal comparisons on 1.8 branch so that http://foo can access wyciwyg:http//foo (but not the other way around, since CheckSameOriginPrincipal is asymmetric on the branch anyway).  I'm starting to think that might be a good idea... thoughts?

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It looks like the test for this bug is failing on linref test:

*** 874 INFO Running /tests/content/html/document/test/test_bug172261.html...
*** 875 INFO PASS | Domains should match
*** 876 INFO PASS | Domains should match 2
*** 877 ERROR FAIL | undefined | got true, expected "Locations should match"
*** 878 INFO PASS | Subframe should be able to call us

http://tinderbox.mozilla.org/MozillaTest/

Comment 16

[Boris Zbarsky [:bzbarsky]]

That's because I screwed up converting a todo() to an is(); todo() acts more like ok() than like is().

Fixed.  Sorry about the mess.  :(

Comment 17

[Boris Zbarsky [:bzbarsky]]

Attachment: 1.8 branch patch

This doesn't fix bug 301510, but that would take a lot more work...

Comment 18

[Daniel Veditz [:dveditz]]

bz: you'd want this in FF2 as well as FF1.5, right?

Comment 19

[Boris Zbarsky [:bzbarsky]]

I think so, yes.  Good catch!

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 256842 [details] [diff] [review]
1.8 branch patch

r=dveditz

Comment 21

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 256842 [details] [diff] [review]
1.8 branch patch

I think it's worth taking this on branches...

Comment 22

[Daniel Veditz [:dveditz]]

Comment on attachment 256842 [details] [diff] [review]
1.8 branch patch

approved for 1.8.0.12 and 1.8.1.4, a=dveditz for release-drivers

Comment 23

[Boris Zbarsky [:bzbarsky]]

Fixed on both branches.

Comment 24

[Tracy Walker [:tracy]]

verified with 
2.0.0.4 rc3 on Windows
and
1.5.0.12 on Mac
and
trunk on Windows