Bug 11862
| Summary: | WebKit incorrectly caching pages | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Kenneth MacArthur <kennethmac18> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | UNCONFIRMED | ||
| Severity: | Normal | CC: | beidson |
| Priority: | P3 | ||
| Version: | 419.x | ||
| Hardware: | Mac | ||
| OS: | OS X 10.4 | ||
| URL: | http://www.tobeme.eu/ | ||
Kenneth MacArthur
The above website uses a novel (non-AJAX) technique to change the content of the page without the URL changing.
Specifically, it checks if the value of HTTP_REFERER is itself, and if it is, it displays different content from that which is displayed if HTTP_REFERER is not set or is a page on a different site. (It also uses cookies to remember if this process has taken place. Once the appropriate cookie is set, user agents will always see the content that is displayed when HTTP_REFERER is the website itself, even if the HTTP_REFERER isn't the website itself.)
Because this scenario of different content at the same URL could prove challenging for user agents to keep track of, we set an Expires time of now in the HTTP header.
This generally works fine in WebKit, except in the following scenario:
a) A user visits the site for the first time.
b) The Flash animation on the site forwards them to the existing URL (but with the HTTP_REFERER set appropriately).
c) The alternative content mentioned above is now shown, since the HTTP_REFERER value was that of the page itself.
d) The user now clicks a link (it doesn't matter if it's to another page on the site or to an external site).
e) The user then clicks their Back button.
f) Rather than seeing the previous URL in the form that it was most recently seen by the user, WebKit - from its cache - reverts to showing them this URL the way it was originally displayed.
For information, Firefox does NOT behave as above. In the situation described in point (f), it shows the user the URL in the form that they most recently saw it, rather than showing them it with its original content.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
David Kilzer (:ddkilzer)
It appears that you've tested this on a shipping version of Safari. Have you tried it on a WebKit nightly build (http://nightly.webkit.org/)? If not, please do and report the results here.
Kenneth MacArthur
Have tested with latest nightly (r18270) and behaviour is identical to that on latest shipping version of Safari.
Kenneth MacArthur
As an aside, Firefox and IE/Win don't have this problem. This is because they maintain two versions of the page in the 'back button history'.
Kenneth MacArthur
Further investigation reveals that point (b) mentioned in the original report is crucial to seeing WebKit exhibit the incorrect behaviour to which this bug report refers.
In other words, if an ordinary HTML link refers the user agent to the current URL, then the second version of this URL is - correctly - what is stored in WebKit's 'back button history', so that if the user agent visits a second URL and the user then clicks the back button, they again see the second version of the first URL.
On the other hand, if a Flash animation refers the user agent to the current URL, the first version of this URL is what is stored in WebKit's back button history, so that when the user visits a second URL and then clicks Back, they see the first version of the first URL again.
This suggests that there is some flaw in WebKit's handling of URL commands passed to it by plug-ins. If nothing else, the way WebKit handles a URL load request passed from a plug-in is materially different from the way it handles a URL load request passed from WebKit itself.