Open Bug 695868 Opened 13 years ago Updated 2 months ago

Unable to set document.body.innerHTML of IFrame

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Project Flags:
Webcompat Priority P3

People

(Reporter: theosib, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [webcompat][needs-wpt-?])

Attachments

(3 files)

the testcase
612 bytes, text/html
Details
working example
642 bytes, text/html
Details
src workaround
637 bytes, text/html
Details 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/534.51.22 (KHTML, like Gecko) Version/5.1.1 Safari/534.51.22

Steps to reproduce:

I'm using the nightly, and I've looked for a cross-browser way to programmatically set the innerHTML of an IFrame.  (As in http://roneiv.wordpress.com/2008/01/18/get-the-content-of-an-iframe-in-javascript-crossbrowser-solution-for-both-ie-and-firefox/).

This is what I wrote:


<html>
<body>

<div name=FRAME2div id=FRAME2div style="position:absolute; background-color:blue; color:black; border-color:black;border-width:0; left:100px; top:40px; width:200px; height:200px; overflow:scroll; display:block; " >
</div>

<script type="text/javascript">
document.getElementById("FRAME2div").innerHTML = '<iframe border=0 id=IFRAME2 name=IFRAME2 ></iframe>';
document.getElementById("IFRAME2").contentWindow.document.body.innerHTML = '<html><body><p>NETSCAPE</p></body></html>';
</script>

</body>
</html>


Actual results:

It works fine in Safari and Chrome, but not in the latest nightly of Firefox.


Expected results:

I should see the word "NETSCAPE" appear in the blue box.
Someone suggested I access the innerHTML this way:

frames['IFRAME2'].document.documentElement.innerHTML = '<html><body><p>NETSCAPE</p></body></html>';

But that doesn't work either.
Attached file the testcase — 

    
    

    
  
Confirming on Win XP and FF10a1.
Interestingly, after loading the page, running the command:

document.getElementById("IFRAME2").contentWindow.document.body.innerHTML = '<html><body><p>NETSCAPE</p></body></html>';

from the Web Console does work.
Status: UNCONFIRMED → NEW
Component: General → DOM: Core & HTML
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
OS: Mac OS X → All
Hardware: x86 → All

    
    

    
  
I think the reason is because the document inside your iframe isn't created yet.
You should wait for the load event before setting something inside the iframe.

I'm going to attach an example that is working.

    
    

    
  

      
      
      
      

        Attached file
          
        working example
        — 
      

    


  

    
    

    
  
Henri, do we plan to follow what Webkit is doing here or should we WONTFIX this? (or DUPE maybe?)

    
    

    
  
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #6)
> Henri, do we plan to follow what Webkit is doing here or should we WONTFIX
> this?

I expect us to follow WebKit/spec here eventually. Marking as dependent on bug 543435.
Depends on: sync-about-blank

    
    

    
  
Someone suggested a workaround for this.  Before setting the innerHTML, we can trigger a false load.  Here's the new version that works, without needing to wait for an unload, which would be inconvenient for the real application (my code here is just the essential parts that demonstrate the problem):

<html>
<body>

<div name=FRAME2div id=FRAME2div style="position:absolute; background-color:blue; color:black; border-color:black;border-width:0; left:100px; top:40px; width:200px; height:200px; overflow:scroll; display:block; " >
</div>

<script type="text/javascript">
document.getElementById("FRAME2div").innerHTML = '<iframe border=0 id=IFRAME2 name=IFRAME2 ></iframe>';
doc = frames["IFRAME2"].document;
doc.open();
doc.close();
doc.body.innerHTML = '<html><body><p>NETSCAPE</p></body></html>';
</script>

</body>
</html>

I got the suggestion from here:
http://stackoverflow.com/questions/7828502/cannot-set-document-body-innerhtml-of-iframe-in-firefox

    
    

    
  
any news for this?

As you can see http://output.jsbin.com/yipemaweha this in Firefox not work, in chrome there are no problem.

    
    

    
  
This long-standing interop issue is still affecting sites adversely, so it's probably worth reconsidering its priority again after all this time.
Flags: webcompat?
See Also:  → https://webcompat.com/issues/16226
Whiteboard: [webcompat]
Flags: webcompat?
Priority: -- → P3

    
    

    
  
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.


Webcompat Priority: --- → ?

    
    

    
  
See bug 1547409. Migrating whiteboard priority tags to program flags.



    
    

    
  
(In reply to Henri Sivonen (:hsivonen) from comment #7)




(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #6)




Henri, do we plan to follow what Webkit is doing here or should we WONTFIX

this?




I expect us to follow WebKit/spec here eventually. Marking as dependent on

bug 543435.




Henri, is it the HTML standard that (should?) defines this?


Flags: needinfo?(hsivonen)
Whiteboard: [webcompat] → [webcompat][needs-wpt-?]

    
    

    
  
(In reply to Mike Taylor [:miketaylr] (PTO July 31 - Aug 8) from comment #13)




Henri, is it the HTML standard that (should?) defines this?




This is in the HTML Standard, but a quick look suggests the level of detail is insufficient (about events):

https://html.spec.whatwg.org/#creating-a-new-browsing-context


Flags: needinfo?(hsivonen)
Webcompat Priority: ? → revisit
Webcompat Priority: revisit → P3

    
    

    
  
(In reply to Henri Sivonen (:hsivonen) from comment #14)




(In reply to Mike Taylor [:miketaylr] (PTO July 31 - Aug 8) from comment #13)




Henri, is it the HTML standard that (should?) defines this?




This is in the HTML Standard, but a quick look suggests the level of detail is insufficient (about events):

https://html.spec.whatwg.org/#creating-a-new-browsing-context




has an issue been opened about it?

https://github.com/whatwg/html/issues

And probably Henri would correctly phrase the issue. Or thomas?


We just created an intervention for webcompat because of this issue

https://github.com/mozilla-extensions/webcompat-addon/pull/175/files


Flags: needinfo?(wisniewskit)
Flags: needinfo?(hsivonen)

    
    

    
  
(In reply to Karl Dubost💡 :karlcow from comment #15)




has an issue been opened about it?




There is https://github.com/whatwg/html/issues/4965 from 2019.



    
    

    
  
This is somewhat less about the spec and more about what we can get done given our corpus of Gecko-specific test cases.


I already failed at fixing this in the summer of 2011. I now thing I understand the issues better, and part of my failure then was trying to fix too much at the same time.


My current thinking is that we should


    

  1. Change the docshell/content viewer-created about:blank from lazy to eager for the Web (keeping in lazy for XUL).
    2. 

  2. Change the ghost of the old HTML parser not to blow away the document created in step 1 and to make it only fire the relevant events.
    3. 



Flags: needinfo?(hsivonen)

    
    

    
  
Realistically, not going to happen while Fission requires the level of attention it is requiring right now.



    
  
Severity: normal → S3

    
    

    
  
Clear a needinfo that is pending on an inactive user.


Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.


For more information, please visit auto_nag documentation.


Flags: needinfo?(wisniewskit)

    
    

    
  
Redirecting the ni? to the correct Tom-account.


Flags: needinfo?(twisniewski)

    
    

    
  
I'm not sure what I can add here, aside from mentioning that we should probably revisit this again after bug 543435 lands, since it seems similar to the first option Henri mentioned in comment #17.


Flags: needinfo?(twisniewski)

    
    

    
  
A workaround, as identified in https://stackoverflow.com/questions/8240101/set-content-of-iframe#comment20993503_8240158, is to set the src property:


<iframe src="javascript:void(0);"></iframe>




    
    

    
  

      
      
      
      

        Attached file
          
        src workaround
        — 
      

    


  

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: