Karen Rudnitski [:kar] Reporter
	Description • 12 years ago

Fx 18 Beta
Samsung Galaxy Nexus
Android 4.2.1

Settings -> clear private data / all boxes are check marked and after three tries, data is not cleared (history, top sites have all remained)

	Aaron Train [:aaronmt]
	Comment 1 • 12 years ago

about:home -> bug 803571 (on 19)

re: awesome-screen; I can't reproduce (loaded 30 tabs, populated history, cleared everything) went to History Tab/Top Sites, and everything was cleared.

I/GeckoApp(12061): Got message: Sanitize:ClearHistory
I/GeckoApp(12061): Return 
I/GeckoApp(12061): Got message: Session:StatePurged
I/GeckoApp(12061): Return 

Was there anything in your log-cat of a failed sanitize attempt?

Tested above on my Note II and Nexus 7

	Brad Lassey [:blassey] (use needinfo?)
	Comment 2 • 12 years ago

need info for Karen to provide logs

	Karen Rudnitski [:kar] Reporter
	Comment 4 • 12 years ago

I am deeply annoyed.

After Aaron patiently worked with me to set up logging, I began logging (without the Gecko filter) and tried clearing private data 3 times on Fx 18. All three times, I did not get a 'pop up / private data cleared' notice, and instead when I backed out to the about:home and clicked on the awesome bar, Fx 18 beta stopped responding. I quit it (after reporting it at one point - I'll try and recover that crash report). Once I restarted it all again, I cleared the logging up to that point and added the filter - and guess what... it cleared the private data. The only difference in my steps was the difference in logging.

	Karen Rudnitski [:kar] Reporter
	Comment 5 • 12 years ago

(and lo and behold, it didn't save my crash report......)

I also tried to reproduce on 19 aurora, but the data cleared as expected.

	Brad Lassey [:blassey] (use needinfo?)
	Comment 6 • 12 years ago

(In reply to Karen Rudnitski from comment #5)
> (and lo and behold, it didn't save my crash report......)
> 
> I also tried to reproduce on 19 aurora, but the data cleared as expected.

Karen, so can you resolve this as WFM?

	bhavana bajaj [:bajaj]
	Comment 7 • 12 years ago

Not tracking for FF18,FF19 considering comment# 4 & comment# 5.Will be helpful if someone can help confirm verify this on the latest nightly as well ? Thanks !

	Karen Rudnitski [:kar] Reporter
	Comment 8 • 12 years ago

I have attempted to clear private data again, and it is no longer WFM. I have attached a new log. 

I go into settings -> clear private data and all the boxes are checked. However when I tell it to clear, I do NOT get a pop-up message saying the data has been cleared. After waiting a bit, I back out and tap onto the awesome bar to check history. The top sites screen appears (which hasn't been cleared) and when I try tapping on bookmarks or history, the browser freezes. After 'waiting' a couple of times, I have to finally close it. There is something not right happening here....

Beta 18.0.

(Once I restart it, it works again - something wonky around clearing private data is causing this to crash? ...)

	Rand Dow [:randix]
	Comment 10 • 12 years ago

I have re-tested with results:

On Samsung Nexus GT-19250, Android.

Chome, works as expected.

Firefox 17
I go to an URL, then go there again (Wireshark running): Get "not modified", page coming from cache.
Settings->Clear private data->all boxes checked->Clear data: "Private data cleared" box pops up, goes away. I tap Settings to go back, and get no response. Only way out is to tap the Home icon. Return to Firefox, enter same URL, result: the cache is not cleared (Wireshark trace).
Result: FF 17 on Android is not clearing cache, and I cannot get back from Settings.

Nightly: 20.0a1 2013-01-02
Essentially the same a FF17, except return from Settings works now.
Thus: enter an URL with wireshark running, get only "not modified", page is coming from cache.
Settings->Clear private data->all boxes checked->Clear data: "Private data cleared" box pops up, goes away. Settings tapped, works, return to main screen.
Enter same URL, (traced with wireshark) only getting "not modified", page is coming from cache.

Conclusion: Clear private data is not working in current Nightly.

	Brad Lassey [:blassey] (use needinfo?)
	Comment 11 • 12 years ago

(In reply to Rand Dow [:randix] from comment #10)
> I have re-tested with results:
> 
> On Samsung Nexus GT-19250, Android.
> 
> Chome, works as expected.
> 
> Firefox 17
> I go to an URL, then go there again (Wireshark running): Get "not modified",
> page coming from cache.
> Settings->Clear private data->all boxes checked->Clear data: "Private data
> cleared" box pops up, goes away. I tap Settings to go back, and get no
> response. Only way out is to tap the Home icon. Return to Firefox, enter
> same URL, result: the cache is not cleared (Wireshark trace).
> Result: FF 17 on Android is not clearing cache, and I cannot get back from
> Settings.
> 
> Nightly: 20.0a1 2013-01-02
> Essentially the same a FF17, except return from Settings works now.
> Thus: enter an URL with wireshark running, get only "not modified", page is
> coming from cache.
> Settings->Clear private data->all boxes checked->Clear data: "Private data
> cleared" box pops up, goes away. Settings tapped, works, return to main
> screen.
> Enter same URL, (traced with wireshark) only getting "not modified", page is
> coming from cache.
> 
> Conclusion: Clear private data is not working in current Nightly.

Rand, perhaps the bug summary is overly vague but that definitely sounds like a different bug that what Karen reported. Can you please file a new bug with your findings?

	Brad Lassey [:blassey] (use needinfo?)
	Comment 12 • 12 years ago

Brian once this is fixed we'll need some tests to make sure we don't regress from here.

	Alex Keybl [:akeybl]
	Comment 13 • 12 years ago

This appears to be a longstanding issue, and not specific to any upcoming Firefox version. We'll accept a low risk uplift if/when found.

	Karen Rudnitski [:kar] Reporter
	Comment 14 • 12 years ago

To be fair, I don't think we really know how widespread or long-standing it is, so waiting on QA to help provide further insight on this in order to help make a more informed priority call on this item.

	Aaron Train [:aaronmt]
	Comment 15 • 12 years ago

Still haven't any luck reproducing here; tracking bug 826385 in regard to clearing cache which does not work (Rand's issue above). I thought I was hitting the 'download' history not clearing, but this is an issue (there's a filed bug somewhere) where the manager is not listening to changes; re-opening the download manager shows a wiped download history.

So, still no leads on this one.

	Ioana Chiorean
	Comment 16 • 12 years ago

TCs:
https://moztrap.mozilla.org/manage/case/6066/\
https://moztrap.mozilla.org/manage/case/6196/

	enrico
	Comment 17 • 11 years ago

i can confirm, same problem on Google Nexus 4. If i clear private data, history and PASSWORDS remain. For me, it's a CRITICAL bug!

	u421692
	Comment 18 • 11 years ago

I was unable to reproduce this issue on Firefox Nightly 25.0a1 (2013-07-20), on HTC Desire HD (Android 2.3.5). Can you please add more information about the build you reproduced this issue, the steps to reproduce and the device you are using? Thanks!

	u421692
	Comment 19 • 11 years ago

I tested also on Nexus 4 (Android 4.2.2). Still unable to reproduce this issue.

	enrico
	Comment 20 • 11 years ago

I'm using android 4.2.2 and firefox 22. (i tryed also to reinstall and clean the program data before reproduce this bug)
1- login on facebook
2- clear private data 
3- close firefox
4- open firefox on facebook and i'm logged yet 


In any case i'm unable to delete history.. i have do it manually..

	enrico
	Comment 21 • 11 years ago

i tryed again with this site and the password was deleted.. sometimes i can clear passwords but is not always working. history still present.

	u421692
	Comment 22 • 11 years ago

The issue is reproducing every time you try to clear private data. It reproduces when "Don't keep activities" is enabled. Could you please check in Android Settings-> Developer Options -> "Don't keep activities" if is enabled, and then try to reproduce this issue?

	enrico
	Comment 24 • 11 years ago

i disabled it without results.. same issue

	Aaron Train [:aaronmt]
	Comment 25 • 11 years ago

(In reply to enrico from comment #24)
> i disabled it without results.. same issue

Did you restart the browser after disabling it?

	u421692
	Comment 26 • 11 years ago

Can you please try this with a clean profile("Clear data" for Firefox from Settings -> App info), and see if the issue is still reproducing? Also, if you manage to reproduce it again, it will be really helpful if you can get the logs. You can save the logs with "aLogcat" https://wiki.mozilla.org/Mobile/Fennec/Android#Using_aLogCat, if you are not familiar with adb tool.

	enrico
	Comment 27 • 11 years ago

i cleaned the profile. History isn't empty whit "clear private data". i hope this log is enough!

	enrico
	Comment 28 • 11 years ago

(In reply to Aaron Train [:aaronmt] from comment #25)
> (In reply to enrico from comment #24)
> > i disabled it without results.. same issue
> 
> Did you restart the browser after disabling it?

yes. i think i tryed everything..
 
also my Nexus 10 (4.2.2) has the same problem..

	Aaron Train [:aaronmt]
	Comment 29 • 11 years ago

(In reply to enrico from comment #20)
> I'm using android 4.2.2 and firefox 22. (i tryed also to reinstall and clean
> the program data before reproduce this bug)
> 1- login on facebook
> 2- clear private data 
> 3- close firefox
> 4- open firefox on facebook and i'm logged yet 
> 
> 
> In any case i'm unable to delete history.. i have do it manually..

I just tried this on my Nexus 4 (Android 4.2.2) as well and I can't reproduce. 

I created a fresh profile, logged into Facebook. I headed over to Settings, cleared all private data and then swiped Nightly off my recent list to close it. I relaunched Nightly and did not have Facebook in my history at all. Visiting Facebook, I was signed out. There must be some other interfering factor here on your device.

Would you be able to record a video showing the behaviour?

	Aaron Train [:aaronmt]
	Comment 31 • 11 years ago

Thanks for the video. So far the only way I can reproduce this is enabling the developer option 'Don't keep activities'. Disabling that is recommended. No luck else-wise. Do you have any task killers on your phone? If so, did you try stopping or removing them?

	enrico
	Comment 32 • 11 years ago

Disabling that everything seems normal! (...lot of bad words...) never had issues with other programs.. good job, thanks! :)

	Aaron Train [:aaronmt]
	Comment 33 • 11 years ago

Glad to hear. Yes, that option is quite problematic and not meant to be tampered with.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 34 • 11 years ago

This is still a bug. That option just makes the scenario happen reliably but if it happens there it can still happen with "Don't keep activities" unchecked.

	u421692
	Comment 35 • 11 years ago

(In reply to enrico from comment #32)
> Disabling that everything seems normal! (...lot of bad words...) never had
> issues with other programs.. good job, thanks! :)


Pop Mihai from comment #22)
> The issue is reproducing every time you try to clear private data. It
> reproduces when "Don't keep activities" is enabled. Could you please check
> in Android Settings-> Developer Options -> "Don't keep activities" if is
> enabled, and then try to reproduce this issue?

(In reply to enrico from comment #24)
> i disabled it without results.. same issue

Did you do something in between, or did I miss something here? Thanks!

	enrico
	Comment 36 • 11 years ago

you missed that i am studying too much engineering! i am tired and in my language antitrack option in firefox has the same words of don't keep activities.. time to go on holiday for me.. comment #24 is wrong, sorry!

	u421692
	Comment 37 • 11 years ago

After comment 32 and comment 36, you can see that this issue only reproduces when "Don't keep activities" option is enabled. Changing the title of the bug.

	Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland
	Comment 40 • 11 years ago

We see this about once a week in sumo forums

e.g. in firefox 27:

https://support.mozilla.org/en-US/questions/988386

1. Would it be possible for Firefox to work around this "Don't keep activities" bug? I don't think this is a Firefox bug. I think it's an Android bug so it may be impossible for Firefox to work around this bug.

2. I think there is a bug here perhaps in Android or in Samsung's Android's customizations (the above forum question is Samsung Galaxy Mega. Firefox v27.0 ) where "Don't keep activities" is checked. The folks on SUMO are users not developers so why are so many reporting it every week?

	Aaron Train [:aaronmt]
	Comment 41 • 11 years ago

This is entirely still reproducible.

LG Nexus 5 (Android 4.4.2)

* Build up history
* Enable 'Don't Keep Activities'
* Clear private data in the browser

-- See history still present

Tested this on all currently shipping channels.

	Wesley Johnston (:wesj)
	Comment 42 • 10 years ago

I saw this yesterday. Didn't realize we had a really old bug on it. Problem is that we listen for these messages in GeckoApp. Will take.

	Nick Alexander :nalexander [he/him] (PTO until Montreallhands August 21, 2023)
	Comment 43 • 9 years ago

This is disturbing.  We clearly aren't doing the right thing when we register some events in GeckoApp#onCreate [1] and unregister in GeckoApp#onDestroy [2], but I don't quite know how this is supposed to be handled.  Should these be longer lived, which might mean moving them to ... GeckoAppShell?  GAS doesn't handle very many messages.  A helper, like DownloadsIntegration?  This needs access to a profile, so there are some timing issues at play.

wesj, rnewman: thoughts?

[1] https://hg.mozilla.org/mozilla-central/file/8d8df22fe72d/mobile/android/base/BrowserApp.java#l786
[2] https://hg.mozilla.org/mozilla-central/file/8d8df22fe72d/mobile/android/base/BrowserApp.java#l1350

	Richard Newman [:rnewman]
	Comment 44 • 9 years ago

Large chunks of Fennec -- apparently this is one -- assume that GeckoApp/BrowserApp is always alive and a great place to put persistent listeners and data structures. They shouldn't do so, because of course that's not the case when Settings is open, when we're backgrounded, etc.

We have a set of components that are initialized in GeckoAppShell, but the problem with doing that is that GeckoView consumers will need to manage things, and those components have very long lifecycles, which isn't always appropriate.

The upshot is that we need to consider what to do on a case-by-case basis.

In this particular case, the ClearHistory listeners should be in GeckoPreferences(Fragment?), not in BrowserApp, because that's where the user clears their history. If we support triggers elsewhere (e.g., clear-on-shutdown), then we might need to do more.

	Wesley Johnston (:wesj)
	Comment 45 • 9 years ago

Hmm... I wonder if we can register these particular ones in LocalBrowserDB (which is created for each profile?). Its possible we've got multiple LocalBrowserDB's around (we do create them in multiple places), but I assume they'll just clear something twice if we do which... isn't the end of the world (the second clear should be really fast :) )

	Richard Newman [:rnewman]
	Comment 46 • 9 years ago

(In reply to Wesley Johnston (:wesj) from comment #45)
> Hmm... I wonder if we can register these particular ones in LocalBrowserDB
> (which is created for each profile?). Its possible we've got multiple
> LocalBrowserDB's around (we do create them in multiple places), but I assume
> they'll just clear something twice if we do which... isn't the end of the
> world (the second clear should be really fast :) )

Interesting idea… I guess on that note, GeckoProfile itself (which is a singleton and intrinsically profile-specific) is also a good place for profile-specific listeners like this to live.

A strong caveat, though: decoupling from the app itself means that there needs to be some way for the DB or the profile to figure out if it's the one to wipe. It'd be sad to have some side effect allow for a guest or secondary profile to wipe the main profile by accident.

	Wesley Johnston (:wesj)
	Comment 47 • 9 years ago

No one is currently working on this, but I think its probably mentorable.

	Nick Alexander :nalexander [he/him] (PTO until Montreallhands August 21, 2023)
	Comment 48 • 9 years ago

(In reply to Wesley Johnston (:wesj) from comment #47)
> No one is currently working on this, but I think its probably mentorable.

This is a hairy bug.  If I understand the problem correctly, we'd need to find a way to start Gecko in order for clean-up to happen correctly.  That's very hard.

	Alex Red
	Comment 49 • 9 years ago

It rarely cleans the history, but most of the time it does nothing.
I used to use an Addon to do this before it was implemented into FF, but that doesnt work anymore.

	Nick Alexander :nalexander [he/him] (PTO until Montreallhands August 21, 2023)
	Comment 50 • 9 years ago

(In reply to Alex Red from comment #49)
> It rarely cleans the history, but most of the time it does nothing.
> I used to use an Addon to do this before it was implemented into FF, but
> that doesnt work anymore.

This is a very tricky problem: see https://bugzilla.mozilla.org/show_bug.cgi?id=818994#c44 and https://bugzilla.mozilla.org/show_bug.cgi?id=818994#c48.  An add-on can do the cleaning, but can't really do better than Fennec itself when it comes to the Gecko shut down cycle.

Sadly, this is the result of significant technical debt around the Gecko lifecycle and the Android Activity lifecycle that we are paying down at the monthly minimum payment rate.  It's going to be a long while.  For now, don't check "Don't keep activities".

	Jan Henning [:JanH]
	Comment 52 • 6 years ago

(In reply to Nick Alexander :nalexander [he/him] from comment #48)
> (In reply to Wesley Johnston (:wesj) from comment #47)
> > No one is currently working on this, but I think its probably mentorable.
> 
> This is a hairy bug.  If I understand the problem correctly, we'd need to
> find a way to start Gecko in order for clean-up to happen correctly.  That's
> very hard.

I don't think we'd actually have to start Gecko - "Don't keep activities" means that the GeckoApp/BrowserApp *activity* is destroyed when we enter our settings, but the app and its associated process remain alive, and consequentially so does Gecko.

Comment 45/comment 46 indicate the way forward - to give yet another example, "Sanitize:OpenTabs" probably ought to be moved into the Tabs instance itself.

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 54 • 6 years ago

Is this something you may also work on eventually for Geckoview? Or is it only affecting Fennec?

	Nick Alexander :nalexander [he/him] (PTO until Montreallhands August 21, 2023)
	Comment 55 • 6 years ago

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #54)
> Is this something you may also work on eventually for Geckoview? Or is it
> only affecting Fennec?

Me?  Not likely.  GeckoView has paid down a large amount of this debt and therefore it's very likely (probable, even!) that a browser built around GV can and will do the right thing about clearing private data in accordance with its lifecycle.  So I think this is WONTFIX for Fennec, and the GV team will take up GV features as and when they're needed for similar features in support of future work.