While I''ve seen various discussions of how Ajax breaks/can break the back button, there is one case in particular that I''m struggling with that I can''t find specific discussion about. For an easy to duplicate example, create a new Backpack page. Save it, and then add a list item with an external link in it. After you''ve added it, click the external link, wait for the external page to load, and then hit the back button. If you''re using Safari, the page will look exactly the same as when you left it, which is nice for the 0.00001% of the world that uses Safari. If you''re using IE, the page will have your list item, but it will not have the add text field still available (it appears that IE re-requests the page when you hit the back button). If you''re using Firefox, it appears that your link never existed unless you hit refresh. This problem is exacerbated for my site, since the page that the user is linking out from is not persistent in any way, so there''s nothing for IE to refresh, meaning that it''s broken in both Firefox and IE. Neither I nor my customer like the idea of opening a new window for the external link, but I''m having a hard time thinking of anything else (besides not using AJAX to update the page at all, which is even less desirable). I could perhaps link to the external site through an intermediary page that does a GET and then use some kind of JS voodoo to forward them on to the external page, but I''m afraid that''s just going to cause its own set of problems. Has anyone else run in to this problem? Does anyone have ideas for solving it? Any and all ideas welcome. Thanks, -- Nathaniel <:((><
On 6/7/05, Nathaniel Talbott <ntalbott-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> While I''ve seen various discussions of how Ajax breaks/can break the > back button, there is one case in particular that I''m struggling with > that I can''t find specific discussion about. > > For an easy to duplicate example, create a new Backpack page. Save it, > and then add a list item with an external link in it. After you''ve > added it, click the external link, wait for the external page to load, > and then hit the back button. If you''re using Safari, the page will > look exactly the same as when you left it, which is nice for the > 0.00001% of the world that uses Safari. If you''re using IE, the page > will have your list item, but it will not have the add text field > still available (it appears that IE re-requests the page when you hit > the back button). If you''re using Firefox, it appears that your link > never existed unless you hit refresh. > > This problem is exacerbated for my site, since the page that the user > is linking out from is not persistent in any way, so there''s nothing > for IE to refresh,Why is that? It seems that unless the browser can GET a resource, you really are going to have a hell of a time making the back button work. I think the easiest solution would be to persist the pages> meaning that it''s broken in both Firefox and IE. > > Neither I nor my customer like the idea of opening a new window for > the external link, but I''m having a hard time thinking of anything > else (besides not using AJAX to update the page at all, which is even > less desirable). I could perhaps link to the external site through an > intermediary page that does a GET and then use some kind of JS voodoo > to forward them on to the external page, but I''m afraid that''s just > going to cause its own set of problems. > > Has anyone else run in to this problem? Does anyone have ideas for > solving it? Any and all ideas welcome. > > Thanks, > > > -- > Nathaniel > > <:((>< > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
On 6/6/05, Michael Koziarski <koziarski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 6/7/05, Nathaniel Talbott <ntalbott-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > This problem is exacerbated for my site, since the page that the user > > is linking out from is not persistent in any way, so there''s nothing > > for IE to refresh, > > Why is that? It seems that unless the browser can GET a resource, > you really are going to have a hell of a time making the back button > work. I think the easiest solution would be to persist the pagesOK, so I can do that (fairly easily, actually), but it still doesn''t solve the problem for either Firefox or IE, because the page will still be built dynamically, and any persistence of the page will be built in to a GET url which will have to be made as a separate request. A bit more detail: basically, users always start at the same url. Say: http://www.app.com/app The app basically takes some inputs, gathers some data, and builds a one-time, transient page for them, using AJAX, at that same url. One of the parts of the page is a link to an external resource about their input. If they click through directly to that url, and hit the back button, they''ll end up with nothing on the page in IE and Firefox, which is exactly the correct thing for the initial GET of the initial URL. Now, I can easily provide an interface, such as: http://www.app.com/app/some-data/some-more-data that will, on a fresh GET, display the right stuff. However, I don''t want this URL to be loaded unless they actually click out to an external site. Then, as long as they don''t change the inputs, I''d want to keep that page as the current url so they wouldn''t have to do a fresh GET each time they hit the back button (at least in Firefox). Does that make sense? If I could edit the URL (so that it actually affected the history) using JS, that would work, but I haven''t seen any way to do that. Can that be done, or does anyone knows of any other ways of doing this cleanly, and have it still work with the three biggies (IE, Firefox, and Safari)? Thanks, -- Nathaniel <:((><
>> This problem is exacerbated for my site, since the page that the user >> is linking out from is not persistent in any way, so there''s nothing >> for IE to refresh, >> > > Why is that? It seems that unless the browser can GET a resource, > you really are going to have a hell of a time making the back button > work. I think the easiest solution would be to persist the pages.I have to agree. This really seems like the core of the problem, not the varied page-caching behaviors of the three browsers you mentioned. I think that basing your expectations on Safari''s behavior isn''t giving you a reliable picture of the situation. To be able to reliably back up to a page that''s in a known-good- state, you''re going to have to build a proper URL, I think. Do you absolutely have to use Ajax techniques here, or is that just a nice- to-have? You''re not going to like my other suggestion, I''ll bet: frames would make this work fine. Just load the external page into a frame within the "transient" URL. andrew
This is the infamous "back button problem". The Dojo toolkit has "resolved" the situation. Each AJAX request changes the URL, and the Dojo framework catches browser back clicks, and does magic to notify the Ajax code that back was pressed. http://dojotoolkit.org/ Bye ! François Nathaniel Talbott said the following on 2005-06-06 20:22:> On 6/6/05, Michael Koziarski <koziarski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >>On 6/7/05, Nathaniel Talbott <ntalbott-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >> >>>This problem is exacerbated for my site, since the page that the user >>>is linking out from is not persistent in any way, so there''s nothing >>>for IE to refresh, >> >>Why is that? It seems that unless the browser can GET a resource, >>you really are going to have a hell of a time making the back button >>work. I think the easiest solution would be to persist the pages > > > OK, so I can do that (fairly easily, actually), but it still doesn''t > solve the problem for either Firefox or IE, because the page will > still be built dynamically, and any persistence of the page will be > built in to a GET url which will have to be made as a separate > request. > > A bit more detail: basically, users always start at the same url. Say: > > http://www.app.com/app > > The app basically takes some inputs, gathers some data, and builds a > one-time, transient page for them, using AJAX, at that same url. One > of the parts of the page is a link to an external resource about their > input. If they click through directly to that url, and hit the back > button, they''ll end up with nothing on the page in IE and Firefox, > which is exactly the correct thing for the initial GET of the initial > URL. > > Now, I can easily provide an interface, such as: > > http://www.app.com/app/some-data/some-more-data > > that will, on a fresh GET, display the right stuff. However, I don''t > want this URL to be loaded unless they actually click out to an > external site. Then, as long as they don''t change the inputs, I''d want > to keep that page as the current url so they wouldn''t have to do a > fresh GET each time they hit the back button (at least in Firefox). > > Does that make sense? If I could edit the URL (so that it actually > affected the history) using JS, that would work, but I haven''t seen > any way to do that. Can that be done, or does anyone knows of any > other ways of doing this cleanly, and have it still work with the > three biggies (IE, Firefox, and Safari)? > > Thanks, > >-- François Beausoleil Solutions Technologiques Internationales Téléphone: (819) 566-5997 Courriel: francois-rcT27nE7VLDiB9QmIjCX8w@public.gmane.org