Closed Bug 959985 Opened 11 years ago Closed 9 years ago

Notification bar for offline storage is always being bypassed despite ticking "tell me when a website asks to store data for offline use" in preferences

Categories

(Core :: Networking: Cache, defect)

26 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: nicholas, Unassigned)

Details

(Keywords: privacy, Whiteboard: [testday-20140328])

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131206145833 Steps to reproduce: 1. Under Preferences -> Advanced -> Network -> Offline Web Content and User Data, hit the 'Clear Now' button, ensure that the 'Tell me when a website asks to store data for offline use' is checked, and that there are no Exceptions listed in the Exceptions dialog. 2. Navigate to a website that uses offline storage. Actual results: Notifcation bar does not appear. By viewing server logs I can see that the manifest assets are being downloaded. After some time the site is listed in Preferences -> Advanced -> Network -> Offline Web Content and User Data and the total bytes of disk space used has increased from zero. Expected results: The notification bar should have appeared and I should have had the option not to accept downloading of assets for offline use.
Keywords: privacy
Ran into the same problem visiting http://developers.whatwg.org/ ; it applies to the Android version as well, by the way.
Reproduced at the 2048 game with firefox-29.0b3.ru.linux64. There is also bug 456517, which the reporter resolved INVALID: bug 456517 comment 2. I don't understand what he meant.
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: Cache
Ever confirmed: true
Product: Firefox → Core
Whiteboard: [testday-20140328]
Same with 2014-03-28-03-02-03-mozilla-central-firefox-31.0a1.en-US.linux-x86_64. The 482 KB are deleted when I "Clear Recent History" (Last Hour) with only "Site Preferences" checked.
Same situation here with Firefox 29.0.1 (64 bits) on Debian Wheezy. To #c2: Aleksej, I neither understand why reporter of bug #456517 closed it as "invalid", the issue seems to be present and easily reproducible.
I can reproduce this with Firefox 30.0 on Windows 8.1.
The problem still occurs in version 44. Here https://support.mozilla.org/en-US/questions/1014708 and here https://support.mozilla.org/en-US/questions/1098540 are presented a stopgap solution: toggle the value of the preference "offline-apps.allow_by_default" to "false". I DO NOT confirmed this.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Patrick, can you please explain why the bug has been marked as "resolved → wontfix" without further details about the reason? The issue is still present in Firefox 44.0.2 so maybe we missed something. Thanks.
appcache is being replaced by serviceworkers.. only critical fixes are accepted in the interim.
Thanks for clarifying this, but tagging the bug as "wontfix" will leave the bug closed once the transition period is over and service workers are in place. Wouldn't have been better to keep the bug open instead? By closing it, it will be for sure forgotten while the problem still remains.
I support not to close this issue. Firefox still has the reputation that you can get notified if anything potentially privacy disturbing features are requested, and this functionality is definitely required to keep this reputation alive.
The checkbox should *not* be present if it doesn't work. If hooking it up to the pref. mentioned above isn't correct, or takes too much work, then the checkbox should be removed unti it works, so the user doesn't falsely believe they have successfully blocked this user-tracking vector. And this bug definitely shouldn't be marked "WONTFIX". It's not an matter of opinion, or a fundamental impossibility to fix, it's a straightforward and legitimate bug.
I agree with others, and the fact it's been 2 years now with no update and this bug still exists is just further proof it should have never been closed. It's misleading and *irresponsible* to a) leave this as is and, more so, b) have a checkbox that *falsely* leads people to believe they are blocking this access. I assumed, when going through all the settings and making sure this was checked, that I was protecting myself by doing so, and only just now, by chance, discovered that's not the case.
You need to log in before you can comment on or make changes to this bug.