"Clear Cookies and Site Data" menu item in the control centre/site information shows up with a noticeable delay
Categories
(Firefox :: Site Identity, defect, P2)
Tracking
()
People
(Reporter: ehsan.akhgari, Assigned: johannh)
References
(Regressed 1 open bug)
Details
Attachments
(2 files)
|
Assignee | |
Comment 1•6 years ago
|
||
|
||
Comment 3•6 years ago
|
||
|
||
Updated•5 years ago
|
|
||
Comment 4•5 years ago
|
||
This is hopefully going to be fixed with bug 1460768 which I'm planning to get done in 62
It's still not fixed in Nightly 70. Could the problem be prioritized, please? Firefox is a fast browser but this problem destroys a bit of the hard work you all invest to improve the perceived performance of Firefox. :-) And I guess with Skyline there will be a another marketing push for the address bar panels so users will probably notice the problem even more. People really shouldn't wait multiple seconds (!) to see the full content of the panel. ;-)
|
|
Assignee | |
Comment 5•5 years ago
|
||
Well, that's quite a dramatic way of framing it but I agree we should fix this in 70...
|
|
Assignee | |
Comment 6•5 years ago
|
||
The idea here is that we avoid updating all site data in SiteDataManager.jsm
just for checking a single host/origin and that we optimize performance by prioritizing
the most common data type (cookies) and synchronous lookups (AppCache) and returning
early if any data was found.
We will still refresh the site data list for clearing once the user clicks on "Clear Site Data".
|
||
Comment 8•5 years ago
|
||
| bugherder | ||
|
|
||
Comment 9•5 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #5)
Well, that's quite a dramatic way of framing it but I agree we should fix this in 70...
Sorry, it was not my intention to be dramatic. All I wanted to say was that sometimes it only needs one UI element with a weak performance to get the impression that the whole product is slow even if it's not true at all. Thank you so much for fixing this performance problem. I can verify it's fixed now. :)
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
||
Comment 10•5 years ago
|
||
Managed to reproduce the issue on Firefox 62.0a1 (2018-06-12), under Ubuntu 16.04x64.
The issue is no longer reproducible on Firefox 71.0a1 (2019-09-26), or on Firefox 70.0b9.
Tests were performed under Ubuntu 16.0x64, Windows 10x64 and macOS 10.12.6.
|
||
Comment 11•5 years ago
|
||
On Firefox 70.0.1 (Windows 10 x64), the button is there as soon as I click the lock, but clicking it seems to do nothing, until 2-4 seconds later a dialog appears.
If I click the button multiple times, 2-4 seconds later, multiple dialog appear simultaneously.
If I close the dialog and press the button again (on the same tab with the same site open), I get a 2-second delay again.
Name: Firefox
Version: 70.0.1
Build ID: 20191030021342
Update Channel: release
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
|
|
Assignee | |
Comment 12•5 years ago
|
||
(In reply to jimbo1qaz from comment #11)
On Firefox 70.0.1 (Windows 10 x64), the button is there as soon as I click the lock, but clicking it seems to do nothing, until 2-4 seconds later a dialog appears.
If I click the button multiple times, 2-4 seconds later, multiple dialog appear simultaneously.
If I close the dialog and press the button again (on the same tab with the same site open), I get a 2-second delay again.
Name: Firefox
Version: 70.0.1
Build ID: 20191030021342
Update Channel: release
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Sorry for the delay, I was out, can you please file a new bug for this?
|
|
||
Comment 13•5 years ago
|
||
Reported at https://bugzilla.mozilla.org/show_bug.cgi?id=1602994.
Description
•