344185 - On restore from crash, page does not function identically

Status: RESOLVED DUPLICATE of bug 389274

(Firefox :: Session Restore, defect)

Description

[Peter Kasting]

I'm not sure why, but when I restore from a crash, the javascript on the page I'm on doesn't always seem to work right.  See the below example.  This was tested only on Linux with a trunk build.

Steps to reproduce:
(1) Visit https://bugzilla.mozilla.org/attachment.cgi?id=223546 with a trunk build
(2) Follow instructions on the page, so the browser crashes
(3) Restart browser and choose to restore session
(4) Try to follow instructions again by right-clicking in textarea.  Note that iframe is not removed from page and console gives JS errors.
(5) Navigate away from the page (I use the back button), then back to it.
(6) Now right-click on textarea and notice that JS works properly.

Comment 1

[Dietrich Ayala (:dietrich)]

Right now, restored page-content is pulled from the cache, or reloaded. Any modifications made to the DOM after the page is finished loading are neither saved nor restored. However, there are some possibilities in the Firefox 3 timeframe: utilizing bfcache, or if the current interest in offline web apps results in any code, maybe we could leverage it so solve this problem.

Comment 2

[Peter Kasting]

(In reply to comment #1)
> Right now, restored page-content is pulled from the cache, or reloaded. Any
> modifications made to the DOM after the page is finished loading are neither
> saved nor restored.

That's not the problem I'm discussing.  What I'm discussing is that when you visit this page for the first time, its Javascript functions correctly, whereas when you "restore from crash" to it, the Javascript doesn't work.  I don't expect Session Restore to restore the DOM modifications the page had made, but it doesn't even restore to a state that matches how the page was on load.

Comment 3

[Simon Bünzli]

Error: uncaught exception: Permission denied to get property Window.doe

What happens is that initially the testcase loads the iframe content from a data: URL whereas when SessionStore restores the history it sets the iframe's URL itself. It's still the very same data: URL, but there's an ownership relation which gets lost in the process.

Any ideas if this parent-child relation is somehow accessible through the session history entries (which we currently preserve to a relevant extent)?

Comment 4

[Dietrich Ayala (:dietrich)]

(In reply to comment #3)
> Error: uncaught exception: Permission denied to get property Window.doe
> 
> What happens is that initially the testcase loads the iframe content from a
> data: URL whereas when SessionStore restores the history it sets the iframe's
> URL itself. It's still the very same data: URL, but there's an ownership
> relation which gets lost in the process.
> 
> Any ideas if this parent-child relation is somehow accessible through the
> session history entries (which we currently preserve to a relevant extent)?
> 

I saved out the data URL to a separate file, and the scenario works fine. This would indicate that we are properly restoring the familial hierarchy, but that data URLs may have a different security policy.

Also, I tried changing to loadType to loadRefresh, and it solved the problem... a couple of times, then the behaviour reverted back to the permissions error. Possibly some user-error here :P

Comment 5

[Boris Zbarsky [:bzbarsky]]

I would have thought that the fix for bug 389274 would have fixed this.  Did it?

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to comment #5)
> I would have thought that the fix for bug 389274 would have fixed this.  Did
> it?

Peter do you still see problem?  URL of comment 0 no longer crashes. Bug 389274 fixed 2007-10-10

Comment 7

[Peter Kasting]

Without a testcase anymore, I can't verify this is fixed, but bz's supposition that this is really the same underlying bug as bug 389274 seems quite reasonable.  I'm just going to dupe.