Closed Bug 172261 Opened 17 years ago Closed 13 years ago

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

Categories

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

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla1.9alpha1

People

(Reporter: rrmaclac, Assigned: bzbarsky)

References

Details

(Keywords: verified1.8.0.12, verified1.8.1.4)

Attachments

(3 files)

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
Demonstrates successfully rendering dynamic pages with JS. Fails after pressing
browser back button.
BTW: works in IE5
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 -
Assignee: rogerl → jst
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → DOM Level 0
Ever confirmed: true
QA Contact: pschwartau → desale
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..
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?
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. 
to mitch, then.
Assignee: jst → mstoltz
Assignee: security-bugs → general
QA Contact: desale → ian
Indeed, it is.
Blocks: 301510
Duplicate of this bug: 220312
Attached patch Proposed fixSplinter Review
Assignee: general → bzbarsky
Status: NEW → ASSIGNED
Attachment #252685 - Flags: superreview?(jst)
Attachment #252685 - Flags: review?(jst)
Summary: Permission denied to call JS methods defined in Window after pressing back button → [FIX]Permission denied to call JS methods defined in Window after pressing back button
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 252685 [details] [diff] [review]
Proposed fix

r+sr=jst
Attachment #252685 - Flags: superreview?(jst)
Attachment #252685 - Flags: superreview+
Attachment #252685 - Flags: review?(jst)
Attachment #252685 - Flags: review+
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
OS: Windows 2000 → All
Hardware: PC → All
Resolution: --- → FIXED
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?
Flags: blocking1.8.0.11?
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/
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.  :(
Attached patch 1.8 branch patchSplinter Review
This doesn't fix bug 301510, but that would take a lot more work...
Attachment #256842 - Flags: superreview?(jst)
Attachment #256842 - Flags: review?(dveditz)
Attachment #256842 - Flags: superreview?(jst) → superreview+
bz: you'd want this in FF2 as well as FF1.5, right?
Flags: blocking1.8.1.4+
Flags: blocking1.8.0.12?
Flags: blocking1.8.0.12+
I think so, yes.  Good catch!
Comment on attachment 256842 [details] [diff] [review]
1.8 branch patch

r=dveditz
Attachment #256842 - Flags: review?(dveditz) → review+
Comment on attachment 256842 [details] [diff] [review]
1.8 branch patch

I think it's worth taking this on branches...
Attachment #256842 - Flags: approval1.8.1.4?
Attachment #256842 - Flags: approval1.8.0.12?
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
Attachment #256842 - Flags: approval1.8.1.4?
Attachment #256842 - Flags: approval1.8.1.4+
Attachment #256842 - Flags: approval1.8.0.12?
Attachment #256842 - Flags: approval1.8.0.12+
Fixed on both branches.
verified with 
2.0.0.4 rc3 on Windows
and
1.5.0.12 on Mac
and
trunk on Windows
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.