Closed Bug 776061 Opened 13 years ago Closed 6 years ago

Disable cookies inside browser

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
blocking-kilimanjaro ?
blocking-basecamp -

People

(Reporter: justin.lebar+bug, Assigned: jduell.mcbugs)

References

Details

(Keywords: feature, Whiteboard: [LOE:S][WebAPI:P3])

Attachments

(1 file)

See also https://github.com/mozilla-b2g/gaia/issues/1236 There are lots of ways we can do this, given that the requirement is only that we be able to disable cookies inside the Firefox browser app. I'll see what seems easiest.
Lest there be any confusion, I'm not actively working on this; Jonas has a plan, and I understand he's planning to carry it out without involvement of the browser API.
Summary: [BrowserAPI] Disable cookies inside browser → Disable cookies inside browser
Here is how we should do this: We should create a B2G setting (settable through the settings API) for controlling "browser cookies". We also create a observer in Gecko which observes this setting and mirrors it in a Gecko preference. We then make necko and the localStorage code observe this preference. When the preference is set, the necko code disables cookies for all requests with the isInBrowserElement flag set. Likewise the localStorage code throws when .localStorage is accessed from a principal with the isInBrowserElement set. I don't know what's involved with setting up an observer in Gecko which mirrors a B2G setting to a Gecko pref. Could anyone help out with this? If we can get help with that, I can write the code to make localStorage and cookies honor the pref.
blocking-basecamp: --- → ?
I guess you want something like this: https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/AutoMounterSetting.cpp That reads initial values from the settingsDB and observe changes.
blocking-basecamp: ? → +
Assignee: nobody → jduell.mcbugs
Jason: Does 1-2 weeks of work sound about right for this? That would include writing tests and getting reviews.
Whiteboard: [LOE:M]
Not to hijack this bug, but can you help me understand what this means, exactly? 1-2 weeks of work meaning "I start today, and it's done 1-2 weeks from today?" So my estimate might take into account how likely I am to be whisked off to other things during that time, how fast or slow I think my reviewer will be, whether I expect to push to try, and so on? Or does "1-2 weeks" mean "1-2 weeks of my undivided attention, 8 hours a day". I count the time spent addressing review comments, but not the time spent waiting for reviews, because I can do something else during that time. It sounds like you mean the first one (because you say it includes the time to "get reviews). But I don't see how the first one is at all useful to project management, because the it does not correspond to "person-hours", but instead is a wishy-washy "how busy am I?" measurement. Whether I can complete two or five "one-to-two-week" bugs within 2 weeks might have nothing to do with the bug itself but instead depend on how many reviews I'm asked to do during those two weeks!
> Or does "1-2 weeks" mean "1-2 weeks of my undivided attention, 8 hours a > day". I count the time spent addressing review comments, but not the time > spent waiting for reviews, because I can do something else during that time. We mean this one. I will clarify in the mailing list to the team.
I can't imagine a global on/off switch will take more than a week of programming. The review back + forth might be longer.
Whiteboard: [LOE:M] → [LOE:S]
Jason, do you have an ETA for this? It's blocking one of the final pieces of B2G browser from being complete.
I don't think the cookie code will take more than 1-2 days. Like jonas in comment 3 I don't know what's involved with setting up an observer in Gecko which mirrors a B2G setting to a Gecko pref, but looks like we've at least got a pointer to it in comment 4. Someone who knows that code already can probably do it faster than me, but I can also do it.
Whiteboard: [LOE:S] → [LOE:S][WebAPI:P3]
Keywords: feature
Latest word is that we're going to do a "delete private data" feature instead of this feature. Yes, I'm sorry the requirements keep changing :(
blocking-basecamp: + → -
blocking-kilimanjaro: --- → ?
Component: DOM: Mozilla Extensions → DOM
This seems to be a b2g bug. Closing as WONTFIX
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: