303151 - fastback breaks gmail back button (when browser.sessionhistory.cache_subframes is true)

Status: RESOLVED DUPLICATE of bug 386782

(Core :: DOM: Navigation, defect)

Description

[Brian Ryner (not reading)]

Steps to reproduce:

1. Bring up your inbox in gmail
2. Click on a message
3. Click Back

Expected results: Return to your inbox view
Actual results: The message continues to be displayed

This works fine w/ fastback disabled.

Comment 1

[Brian Ryner (not reading)]

This might be similar to bug 298377, but here I have an easily accessible
testcase.  In gmail, an iframe is used to push a new history state for the page.
 When it wants to add a new session history entry, it navigates the iframe to a
new url.  When the iframe is navigated back by the browser, it calls a function
on its parent document that does whatever the desired "back" behavior is.

The reason fastback breaks this is that the inner iframe runs its handlers using
an onload handler, and so navigating the frame back does not run the script.

I see a couple of approaches we could take for this:

1. Leave our behavior as-is, and evangelize sites.  Taking this stance could
hinder adoption of Firefox 1.5.

2. We could deal with this particular case by avoiding the bfcache for subframe
navigation.  This by no means solves the problem in the general case, but may be
a good solution in practice.  We could perhaps optimize this case a little bit
by only making the document uncacheable if it has inline script or an onload
handler.

Comment 2

[Darin Fisher]

I'd lean toward #2, but I suppose it's just hard to know whether it is important
or not to the functioning of a web app to have inline script evaluate on
back/forward.

Comment 3

[Brian Ryner (not reading)]

Attachment: patch to avoid caching subframes

I'm not sure if this is the route we want to go for sure, but this patch would
avoid caching any page that is in a subframe... which has the effect of making
gmail work correctly.

Comment 4

[Matt]

fastback doesn't seem to just break Gmail's JavaScript in this sense.

Comment 5

[Brian Ryner (not reading)]

Please don't add dependencies such as this without verifying that the two
problems are related.  This is a specific instance where something breaks due to
not running the onload handler.  It sounds like there may be further problems
with fastback due to split-window, but that's quite unrelated to this bug, which
is a working-as-originally-designed aspect of fastback.

Comment 6

[Asa Dotzler [:asa]]

bryner, if that's the right route, can you shephard this patch in?

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

hm... what if a main page's script did some DOM modifications in the subframe?

Will this break the case where an entire frame is document.written? (e.g. an
<iframe> with initial source of about:blank)

Comment 8

[Brian Ryner (not reading)]

I believe this should no longer be a blocking issue because of the patch checked
in for bug 304860.  Renominating, can someone with authority to minus this
please do that if you agree?

Comment 9

[Jesse Ruderman]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050822
Firefox/1.0+

I can reproduce this bug when browser.sessionhistory.cache_subframes is true but
not when it is false.

Comment 10

[Mike Connor [:mconnor]]

minusing per comment 8 and comment 9

Comment 11

[Michael Gall]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3

I have browser.sessionhistory.cache_subframes set to false and this is happening. This pretty much breaks gmail, and I would suggest any apps that use the Google WebToolkit will be broken too.

Comment 12

[Brian Ryner (not reading)]

Reassigning my bugs, since I'm not actually working on them.