[webkit-dev] CSS cache and unfired events.

Frédéric Lefebvre Frederic.Lefebvre at 4d.com
Thu Feb 10 08:51:33 PST 2011

Hello again.

Regarding the events firing, and after some tests, it appears that, using the TryItYourself of the page

I followed an advised simple routine:
-Open TryitYourself page in a new thumb
-Edit and click me button always works but
-Close the newly created thumb happens to...

catches unload event on:
 Safari5.0.3 & Firefox3.6.13 (MAC SNOW LEOPARD)
 Firefox3.6.13 (WINDOWS 7)

unload evt IS NOT CATCHED on:
 Opera11.01 & Chromium11.0.666.0 (MAC SNOW LEOPARD)
 Safari5.0.3, Chromium9.0.584.0 & Opera11.01 (WINDOWS 7)

(Safari doesn't react the same whether it runs on OSX or 7)
The event seems to be lost or not sent on page closure on most of these browsers (webkit ones too) or, at least, not catchable by any process after sending (maybe some precedence issue in the page's closing steps).


De : webkit-dev-bounces at lists.webkit.org [mailto:webkit-dev-bounces at lists.webkit.org] De la part de Frédéric Lefebvre
Envoyé : mercredi 9 février 2011 18:34
À : webkit-dev at lists.webkit.org
Objet : [webkit-dev] CSS cache and unfired events.


I'm currently working on a Webkit interface using an HTMLview filled with YUIlayout panels including an HTMLdocument to edit within.

Once a change has been made to the HTMLdocument, we save the whole stuff in both CSS and HTML physical files.

When reopening the interface, the HTML file is physicaly accessed but not the CSS and image files included in the HTML.  The cache prevails.
Primary effect is that, though the HTML contents seem to be correctly brought back (from cache indeed), the styles are not up to date.
Secondary effect is, on reload call, that the styles are updated but the HTML contents disappear.

I would like to assure the cache is correctly flushed on page closure, but it appears that neither unload nor pagehide event is fired upon Page::~Page run in the Webkit core.  The page destructor closes backforward list then calls the PageCache::remove without finding any cached page for the HistoryItem passed and that's it.

How could I ensure, from higher layers, that the CSS cache and HTML of the edited HTMLdocument are surely flushed from cache and not retrieved on subsequent calls without adding ?val=random tricks in the URLs of DOM elements.

Obviously no-cache, must-revalidate and all these obsolescence tricks are of no interest here since, even if the document has to be no-cache accessed on loading, we should be able to edit an ultimately cachable document.

Any advice or clue welcome.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110210/ecdcc0d9/attachment.html>

More information about the webkit-dev mailing list