Closed
Bug 1323614
Opened 9 years ago
Closed 8 years ago
Forget browsing history visibly resets to 5 minutes radio button (because sanitize is slow)
Categories
(Firefox :: Bookmarks & History, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: daustie, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507
Steps to reproduce:
Click forget browsing history icon, select two hours or 24 hours radio button, click the FORGET! button.
Actual results:
Just as FF prepares to close, the selected radio button gets deselected and the FIVE MINUTES radio button highlights, then FF closes and reopens.
Expected results:
The radio button I select should remain selected as FF closes to give the user some confidence that what they select actually happens.
Comment 1•9 years ago
|
||
This is a problem, but not one that needs to be hidden as a security bug.
I can't reproduce this (testing on OS X). The panel hides before the rest of Firefox closes. Can you reproduce this if you try with a separate clean profile ( https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles ) ? (You don't have to remove your existing profile to do this.)
Group: firefox-core-security
Component: Untriaged → General
Flags: needinfo?(daustie)
Updated•9 years ago
|
Component: General → Bookmarks & History
Reproducible on Windows10 and LinuxMint 18 with nightly 20161216030207 and fresh profile, probably because
https://dxr.mozilla.org/mozilla-central/source/browser/components/customizableui/CustomizableWidgets.jsm#1232
Updated•9 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•9 years ago
|
||
I guess we should explicitly close the panel before resetting - the window closing is too fast on my machine, but apparently not on other people's...
Flags: needinfo?(daustie)
Summary: Forget browsing history ALWAYS defaults to 5 minutes, V 50.1.0, OS win7 → Forget browsing history visibly resets to 5 minutes radio button (because sanitize is slow)
Updated•9 years ago
|
Priority: -- → P3
Comment 4•8 years ago
|
||
Here's a video of a user experiencing this on Twitter:
https://twitter.com/BWGREENLEAF/status/962800981695254529
Hey Gijs, does this mean that the 24 hour sanitization _is_ occurring, but we're glitching out visually a bit by showing the 5 minute item selected before teardown?
Flags: needinfo?(gijskruitbosch+bugs)
Comment 5•8 years ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) from comment #4)
> Here's a video of a user experiencing this on Twitter:
>
> https://twitter.com/BWGREENLEAF/status/962800981695254529
>
> Hey Gijs, does this mean that the 24 hour sanitization _is_ occurring, but
> we're glitching out visually a bit by showing the 5 minute item selected
> before teardown?
Having reviewed the code, the answer is "yes, but only on 59 and earlier, and early nightlies of 60", because bug 1167238 broke this on recent nightlies by changing the ordering of getting the sanitizer range and when we reset the item. I filed bug 1437486 on this. I'll update the user on twitter as well, and I'll see about getting a patch for these bugs done because it's clearly causing issues.
Flags: needinfo?(gijskruitbosch+bugs)
Comment 6•8 years ago
|
||
This should be fixed by bug 1437486.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•