Closed Bug 1416548 Opened 7 years ago Closed 6 years ago

cookies.onChanged changeInfo should contain tabId

Categories

(WebExtensions :: General, defect, P5)

56 Branch
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: craig, Unassigned)

Details

(Whiteboard: [design-decision-denied][cookies])

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171003144318

Steps to reproduce:

Attempting to implement a cookie managing webextension, and wanting to handle cookies set by Javascript rather than by headers, I add a listener to cookies.onChanged.  


Actual results:

The changeInfo object passed contains no usable information to identify which tab this cookie change is happening in.   At best, by listening to a bunch of other events, and tracking a lot of state, some inferences can be made, but they're not definitive (could imply >1 tabs)


Expected results:

Ideally, the changeInfo object should contain a tabId (or something similar).
I'm not sure how possible this is. It's definitely not possible with the current notification from nsICookieService, but changes to that may be possible or there may be other ways of implementing this.

Adding it to the API triage for further discussion.
Status: UNCONFIRMED → NEW
Component: WebExtensions: Untriaged → WebExtensions: General
Ever confirmed: true
Priority: -- → P5
Whiteboard: [design-decision-needed][cookies]
Hi Craig, this has been added to the agenda for the November 28, 2017 WebExtensions APIs triage meeting. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/Add-ons/Contribute/Triage
* Meeting agenda: https://docs.google.com/document/d/1MduEIKmXDdj3p94PJDrPPPYvbSfEdrrMF-UhMnHPqEQ/edit#heading=h.edrw957gm8hg
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
Sadly the meeting is scheduled for the middle of my commute (7:30am NZDT, +1300).  Is there any additional information I can provide before hand to assist?
No worries at all. We may needinfo you if any questions come up during the meeting.
This would indeed be very nice to have.
My use-case would be to track what cookies are created by a third party. (i.e. if the domain of the cookie does not match the one from the tab)
Flags: needinfo?(bob.silverberg)
Whiteboard: [design-decision-needed][cookies] → [design-decision-denied][cookies]
We discussed the fact that cookies are not necessarily always associated with a particular tab, so this request doesn't really make sense. Is there another way of explaining what data you need access to, that isn't specifically a tabId?
Flags: needinfo?(bob.silverberg)
Don't suppose the tabs url is any better?
BTW, for me it would be acceptable if this info wasn't set on cookies which have not been created by a tab.
Yeah, what Lusito said.  I'm trying to track which tab set the cookie when it was set by Javascript so I can display a list of cookies set (or blocked from being set) in a WebExtension Popup (to allow further user choices).  This popup is (obviously?) going to be displaying information about the current tab only.
 
I'd be quite happy for the tabID to be an optional item, available only if the cookie was *actually* set in the context of a tab, because that's the only ones I'm interested in tracking this information about.

I am lightly interested in what other contexts can set cookies by Javascript, although that's largely academic for my needs in this bug.
Closing all open bugs with the [design-decision-denied] whiteboard flag.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
So is this a final won't fix? I'd really like to see this happen.
Flags: needinfo?(kmaglione+bmo)
Product: Toolkit → WebExtensions
Flags: needinfo?(kmaglione+bmo)
You need to log in before you can comment on or make changes to this bug.