Closed Bug 50393 Opened 24 years ago Closed 24 years ago

<frame src="javascript:parent.foo()"> fails to load; throws error

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mlum, Assigned: jst)

References

(
URL
)

Details

(Whiteboard: [nsbeta3+] [fixinhand])

Attachments

(3 files)

Here is the HTML for anyone to analyze -
1.92 KB, text/plain
Details
simple test case for <frame src=javascript:parent.foo()>
353 bytes, text/html
Details
Proposed fix.
1.19 KB, patch
Details | Diff | Splinter Review 
This probably isn't useful, but anyway..

A promotion that appears (as expected) in NS 4.5 and IE (ick), doesn't appear
in mozilla (2000082513).  The image of the black cat that appears is pulled from 
server cache and displayed.  Clicking on the image uses MS's Jrun (VM) to 
dynamically generate a request based on the ID passed in the contentMapGroupId.

I should probably check if a Milestone build displays this.

steps to reproduce:
1. access the above URL
2. click on the cat
3. a pop-up appears 
4. no content in the pop-up

Observations: in the view source

1. '<' appear as \x3c references (like where <font> would be correct, \x3cfont> 
appears instead)

I'll bet that if these '\x3c' references were replaced with '<' the content 
would get displayed ;-)
Browser, not engine. Reassigning to Parser for further triage. 
cc'ing John Morrison. Is this a DTD issue?
Assignee: rogerl → rickg
Component: Javascript Engine → Parser
QA Contact: pschwartau → janc
Actually, the \xHH escaping appears to work correctly. What does not work
is the following example, whether using escaped hex values or straight up
ascii. 

<html>
<head>

<script>
function getPageSource() {
  //var str =  "\x3cB>this is in bold\x3c/B>";
  var str =  "<B>this is in bold</B>"; // this doesn't work either
  return str;
}
</script>
</head>

<frameset rows='*,100'>
  <frame src='javascript:parent.getPageSource()'>
  <frame src='http://www.mozilla.org/'>
</frameset>

</html>


--> DOM 0
Assignee: rickg → jst
Status: UNCONFIRMED → NEW
Component: Parser → DOM Level 0
Ever confirmed: true
QA Contact: janc → desale
Summary: '\x3c' instead of '<' → <frame src="javascript:parent.foo()"> fails to load; throws error
Forgot to note that the error in the console is NS_ERROR_FAILURE

JavaScript error:
 line 0: uncaught exception: [Exception... "Failure"  code: "-2147467259" nsresu
lt: "0x80004005 (NS_ERROR_FAILURE)"  location: "<unknown>"]

I'll take a look.
Assignee: jst → mstoltz
jst has offered to fix this. Thanks, Johnny!
Assignee: mstoltz → jst
Errh, I feel badly about adding an nsbeta3 nom., and you all probably already
realize that this must "just work" (it's a fundamental DOM0'ism), but anyways
to keep this on the radar ... nsbeta3
Keywords: nsbeta3
Attached patch Proposed fix. — — Splinter Review 

    
    

    
  
Just for the record, the proposed patch I attached is already reviewed by
Michell Stoltz.

Status: NEW → ASSIGNED

    
  
Whiteboard: [nsbeta3+] [fixinhand]

    
    

    
  
Marking nsbeta3+...


    
    

    
  
Classic did pretty much the same thing, but IIRC it had to go up the ancestor
line using a loop, to handle nested framesets.  Here, it looks like you'll
recursively ascend a frameset tree.  One thought: do you want to cache the value
in mDocumentPrincipal?  Any new doc loaded into the frame will call SetNewDoc
and change principals.  By asking your parent each time, it seems to me you make
it possible to get different principals at different times for the same frame
doc generated by javascript:.

/be

    
    

    
  
I think the attached patch is correct, I believe that there's no need to loop
over the ancestors explicitely since the way the patch is written, if for
whatever reason there wouldn't be a principal in the parent window, the parent
window will ask its parent, and so on (I don't however believe that it's
possible to have a parent that doesn't have a principal)...

As for caching the principal, once the result of the javascript: URL execution
is available we'll parse that into a HTML document and call SetNewDocument() on
the window and that call will cache the principal for that document, and the
principal for the new document will be the same as the one we get from the
parent in this case since (according to mstoltz) the docshell (or whoever)
effectively does the same thing when it calculates the principal for a document
that has a javascript: URL.

Please correct me if I'm wrong. Markin FIXED for now.

Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
Re: iteration vs. recursion -- I wasn't finding fault, just commenting.

The old codebase taught me that Murphy was an optimist.  While it seems as 
though there can be no case where a parent lacks a principal, and it's true that 
a new doc will arrive (via evaluation of the javascript: URL -- so long as the 
result is not undefined!), I worry that somehow, you'll get multiple calls to 
GetPrincipal that have to search.  That's not just inefficient in a really minor 
way that we needn't worry about, it makes for multiple possible states.

So what does happen when I write <frameset rows=...><frame name="frame1" 
src="javascript:top.voidFunction()">...</frameset>?  Do I get an empty frame, 
and no bogus security errors?  I'm not sure why anyone would do that, but I'm 
curious to know how things work.  A script in the top frameset could even then 
repeatedly set frame1.location = "javascript:void blah()".

/be

    
    

    
  
There still seems to be a problem.  Although the frame will be filled by <frame 
src=javascript:parent.something>, a subsequent attempt to write to that frame 
using document.open and document.write(something) will fail.  I noticed that 
View, Frame Source is blank for a frame filled by a javascript url.  Test case:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">
<html>
<head>
<script language="JavaScript">

var leftFrame = '<html><body><a href="javascript:parent.initialize()"><big>Start 
Test</big></a></body></html>';
  
var success = '<html><body><big>Success</big></body></html>';
  
var blankFrame = '<html><body></body></html>';
  
function initialize() {
  self.right.document.open();
  self.right.document.write(success);
  self.right.document.close();
}
// end script -->

</script>
</head>
<frameset cols="120,*" >
  <frame name="left" src="javascript:parent.leftFrame">
  <frame name="right" src="javascript:parent.blankFrame">
</frameset>
</html>

Note that this works if the frame if filled with external files, as in:

  <frame name="left" src=left.htm>
  <frame name="right" src=blank.htm>

Tested with Build 2000092008 thru 2000092205.

    
    

    
  
Reopening. This is fixed for the original problem as reported by mlum. 
However, Mark Reed notes that there is a problem with security principals
when overwriting the contents of a frame. For Mark's testcase, the following
exception is thrown:

[Exception... "Access to property denied"  code: "1010" 
 nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)"]

I could have opened a new bug, but since principals was already part of the
discussion on this bug, and mstolz is already CC on this bug, then I'll 
just reopen to deal with it here.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Closing again. John, please file a new bug on the problem with the principals,
and assign it to mstoltz. Please try to avoid reopening nsbeta3+:ed bugs unless
the real problem in the bug really isn't fixed (AFAIK, the problem reported in
this bug is indeed fixed) so that we don't need to reprioritize already nsbeta3+
marked bugs. Thanks!

Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
Opened bug 54060 for the situation pointed out by Mark Reed. (Sorry, for 
morphing; I generally don't do that, but I did so in this case for the 
reasons stated above). 

At any rate, yes, this is fixed for the originally reported problem. Marking
Verified. 
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: