424001 - "Try again" button of error page loads former site when tabs are restored by session restore

Status: VERIFIED DUPLICATE of bug 421067

(Core :: DOM: Navigation, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008031804 Minefield/3.0b5pre ID:2008031804

If you have Session Restore enabled and restart Firefox, the "Try again" button of the error page loads the former page when clicking twice.

Steps to reproduce:

1. Activate Session Restore
2. Open a website e.g. http://www.google.com in a tab
3. Restart Firefox
4. Open http://aoeu.mine.nu/~zan/crash.html within the same tab
5. Click on "Try again" twice

When clicking the second time on "Try again" the former site (in this case google.com) is loaded again. That shouldn't happen. If you do this directly after opening a new tab this behavior cannot be seen. We should still try to load the target website and not going back to the former website.

Comment 1

[Ria Klaassen (not reading all bugmail)]

I can't reproduce this on Windows. Maybe related to Bug 407548 and/or Bug 421067 ?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

It's also reproducible with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031806 Minefield/3.0b5pre ID:2008031806

Perhaps all of your mentioned bugs could be based on the same core issue. But I don't have an idea what exactly happens here. Perhaps Boris can help.

Ria, you have to clearly follow my given steps to reproduce this issue. It won't happen if you do not restart Firefox and just try it with a new opened tab. Instead the tab has to be restored by Session Restore first.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #2)
> don't have an idea what exactly happens here. Perhaps Boris can help.

I also have to CC him...

Comment 4

[Boris Zbarsky [:bzbarsky]]

As it happens, I watch docshell.  And I don't think I'll have time for this any time soon...

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I have to add that we are not going back to the former site. Instead the first entry of the history for this tab is displayed.

Comment 6

[Ria Klaassen (not reading all bugmail)]

Regression window for this is
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-02-19+04%3A00&maxdate=2006-02-19+14%3A00

Comment 7

[Boris Zbarsky [:bzbarsky]]

So presumably bug 302115.  Fun times!

I wonder whether we should be checking for a history load there before doing the GetRequestedIndex() bit.  It sounds like in this case, the requested index is 0, right?

Or is the problem that there is session history state that session restore is not restoring?  Someone would have to dig into what the session history looks like before/after the restore.

Comment 8

[Boris Zbarsky [:bzbarsky]]

And perhaps into what it looks like after loading the error page, for that matter.  Perhaps error pages need to UpdateIndex() on the sesion history?

Comment 9

[Boris Zbarsky [:bzbarsky]]

For what it's worth, calling UpdateIndex() in LoadErrorPage() doesn't seem to do anything.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #7)
> not restoring?  Someone would have to dig into what the session history looks
> like before/after the restore.

Boris, I could do but I don't know where to place the breakpoint right now. Could you give me a file and a line which can help me starting a debug session?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Perhaps breakpoint in nsGlobalWindow::Dump, then run javascript:window.dump('test') from, the URL bar?  Then you can examine that window's docshell, its session history, etc.  This will guarantee that you're looking at things in steady-state.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

No more work is necessary here. It will be fixed by bug 421067.

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified dup