298377 - Fastback breaks dojo.io.bind's back-button interception when subframe caching enabled

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect)

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

With 1.0.4, the back-button interception in the test case that comes with the
dojo.io.bind package works, but with DP1.1a1 it does not.  Just untar the
package linked from this bug's URL (currently
http://dojotoolkit.org/dojo_browserio_20050505.tar.gz) and notice that you don't
get the "we intercepted the back button" alert on DP1.1a1.

Comment 1

[chris hofmann]

byner/sicking,   we should see if we can get this working quickly for next alpha
or beta

Comment 2

[Benjamin Smedberg]

Why do we want to support back-button interception? And please can we get a
minimal self-contained testcase?

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

We want to support back-button interception for the same reason that we want to
support onbeforeunload -- it lets app authors prevent inadvertent data loss
caused by user navigation.  That's also why the pushState/onBackButton stuff is
in the WA1 draft from WHATWG.

_And_ we supported it in 1.0.4, _and_ it's something you can do in pretty much EOMB.

Comment 4

[Benjamin Smedberg]

ok, blah

Comment 5

[chris hofmann]

bryner thinks this is unrelated to fastback.

shaver/bclary, can you reduce the rest case or suggest some one to do it.

Comment 6

[Bob Clary [:bc] (inactive)]

(In reply to comment #5)
looking into it now.

Comment 7

[Bob Clary [:bc] (inactive)]

I've been looking but haven't figured it out yet. If someone else can do it
before I can that would be great. I'll start again fresh after a break.

Comment 8

[Bob Clary [:bc] (inactive)]

This worked in build 2004-12-08-07 but failed in build 2004-12-09-07.

Comment 9

[Bob Clary [:bc] (inactive)]

The basic issue is that when you click back in recent builds, the page
automatically reloads which starts the process from the beginning. I don't know why.

Comment 10

[Bob Clary [:bc] (inactive)]

This works in a cvs build on winxp with the patch from bug 277224.

Comment 11

[Brian Ryner (not reading)]

This should no longer be blocking, based on the pref change in bug 304860.

Comment 12

[Mike Connor [:mconnor]]

minusing per bryner's comment 11

Comment 13

[Jesse Ruderman]

I'm confused from reading comments 10 and 11.  Does this bug still occur (when
browser.sessionhistory.cache_subframes is true)?

Comment 14

[Boris Zbarsky [:bzbarsky]]

> Does this bug still occur (when browser.sessionhistory.cache_subframes is
> true)?

Yes, but its false by default.

Comment 15

[Brian Ryner (not reading)]

Resummarizing, and taking this off my list since I'm not currently planning to do the work required to support bfcache for subframe navigation.

Comment 16

[Aiko]

This WFM now (at least the test page at the URL does), even when browser.sessionhistory.cache_subframes is true. I don't know whether a change in Dojo or Gecko fixed this.

Comment 17

[Hallvord R. M. Steen [:hallvors]]

I think I can close this as WFM per comment 16, especially given that nothing has happened here since '08