Closed Bug 1018265 Opened 10 years ago Closed 10 years ago

iFrame containing Javascript Alert dialog fails after leaving and returning to page

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Version:
29 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla33

People

(Reporter: dvs, Assigned: smaug)

Details

Attachments

(2 files, 3 obsolete files)

+tests
7.15 KB, patch
bzbarsky
: review+
Details | Diff | Splinter Review
+comment
7.30 KB, patch
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130216 Firefox/17.0 (Nightly/Aurora)
Build ID: 20130218031018

Steps to reproduce:

Create element within iframe which uses javascript onclick to call alert(). Go forward a page (either through a link or by typing in a new URL), then hit back button.

Example outer frame ("outer.htm"):
<!DOCTYPE html>
<html>
<iframe src="frame1.htm"></iframe> <frame src=frame1.htm>
</html>

Example inner frame ("frame1.htm"):

<!DOCTYPE html>
<html lang="en"><body>
<a href="" onclick="alert('alert')">Show alert</a>
<a href="otherpage" target="_top">Next page</a>
</body></html>

To reproduce with above example:

* load outer.htm
* click on "Show alert" to verify alert works.
* click on "Next page" 
* hit back button
* click on "Show alert". Alert fails.



Actual results:

No alert dialog appears. 


Expected results:

An alert dialog appears.
This is really weird.  After the back we seem to have dialogs disabled on the current inner of the top window nsGlobalWindow::AreDialogsEnabled finds...  Are we ending up with things hooked up to the wrong inners somehow in the bfcache case?
Flags: needinfo?(bugs)
Note: apologies for the stray text - the Example Outer Frame "outer.htm" example should be:

<!DOCTYPE html>
<html>
<iframe src="frame1.htm"></iframe>
</html>
Something bizarre going here.
We load a new inner window?
Assignee: nobody → bugs
Flags: needinfo?(bugs)
I don't _think_ we create new inners during the back navigation....
You don't need the any back-forward here to see the odd behavior.
Let me upload a testcase.
Attached file inner.html (obsolete) — 

    
    

    
  

      
      
      
      

        Attached file
          
        test (obsolete)
        — 
      

    


  

    
    

    
  
Oh, silly me. That is coming from the <a>. We do load to a new page...

        Attachment #8451013 -
        Attachment is obsolete: true

        Attachment #8451016 -
        Attachment is obsolete: true

    
    

    
  
Ok, so we never unhide contentviewers coming from bfcache. Patch and test coming.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch (obsolete)
        — 
          — Splinter Review
      

    


  
(still figuring out the tests)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        +tests
        — 
          — Splinter Review
      

    


  
The test is a bit silly, but mimics the testcase in this bug without
actual alert, but focuses on the actual bug about ContentViewer.isHidden

https://tbpl.mozilla.org/?tree=Try&rev=5aa732556a1a

        Attachment #8451170 -
        Attachment is obsolete: true

        Attachment #8451174 -
        Flags: review?(bzbarsky)

    
    

    
  
And yes, the whole setup of restoring from bfcache is rather horrible in ContentViewer/Docshell.
I'm sure mconley wants to clean it up ;)

    
    

    
  
Comment on attachment 8451174 [details] [diff] [review]
+tests

r=me if you add a nice IDL comment about who is or is not allowed to set that attribute and what setting it means.

        Attachment #8451174 -
        Flags: review?(bzbarsky) → review+

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/62f11352d198
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: