Site Data Manager should watch for site data changes and update itself
Categories
(Firefox :: Settings UI, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox62 | --- | wontfix |
firefox63 | --- | wontfix |
firefox64 | --- | fix-optional |
People
(Reporter: johnjones1979, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(13 obsolete files)
Updated•7 years ago
|
Updated•7 years ago
|
Comment 1•7 years ago
|
||
Reporter | ||
Comment 3•7 years ago
|
||
Updated•7 years ago
|
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 9•6 years ago
|
||
Comment 10•6 years ago
|
||
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 16•6 years ago
|
||
Comment 17•6 years ago
|
||
Comment 18•6 years ago
|
||
Comment 19•6 years ago
|
||
Comment 21•6 years ago
|
||
Comment 22•6 years ago
|
||
Comment 23•6 years ago
|
||
Comment 24•6 years ago
|
||
Comment 25•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 26•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 27•6 years ago
|
||
Please take your time with the reviews, I'm not hoping to land before 66 merges to beta. This feels like it would need a good beta cycle to confirm it doesn't impact perf and to iron out possible issues.
Comment 28•6 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #27)
Please take your time with the reviews, I'm not hoping to land before 66 merges to beta. This feels like it would need a good beta cycle to confirm it doesn't impact perf and to iron out possible issues.
Can you do a trypush with talos and raptor tests (at least 5 runs of each) to check for perf issues pre-emptively, if we expect there might be some?
Did you consider an alternative solution, like refreshing the list when the tab gets a pageshow event (ie. because the user switched to a different tab and then back)? That seems like it'd require less infrastructure and have less perf impact.
If we need to use this mechanism, can we add/remove the cache/cookie/whatever listeners based on when the dialog is actually open, instead of doing it on startup? As it is, the perf impact even just on startup seems like it'd likely not be acceptable (even if it probably won't end up showing up on try because it's so small on the really fast hardware we run the tests on, and the noise is substantial).
Comment 29•6 years ago
|
||
Yeah, there might be better ways to do this. One problem here is that I'm trying to solve both this bug and bug 1468355 in a single set of patches as well as doing a bunch of unrelated cleanups.
The more I think about this the more I come to the conclusion that having a constantly updating SiteDataManager might not be worth it, even if the perf hit is minimal. I like the idea of attaching listeners while the dialog (or about:preferences) is open much better, I'll only have to find a separate solution to bug 1468355 then.
I'm going to come up with a plan on how to fix all these intermingled issues in separate patches instead and file the outstanding bugs.
Comment 30•5 years ago
|
||
With bug 1468355 on its way to resolution I have to admit that I have bigger fish to fry right now and am resigning from this bug for now...
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•2 years ago
|
Description
•