Closed
Bug 172261
Opened 22 years ago
Closed 17 years ago
[FIX]Permission denied to call JS methods defined in Window after pressing back button
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla1.9alpha1
People
(Reporter: rrmaclac, Assigned: bzbarsky)
References
Details
(Keywords: verified1.8.0.12, verified1.8.1.4)
Attachments
(3 files)
819 bytes,
text/html
|
Details | |
7.98 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
3.28 KB,
patch
|
dveditz
:
review+
jst
:
superreview+
dveditz
:
approval1.8.1.4+
dveditz
:
approval1.8.0.12+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•22 years ago
|
||
Demonstrates successfully rendering dynamic pages with JS. Fails after pressing browser back button. BTW: works in IE5
Comment 2•22 years ago
|
||
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
Reporter | ||
Comment 3•22 years ago
|
||
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..
Assignee | ||
Comment 4•22 years ago
|
||
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•22 years ago
|
||
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.
Updated•18 years ago
|
Assignee: security-bugs → general
QA Contact: desale → ian
Comment 7•17 years ago
|
||
This may be related to https://bugzilla.mozilla.org/show_bug.cgi?id=301510
Assignee | ||
Comment 10•17 years ago
|
||
Assignee: general → bzbarsky
Status: NEW → ASSIGNED
Attachment #252685 -
Flags: superreview?(jst)
Attachment #252685 -
Flags: review?(jst)
Assignee | ||
Updated•17 years ago
|
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 11•17 years ago
|
||
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+
Assignee | ||
Comment 12•17 years ago
|
||
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
OS: Windows 2000 → All
Hardware: PC → All
Resolution: --- → FIXED
Comment 13•17 years ago
|
||
http://lxr.mozilla.org/mozilla/source/testing/mochitest/tests/test_bug172261.html
Flags: in-testsuite+
Assignee | ||
Comment 14•17 years ago
|
||
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/
Assignee | ||
Comment 16•17 years ago
|
||
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. :(
Assignee | ||
Comment 17•17 years ago
|
||
This doesn't fix bug 301510, but that would take a lot more work...
Attachment #256842 -
Flags: superreview?(jst)
Attachment #256842 -
Flags: review?(dveditz)
Updated•17 years ago
|
Attachment #256842 -
Flags: superreview?(jst) → superreview+
Comment 18•17 years ago
|
||
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+
Assignee | ||
Comment 19•17 years ago
|
||
I think so, yes. Good catch!
Comment 20•17 years ago
|
||
Comment on attachment 256842 [details] [diff] [review] 1.8 branch patch r=dveditz
Attachment #256842 -
Flags: review?(dveditz) → review+
Assignee | ||
Comment 21•17 years ago
|
||
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 22•17 years ago
|
||
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+
Comment 24•17 years ago
|
||
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.
Description
•