Last Comment Bug 665336 - SeaMonkey clears all LSOs (Flash Cookies) when clearing cache only
: SeaMonkey clears all LSOs (Flash Cookies) when clearing cache only
Status: RESOLVED FIXED
: dataloss
Product: SeaMonkey
Classification: Client Software
Component: Passwords & Permissions (show other bugs)
: Trunk
: x86 Windows XP
: -- major (vote)
: seamonkey2.4
Assigned To: Jens Hatlak (:InvisibleSmiley)
:
Mentors:
Depends on: 632746
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-19 00:39 PDT by H. Hofer
Modified: 2011-08-03 22:53 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
fixed
fixed


Attachments
stop calling clearSiteData for cache [Checkin: comment 9] (840 bytes, patch)
2011-06-20 14:28 PDT, Jens Hatlak (:InvisibleSmiley)
neil: review+
kairo: approval‑comm‑aurora+
kairo: approval‑comm‑beta+
Details | Diff | Splinter Review

Description H. Hofer 2011-06-19 00:39:43 PDT
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110608 Firefox/4.0.1 SeaMonkey/2.1

When clearing the cache only in 'Clear Private Data...', all LSOs are removed, too.

Reproducible: Always

Steps to Reproduce:
1. Visit a site that stores LSOs (e.g. http://youtube.com)
2. Use a LSO-viewer to verify LSOs exist (e.g. http://www.nirsoft.net/utils/flash_cookies_view.html)
3. Use 'Clear Private Data...' to clear *only* the cache
4. Use the LSO-viewer again.

Actual Results:  
All LSOs have been deleted.

Expected Results:  
No LSOs should have been cleared. Only if 'Cookies' would have been selected in 'Clear Private Data...', they should have been deleted.

Seems like the call to
  Sanitizer._clearPluginData("FLAG_CLEAR_CACHE");
in Sanitizer.jsm doesn't really respect the flags...
Comment 1 Philip Chee 2011-06-19 11:10:28 PDT
The backend code eventually just sends the clear cache flag to the flash plugin. So I guess the flashplayer code itself considers LSOs cache data. Not too surprising since that was the original intention of LSOs (which can store any data) and websites then started making use of these to store cookie like data.
Comment 2 H. Hofer 2011-06-20 06:09:54 PDT
But i still think, SeaMonkey doesn't behave as expected (FireFox does).

As annoying as LSOs are, I usually want to keep them. And when doing
web development, cache clearing occurs quite frequently.
Comment 3 Philip Chee 2011-06-20 08:19:14 PDT
Yeah sounds reasonable => NEW.
Comment 4 Jens Hatlak (:InvisibleSmiley) 2011-06-20 14:28:42 PDT
Created attachment 540591 [details] [diff] [review]
stop calling clearSiteData for cache [Checkin: comment 9]

OK, so we gambled (made assumptions about nsIPluginHost flags) and lost. When we added this code, no version of Flash with support for this had been available yet, so we couldn't test it. Firefox never did what we did, so this brings us back in line with what they implemented.

This should probably land on aurora (and beta, if there's still time), too.
Comment 5 Jens Hatlak (:InvisibleSmiley) 2011-06-20 14:30:44 PDT
[leftover empty line removed locally]
Comment 6 neil@parkwaycc.co.uk 2011-06-22 04:24:40 PDT
Comment on attachment 540591 [details] [diff] [review]
stop calling clearSiteData for cache [Checkin: comment 9]

Bah, so Firefox creates a flag, doesn't use it, then Flash doesn't implement it correctly, and we lose :-(

> 
>-        Sanitizer._clearPluginData("FLAG_CLEAR_CACHE");
Nit: the blank line can go too.
Comment 7 Jens Hatlak (:InvisibleSmiley) 2011-06-22 05:21:16 PDT
Comment on attachment 540591 [details] [diff] [review]
stop calling clearSiteData for cache [Checkin: comment 9]

Unless we do a respin this is too late for 2.2. 2.3 it should be, then.
Comment 8 Robert Kaiser 2011-06-22 05:29:10 PDT
Comment on attachment 540591 [details] [diff] [review]
stop calling clearSiteData for cache [Checkin: comment 9]

We will surely do another build for final 2.2 (if only to pick up the rest of the locales), and this seems safe and important enough to make that.

Note You need to log in before you can comment on or make changes to this bug.