[Webkit-unassigned] [Bug 7990] New: Back, Forward buttons cause network access, data loss

[bugzilla-daemon at opendarwin.org]

http://bugzilla.opendarwin.org/show_bug.cgi?id=7990

           Summary: Back, Forward buttons cause network access, data loss
           Product: WebKit
           Version: 417.x
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: NEW
          Severity: normal
          Priority: P1
         Component: WebKit API
        AssignedTo: webkit-unassigned at opendarwin.org
        ReportedBy: contact at nickshanks.com


Sometimes pressing back and forward initiates network activity. This can result
in data loss especially where forms are concerned, or incorrect results for
XMLHTTPRequest‐based sites.

For example:

First I click a link, which follows a redirect to a page with a form.
I type some large quantity of text into a field.
The page reloads itself and displays a "connection timed out" message. I curse
Netscape for inventing Javascript.
I want to go back to the page so I can copy my text into a real text editor
which won't screw me around.
However, pressing back goes to the redirect, which brings me to the page I was
on, but without the data I had typed.
Several cute furry animals die.

Alternatively:

A web app with a static URI varies it's display according to user input,
javascript, XMLHTTPRequests and such like.
After using for a while and now in a custom state, I click a link taking me to
a new page.
Clicking back however does not restore the previous page to the state it was in
when I left it. Instead a new GET request is issued to the static URI and all
previous status is lost.
It would appear that some period of time must elapse before clicking back will
cause a GET request rather than pulling the page from the cache.

Counter‐example:
If instead of opening new links in the same tab, I open each in a new tab, then
going back and forth between the tabs DOES preserve the state of each page.
There should be no difference in behaviour between switching tabs and pressing
back and forward. Both should return me to the requested page exactly as I left
it.


I suggest resolving this by entirely freezing pages in their current state
before putting them on the history stack. Network access should NEVER occur on
pressing back or forward, not only is it incorrect, prone to data loss and much
slower than reading from cache, but can in cases such as outlined result in
entirely the wrong page being displayed.

Furthermore, even when reading apparently from the cache, pressing back/forward
in any WebKit‐based app is much slower than switching tabs in the app (e.g.
Safari, NetNewsWire). It seems as if the page cache is disorganised or
incomplete, and images & css need to be reloaded separately and the whole page
re-rendered, clearly this is negative behaviour.


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.