Closed
Bug 794978
Opened 12 years ago
Closed 6 years ago
Always delete app's cookies even if the cookies have not been loaded yet
Categories
(Core :: Networking: Cookies, defect, P5)
Core
Networking: Cookies
Tracking
()
RESOLVED
WONTFIX
blocking-basecamp | - |
People
(Reporter: mounir, Assigned: jduell.mcbugs)
References
Details
(Whiteboard: [necko-would-take])
See: https://bugzilla.mozilla.org/show_bug.cgi?id=783408#c33
Seems that "cookie-db-read" notification is fired when the cookies are all loaded. We could maybe initialize the service if not running yet and then wait for that event to do the actual removal.
We might want to block on that (as a bug fix) because if no network connection is created and a user tries to delete the data of an app/browser, we might end up with the data not being deleted.
Comment 1•12 years ago
|
||
(In reply to Mounir Lamouri (:mounir) from comment #0)
> We might want to block on that (as a bug fix) because if no network
> connection is created and a user tries to delete the data of an app/browser,
> we might end up with the data not being deleted.
Sounds like a blocker. I clarified the summary, please fix if I did it incorrectly :)
blocking-basecamp: ? → +
Summary: Do not try to remove app's cookies if the cookies have not been loaded yet → Always delete app's cookies even if the cookies have not been loaded yet
Comment 2•12 years ago
|
||
Mounir, please let us know if you don't have time for this.
Assignee: nobody → mounir
Assignee | ||
Comment 3•12 years ago
|
||
Not sure this is actually much of a risk in practice, but I have ideas on how to fix.
Assignee: mounir → jduell.mcbugs
Comment 4•12 years ago
|
||
Is this really a basecamp blocker if the practical risk is low?
Reporter | ||
Comment 5•12 years ago
|
||
I don't think we should only consider the chances that this bug actually happens. We should take into consideration the consequences of the bug also. IMO, the consequences are not minor.
Updated•12 years ago
|
Priority: -- → P2
Updated•12 years ago
|
Priority: P2 → P3
Assignee | ||
Comment 7•12 years ago
|
||
It's not the first thing on my TODO list, but it's on it.
Flags: needinfo?(jduell.mcbugs)
Assignee | ||
Comment 8•12 years ago
|
||
See bug 810209: I'm proposing that we do that instead of this for B2G v1
blocking-basecamp: + → ?
Cool, let's fix this bug that way instead.
blocking-basecamp: ? → -
Depends on: 810209
Comment 10•11 years ago
|
||
Is this fixed entirely by bug 810209? Sounds like still a little racy, but y'all would know for sure.
Updated•11 years ago
|
Flags: needinfo?(jduell.mcbugs)
Assignee | ||
Comment 11•11 years ago
|
||
I'm not worried about correctness/raciness. At this point the cookie deletion thing works, but is an inefficient hack (mounir coded it to evict each of an app's cookies, one by one, which is a lot less efficient than just doing a SQL "delete where appId=XYZ"). So I'm leaving this bug open for technical debt (and I guess perf, though I'd be surprised if any app but a browser would see any really large delay).
Flags: needinfo?(jduell.mcbugs)
Comment 12•11 years ago
|
||
Ok, so the patch to close this would be more efficient cookie eviction on app uninstall? Anything else?
Updated•9 years ago
|
Whiteboard: [necko-would-take]
Comment 13•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P3 → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•