Browser Back Button is not exit after clearing Clear Private Data

VERIFIED FIXED in Firefox 53

Status

()

Firefox for Android
General
VERIFIED FIXED
a year ago
a year ago

People

(Reporter: lgbrowser5, Assigned: JanH)

Tracking

51 Branch
Firefox 54
All
Android
Points:
---

Firefox Tracking Flags

(firefox53+ verified, firefox54 verified)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

(Reporter)

Description

a year ago
Created attachment 8841382 [details]
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.
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/
Flags: needinfo?(lgbrowser5)
(Assignee)

Comment 2

a year ago
@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.
Status: UNCONFIRMED → NEW
Component: Settings and Preferences → General
Ever confirmed: true
OS: Unspecified → Android
Hardware: Unspecified → All
Thanks for clarification. I will delete the ni.
Flags: needinfo?(lgbrowser5)
> 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?
(Assignee)

Comment 5

a year ago
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.
> 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.
(Assignee)

Comment 7

a year ago
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.
(Assignee)

Updated

a year ago
Assignee: nobody → jh+bugzilla
(Assignee)

Updated

a year ago
See Also: → bug 1343603
Comment hidden (mozreview-request)
[Tracking Requested - why for this release]: Reported by partner. Would be nice to have for them.
tracking-firefox53: --- → ?

Comment 10

a year ago
mozreview-review
Comment on attachment 8842570 [details]
Bug 1342820 - Reset navigation button state when clearing history.

https://reviewboard.mozilla.org/r/116354/#review118064
Attachment #8842570 - Flags: review?(ahunt) → review+

Comment 11

a year ago
Pushed by mozilla@buttercookie.de:
https://hg.mozilla.org/integration/autoland/rev/65317946fe00
Reset navigation button state when clearing history. r=ahunt
(Assignee)

Comment 12

a year ago
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.
Attachment #8842570 - Flags: approval-mozilla-aurora?

Comment 13

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/65317946fe00
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox54: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 54
status-firefox53: --- → affected
tracking-firefox53: ? → +
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.
Attachment #8842570 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 15

a year ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/1c85043498f0
status-firefox53: affected → fixed
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.
Status: RESOLVED → VERIFIED
status-firefox53: fixed → verified
status-firefox54: fixed → verified
You need to log in before you can comment on or make changes to this bug.