1342820 - Browser Back Button is not exit after clearing Clear Private Data

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[lgbrowser5]

Attachment: back.avi

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; NetHelper70; CNS_UA; AD_LOGON=4C47452E4E4554; rv:11.0) like Gecko

Steps to reproduce:

Steps to Reproduce:
1. Visit more than one website.
2. From the Tools Menu select the Clear Private Data option.  
    Clear Private Data. 





Actual results:

Actual Results:  
The Back Button should be disabled after clearing Browsing History. 



Expected results:

Expected Results:  
The Back Button is exit browser.

Comment 1

[Sorina Florean [:sflorean]]

Hello and thank you for reporting this!

The issue that you describe is fixed on Nightly 54.0a1 and Aurora 52.0a2. In Settings -> Clear private data you have a new option "Open tabs". If you check it, the tabs open will be cleared too and back button will take you to the about:home page.

Please install latest Nightly [1] and try to see if it fix the issue for you.

[1] archive.mozilla.org/pub/mobile/nightly/2017/

Comment 2

[Jan Henning [:JanH]]

@sorina: This is a different issue - when you clear the browsing history on desktop, the session history of all open tabs is purged as well. In principle the same happens on Android, except our implementation is somewhat incomplete...

After a quick perusal it looks like there are two components to this bug:

1. The session history of any live tabs in indeed purged of everything except the currently open page, but the session store doesn't update its cached tab data. For live tabs I think that bug 1337940 might work around this, as we'll presumably catch the history purge notification for each tab and collect the session history again, but zombified tabs will still require special handling, since as far the rest of Gecko is concerned those are simply about:blank tabs with no other history, so a) we can't just recollect the tab data because there's nothing to collect from except our own session store data and b) if zombified tabs indeed only have a single session history entry for about:blank we might not even receive a purge notification for them if there is no other history to purge there anyway.

So unless somebody has a better idea, maybe we should just do an |if (aTopic == "browser:purge-session-history") {...}| special-casing here (https://dxr.mozilla.org/mozilla-central/rev/7ef1e9abd296a8edc39b7efc8d637767ba2f77ed/mobile/android/components/SessionStore.js#237), iterate through all tabs held in BrowserApp and splice away everything but the last history entry (and accordingly reset the index to 0) in each tab's __SS_data.

2. Currently we only update the forward/back button state in the UI from onLocationChange (https://dxr.mozilla.org/mozilla-central/rev/7ef1e9abd296a8edc39b7efc8d637767ba2f77ed/mobile/android/chrome/content/browser.js#4347). In that case a solution could be to have Java-side "Tabs" listen for "Sanitize:ClearHistory" and reset the button state on all tabs.

Comment 3

[Sorina Florean [:sflorean]]

Thanks for clarification. I will delete the ni.

Comment 4

[Mike Kaply [:mkaply]]

> The session history of any live tabs in indeed purged of everything except the currently open page, but the session store doesn't update its cached tab data. 

I'm not seeing this on nightly. When I clear private data, I lose the current page I'm on as well. Can someone else verify?

Comment 5

[Jan Henning [:JanH]]

The session history of the current tab as held by Gecko (and displayed by long pressing the back button) is indeed purged, but as long as you don't do anything that triggers a session store tab data collection (i.e. navigate to some other page), all the session history reappears if you kill Firefox and then restart it.
In fact, even closing the tab and then restoring it (either via the snackbar or from the history panel) is enough to bring back its session history.

Comment 6

[Mike Kaply [:mkaply]]

> In fact, even closing the tab and then restoring it (either via the snackbar or from the history panel) is enough to bring back its session history.

That seems like a pretty serious privacy issue (and probably a separate bug).

I think this is covering specifically that the back button doesn't work in this case.

Comment 7

[Jan Henning [:JanH]]

It's partly mitigated because it only happens when you don't touch the tab afterwards.
But you're right, it's related to history clearing, but not the actual cause of this bug - feel free to split it off and CC me.

Comment 8

[Jan Henning [:JanH]]

Attachment: Bug 1342820 - Reset navigation button state when clearing history.

Clearing history purges a tab's session history as well. Normally, we only update the navigation button state in the UI for a location change, so now we need to start listening for the appropriate message as well.

BrowserApp has already registered a background thread listener for "Sanitize:ClearHistory" - since this can be called during shutdown as well and their listener is more important (clearing the history DB), we defer to them and redispatch to the UI thread ourselves, so BrowserApp doesn't have to do this during shutdown.

Review commit: https://reviewboard.mozilla.org/r/116354/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/116354/

Comment 9

[Mike Kaply [:mkaply]]

[Tracking Requested - why for this release]: Reported by partner. Would be nice to have for them.

Comment 10

[Andrzej Hunt :ahunt]

Comment on attachment 8842570 [details]
Bug 1342820 - Reset navigation button state when clearing history.

https://reviewboard.mozilla.org/r/116354/#review118064

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/65317946fe00
Reset navigation button state when clearing history. r=ahunt

Comment 12

[Jan Henning [:JanH]]

Comment on attachment 8842570 [details]
Bug 1342820 - Reset navigation button state when clearing history.

Approval Request Comment
[Feature/Bug causing the regression]: Private data clearing
[User impact if declined]: Navigation button state won't be updated after clearing history
[Is this code covered by automated tests?]: No.
[Has the fix been verified in Nightly?]: No.
[Needs manual test from QE? If yes, steps to reproduce]: 
1. Open a tab and navigate to accumulate some session history.
2. Go back one step, so that both back and forward buttons are enabled.
3. Clear History.
4. Check that
a) The navigation buttons are both deactivated
b) Going back (system back button) now exits Firefox.
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: No.
[Why is the change risky/not risky?]: Navigation button state is regularly updated on location change - this just triggers an additional update to reset the buttons when the history clearing notification is received.
[String changes made/needed]: none

This might possibly need a dedicated patch for uplifting, as bug 1269210 touched a neighbouring line in Tab.java.

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/65317946fe00

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 8842570 [details]
Bug 1342820 - Reset navigation button state when clearing history.

This is very last minute, but we can give it a try for aurora 53.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1c85043498f0

Comment 16

[Sorina Florean [:sflorean]]

Verified as fixed following the steps from comment #12.
- The back and forward arrow are grey out after clearing history.
- Tapping on back android button puts the Firefox in background.
Device: Samsung Galaxy Note 4 (Android 5.0.1).
Build: 53.0b1 and 54.0a2.