Closed Bug 1514824 Opened 5 years ago Closed 5 years ago

Add an MDN link for cookie/storage warnings

Categories

(DevTools :: Console, enhancement, P1)

Product:
DevTools
Component:
Console
Version:
65 Branch
Type:
enhancement

Tracking

(firefox67 fixed)

Status:
RESOLVED FIXED
Milestone:
Firefox 67
Tracking Flags:
Tracking Status
firefox67 --- fixed

People

(Reporter: Harald, Assigned: nchevobbe)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, Whiteboard: [console-grouping])

Attachments

(1 file)

Bug 1514824 - Add an MDN link for cookie/storage warning messages in console; r=bgrins.
47 bytes, text/x-phabricator-request
Details | Review 
`Request to access cookie or storage on “https://www.youtube.com/embed/C6Cyrpkb25k?rel=0&html5=1&&enablejsapi=1&origin=https://developer.mozilla.org” was blocked because it came from a tracker and content blocking is enabled.`

As best practice, console warnings should have links to MDN that explain the concept, heuristics, and next steps for developers.

The page could be https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy
Christoph, as you helped before and know what needs to be done; can you find who can help with this on the platform side?
Flags: needinfo?(ckerschb)
Severity: normal → enhancement
Priority: -- → P1
Blocks: 1462372
(In reply to :Harald Kirschner :digitarald from comment #1)
> Christoph, as you helped before and know what needs to be done; can you find
> who can help with this on the platform side?

What kind of help do you need?  baku or I could probably help.
That would be great!

Similar to bug 1475073 for CORS, warnings need to be mapped to a category, which then maps to a MDN page.

Since we already have a category for `Tracking Protection` [1], we should probably add a new category for `Storage access`.

Does that sound OK, Nicolas?

[1]: https://searchfox.org/mozilla-central/source/devtools/server/actors/errordocs.js#109
Flags: needinfo?(nchevobbe)
> Does that sound OK, Nicolas?

It does :)
Flags: needinfo?(nchevobbe)
(In reply to :Harald Kirschner :digitarald from comment #3)
> That would be great!
> 
> Similar to bug 1475073 for CORS, warnings need to be mapped to a category,
> which then maps to a MDN page.

Hey Ehsan, Andrea, as Harald already mentioned we pass individual errors as categories which devtools folks then use to generate unique links to MDN. I think by looking at Bug 1304645 or also Bug 1475073, where we have done similar things, you get what they are seeking. If not, let me know and I can explain in more detail.

Could you or baku take that on?
Flags: needinfo?(ehsan)
Flags: needinfo?(ckerschb)
Flags: needinfo?(amarchesini)
Sure.
Assignee: nobody → ehsan
Flags: needinfo?(ehsan)
Err, I guess I'll file a dependency.

I assume I can use some arbitrary strings for the names of the categories...
Assignee: ehsan → nobody
Depends on: 1515063
Please see the patch I posted in bug 1515063 which does what comment 5 suggested.
Flags: needinfo?(amarchesini)
OK, the patch is on autoland now.  New categories to use are:

  * cookieBlockedPermission: when we block a cookie due to a cookie permission.
    Console message: Request to access cookies or storage on “%1$S” was blocked because of custom cookie permission.

  * cookieBlockedTracker: when we block a cookie due to it coming from a tracker.
    Console message: Request to access cookie or storage on “%1$S” was blocked because it came from a tracker and content blocking is enabled.

  * cookieBlockedAll: when we block a cookie due to all cookies being set to be blocked.
    Console message: Request to access cookie or storage on “%1$S” was blocked because we are blocking all storage access requests.

  * cookieBlockedForeign: when we block a third-party cookie due to third-party cookies being set to be blocked.
    Console message: Request to access cookie or storage on “%1$S” was blocked because we are blocking all third-party storage access requests and content blocking is enabled.
(In reply to :Ehsan Akhgari from comment #9)
> OK, the patch is on autoland now.  New categories to use are:
> 
>   * cookieBlockedPermission: when we block a cookie due to a cookie
> permission.
>     Console message: Request to access cookies or storage on “%1$S” was
> blocked because of custom cookie permission.
> 
>   * cookieBlockedTracker: when we block a cookie due to it coming from a
> tracker.
>     Console message: Request to access cookie or storage on “%1$S” was
> blocked because it came from a tracker and content blocking is enabled.
> 
>   * cookieBlockedAll: when we block a cookie due to all cookies being set to
> be blocked.
>     Console message: Request to access cookie or storage on “%1$S” was
> blocked because we are blocking all storage access requests.
> 
>   * cookieBlockedForeign: when we block a third-party cookie due to
> third-party cookies being set to be blocked.
>     Console message: Request to access cookie or storage on “%1$S” was
> blocked because we are blocking all third-party storage access requests and
> content blocking is enabled.

Hello Ehsan, 
Would you have STR that produces those messages so I can have a look at this issue? Thanks!
Sure.  On Nightly, by default we block cookies from trackers.  If you go to a news website like bbc.com you should see a lot of cookies being blocked from trackers.  That should cover cookieBlockedTracker.

For cookieBlockedAll, in about:preferences#privacy, select Custom under Content Blocking, under Cookies, select "All Cookies...".  Then refresh the BBC tab.  :-)

For cookieBlockedForeign, in about:preferences#privacy, select Custom under Content Blocking, under Cookies, select "All Third-Party Cookies...".  Then refresh the BBC tab.

For cookieBlockedPermission, in about:preferences#privacy, select Custom under Content Blocking, uncheck Cookies, then scroll down, next to "Delete cookies and site data when Nightly is closed" click on "Manage Permissions".  Then under "Address of website" you should enter the address of a third-party site that is setting cookies on BBC (or the site you're testing on.)  To see the list of third-parties (or trackers, either would work) which are setting cookies on a site, you can open the control centre on the site, click on Cookies and then look under "Tracking Cookies" or "Third-Party Cookies".  For example, I am getting a third-party cookie from https://experience.tinypass.com right now on bbc.com.  So, in that field I can type https://tinypass.com.  (It may be different for you.)  Then click on Block followed by Save Changes.  Then refresh the BBC tab.

In all of these cases, you should see the appropriate messages in the console, and the control centre's Cookies subpanel should reflect the type of blocking that's happening after you update Nightly's settings.

Good luck, and let me know if you needed help.
:Ehsan, would all of those categories link to https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy for now? We can have a follow up issue with MDN to create specific landing pages for every category.
Flags: needinfo?(ehsan)
(In reply to :Harald Kirschner :digitarald from comment #12)
> :Ehsan, would all of those categories link to
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/
> Storage_access_policy for now? We can have a follow up issue with MDN to
> create specific landing pages for every category.

No, that page is only relevant for cookieBlockedTracker.  It would be misleading to use it for the rest.

We should probably create individual pages for each error code, and have each page describe what kind of cookie blocking is happening in that case, and how it impacts the web page.  The "how" part is actually already documented here: <https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#What_does_the_storage_access_policy_block>.  It may make sense to break that part off into its own page and link to it from each one of these pages.

The other option is of course to extend the current page.  I don't have a strong opinion on that, but the existing content only describes blocking storage access from trackers.  Chris Mills has been helping us with this project, he may be a good person to reach out to in order to consult with about how to do this best from the MDN perspective...
Flags: needinfo?(ehsan)

(In reply to :Ehsan Akhgari from comment #13)

(In reply to :Harald Kirschner :digitarald from comment #12)

:Ehsan, would all of those categories link to
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/
Storage_access_policy for now? We can have a follow up issue with MDN to
create specific landing pages for every category.

No, that page is only relevant for cookieBlockedTracker. It would be
misleading to use it for the rest.

We should probably create individual pages for each error code, and have
each page describe what kind of cookie blocking is happening in that case,
and how it impacts the web page. The "how" part is actually already
documented here:
<https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/
Storage_access_policy#What_does_the_storage_access_policy_block>. It may
make sense to break that part off into its own page and link to it from each
one of these pages.

The other option is of course to extend the current page. I don't have a
strong opinion on that, but the existing content only describes blocking
storage access from trackers. Chris Mills has been helping us with this
project, he may be a good person to reach out to in order to consult with
about how to do this best from the MDN perspective...

We'd probably want to follow the same kind of pattern as we have followed for

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors

So maybe we could have a page under

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors

that acts as a landing/index page for the errors, then have an individual page for each erorr along these lines:

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSDisabled

How many errors are there to document?

Hello Chris,

In Bug 1515063, where the categories were added, we refer to 4 type of errors:

CookieBlockedByPermission=Request to access cookies or storage on “%1$S” was blocked because of custom cookie permission.
CookieBlockedTracker=Request to access cookie or storage on “%1$S” was blocked because it came from a tracker and content blocking is enabled.
CookieBlockedAll=Request to access cookie or storage on “%1$S” was blocked because we are blocking all storage access requests.
CookieBlockedForeign=Request to access cookie or storage on “%1$S” was blocked because we are blocking all third-party storage access requests and content blocking is enabled.

(See necko.properties).

So I guess we should start with those.
Ehsan, am I right?

Flags: needinfo?(ehsan)

Yes, exactly.

Flags: needinfo?(ehsan)

Thanks Ehsan!

Chris, what would be the next steps to have those errors documented on MDN ?

Flags: needinfo?(cmills)

(In reply to Nicolas Chevobbe from comment #17)

Thanks Ehsan!

Chris, what would be the next steps to have those errors documented on MDN ?

I am happy to get the page structures set up and start adding the content templates ready to be filled in, but I'll probably need your help on the engineering side to fill in the actual details.

I might have some free time to do this next week — seen as it is only 4 errors it will not take very long. Does that plan suit you?

Flags: needinfo?(cmills) → needinfo?(nchevobbe)

Yes, looks good to me, thanks!

Flags: needinfo?(nchevobbe)

(In reply to Nicolas Chevobbe from comment #19)

Yes, looks good to me, thanks!

OK, cool. I'll get the page structures created probably Monday, then give you a shout about helping to fill in the details.

I've set up a landing page for the errors here:

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors

I've also created the actual error pages. Only one of them has any content in it:

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedByPermission

This is the kind of template I'd expect to use for each of the pages. I don't think it needs to be much more complicated than that, but let me know if you think any other sections should be included.

A couple of questions:

  1. Is this in the right place? I was a bit concerned by Ehsan's comment above "No, that page is only relevant for cookieBlockedTracker". We can always move the page tree if needed.
  2. Does the landing page need any more content. there is something above about moving some content over from the main SAP page, but I wasn't sure how muhc was relevant.

So let me know if you are OK to fill in some details here. I am happy to give edits and advise after the fact.

Flags: needinfo?(nchevobbe)

Thanks a lot Chris!

Is this in the right place? I was a bit concerned by Ehsan's comment above "No, that page is only relevant for cookieBlockedTracker". We can always move the page tree if needed.

I think it was in response to "should all the error link to https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy", and I think what you did is fine because we have distinct pages for all those errors.

Does the landing page need any more content.

I think it's okay as is? Not sure though, let's check what Ehsan thinks.

Flags: needinfo?(nchevobbe) → needinfo?(ehsan)

(In reply to Nicolas Chevobbe from comment #22)

Thanks a lot Chris!

Is this in the right place? I was a bit concerned by Ehsan's comment above "No, that page is only relevant for cookieBlockedTracker". We can always move the page tree if needed.

I think it was in response to "should all the error link to https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy", and I think what you did is fine because we have distinct pages for all those errors.

OK, no worries then.

(In reply to Nicolas Chevobbe from comment #22)

Thanks a lot Chris!

Is this in the right place? I was a bit concerned by Ehsan's comment above "No, that page is only relevant for cookieBlockedTracker". We can always move the page tree if needed.

I think it was in response to "should all the error link to https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy", and I think what you did is fine because we have distinct pages for all those errors.

Does the landing page need any more content.

I think it's okay as is? Not sure though, let's check what Ehsan thinks.

Yes, Nicolas is right. I only meant that we should have a separate page. :-)

One note about https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors (and I guess about the individual error pages too): the names of the error messages (e.g. CookieBlockedByPermission, etc) aren't user facing, and developers won't see them anywhere in the application UI, so we should probably not show them anywhere in the documentation. That includes the title of the individual error pages like https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedByPermission. I wasn't sure what happens to the URLs if we edit the page titles to something else... (It's not a big deal for these names to appear in the URLs of course, and it probably makes it simpler for the devtools code to map the error messages to URLs to keep the names in URLs.)

Flags: needinfo?(ehsan)

(In reply to :Ehsan Akhgari from comment #24)

One note about https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors (and I guess about the individual error pages too): the names of the error messages (e.g. CookieBlockedByPermission, etc) aren't user facing, and developers won't see them anywhere in the application UI, so we should probably not show them anywhere in the documentation. That includes the title of the individual error pages like https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedByPermission. I wasn't sure what happens to the URLs if we edit the page titles to something else... (It's not a big deal for these names to appear in the URLs of course, and it probably makes it simpler for the devtools code to map the error messages to URLs to keep the names in URLs.)

Ah, OK. This is not a problem — I can easily move existing pages to new URLs, and the old URLs will automatically redirect to them.

I think the pages will be more intuitive and have better SEO if we change the titles and URLs to reflect what the web devs encountering these errors will actually see in the console, etc.

So what should we change the title/URL to, in each case?

Chris, I started to look into the implementation, and I have a question.

For all those [Learn more] links, we add some utm_* parameters, for example, this for cors utm_source=devtools&utm_medium=firefox-cors-errors&utm_campaign=default.

What should those be for the storage access errors?

(In reply to Nicolas Chevobbe from comment #26)

Chris, I started to look into the implementation, and I have a question.

For all those [Learn more] links, we add some utm_* parameters, for example, this for cors utm_source=devtools&utm_medium=firefox-cors-errors&utm_campaign=default.

What should those be for the storage access errors?

This is a good question — I'm not sure.

For the JS error messages, the parameters are ?utm_source=mozilla&utm_medium=firefox-console-errors&utm_campaign=default

So I'm guessing you'd use something like utm_source=devtools&utm_medium=firefox-cookie-errors&utm_campaign=default. The medium param is probably just something unique that we can use to track the number of click throughs we get to these pages from the devtools.

I'm ni'ing Kadir here, as he knows about these things. Kadir, this is for a new set of error pages related to cookie/storage blocking. Anything in particular we need to put for the utm params?

Flags: needinfo?(a.topal)

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #25)

(In reply to :Ehsan Akhgari from comment #24)

One note about https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors (and I guess about the individual error pages too): the names of the error messages (e.g. CookieBlockedByPermission, etc) aren't user facing, and developers won't see them anywhere in the application UI, so we should probably not show them anywhere in the documentation. That includes the title of the individual error pages like https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedByPermission. I wasn't sure what happens to the URLs if we edit the page titles to something else... (It's not a big deal for these names to appear in the URLs of course, and it probably makes it simpler for the devtools code to map the error messages to URLs to keep the names in URLs.)

Ah, OK. This is not a problem — I can easily move existing pages to new URLs, and the old URLs will automatically redirect to them.

I think the pages will be more intuitive and have better SEO if we change the titles and URLs to reflect what the web devs encountering these errors will actually see in the console, etc.

So what should we change the title/URL to, in each case?

The console messages in comment 9 are what developers will see (in English builds of course.)

(In reply to :Ehsan Akhgari from comment #28)

The console messages in comment 9 are what developers will see (in English builds of course.)

Cool, thanks.

So I've updated the error links on the landing page to be part of the actual error message:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors

Then if you you click the links, you'll see that I've changed the page titles to an abbreviated version of the error. The full error would still appear in the information on the page below, in each case.

If these abbreviated errors are OK, I could then also change the URL slugs to match them.

utm_source=devtools&utm_medium=firefox-cookie-errors&utm_campaign=default sounds good to me.

Flags: needinfo?(a.topal)

+1 on utm_source=devtools&utm_medium=firefox-cookie-errors&utm_campaign=default . I was providing the UTM parameter requirements for the CORS errors and this format is in line with all recently added links.

Assignee: nobody → nchevobbe
Whiteboard: [console-unclutter]

So I have a working patch and a test for it.
For some reason I can't explain, I can't have the "blocked because it is a tracker" message to show up in the mochitest (See https://phabricator.services.mozilla.com/D18812#inline-100160).
It certainly does when browsing (e.g. on cnn.com), so I guess I'm missing something from the test harness.
Ehsan, would you happen to know how I could get the message to be displayed in a mochitest?

ni francois as he worked on the addTestTrackers function

Flags: needinfo?(francois)
Flags: needinfo?(ehsan)

:baku or :dimi might be able to help here, I don't work at Mozilla anymore.

Flags: needinfo?(francois) → needinfo?(dlee)

(In reply to Nicolas Chevobbe from comment #34)

ni francois as he worked on the addTestTrackers function

I did a quick test and found out sometimes after the "refreshTab" call, the iframe "tracking.example.com" doesn't reload.
So the error message doesn't show up because the channel is not classified.

You can check if this is the same issue as yours.

Flags: needinfo?(dlee)

In a mochitest that has called the addTestTrackers function, you would need to load third-party content that sets a cookie in a variety of cases.

  • For cookieBlockedPermission, you would need to create a deny "cookie" permission for example.net and load the third-party content from example.net.

  • For cookieBlockedTracker, you would need to set the network.cookie.cookieBehavior pref to 4 and load the third-party content from tracking.example.org (this domain is marked as a tracker in mochitests).

  • For cookieBlockedAll, you would need to set the network.cookie.cookieBehavior pref to 2 and load the third-party content from any domain (e.g. example.com).

  • For cookieBlockedForeign, you would need to set the network.cookie.cookieBehavior pref to 1 and load the third-party content from a third-party domain (doesn't really matter what domain you pick as long as it's different from the top-level domain).

Please note that after bug 1525245 lands, our cookie policy and permissions will only be read for each top-level document when the initial navigation happens, so in your test in each case after setting the prefs/permissions, you probably want to open a new window and load your test pages in there to ensure your test will work correctly after that bug.

Flags: needinfo?(ehsan)

Thanks a lot for the explanations, I was able to get the blocked tracker message working in my test :)
I've pushed to TRY to ensure everything is okay.

(In reply to Nicolas Chevobbe from comment #38)

Thanks a lot for the explanations, I was able to get the blocked tracker message working in my test :)
I've pushed to TRY to ensure everything is okay.

FYI those "mda" chunks are perma orange in artifact builds (so not related to your patches). I have Bug 1526058 on file for that.

Pushed by nchevobbe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/317b67e93f37
Add an MDN link for cookie/storage warning messages in console; r=bgrins.

https://hg.mozilla.org/mozilla-central/rev/317b67e93f37

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox67: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

The links are now displayed in the console. Could we prioritize writing the actual content for those pages so the links are useful for developers? Thanks!

Flags: needinfo?(cmills)

(In reply to Nicolas Chevobbe from comment #42)

The links are now displayed in the console. Could we prioritize writing the actual content for those pages so the links are useful for developers? Thanks!

I'm happy to help with this, but as stated above, I don't know what content needs putting in these pages so would need some help from you with the content.

Would you be able to fill in some content on

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedByPermission

?

You don't need to fill in finished content, just rough notes and examples, then I can come in and edit it to make it look finished.

Then once we are agreed that the structure of the first page looks good, we can move on to the others.

Flags: needinfo?(cmills)
Keywords: dev-doc-needed

Nicolas, just a gentle ping (and ni) to make sure you saw the above comment.

Flags: needinfo?(nchevobbe)

I just started editing the page when I received your comment :) On it!

Flags: needinfo?(nchevobbe)
Whiteboard: [console-unclutter] → [console-grouping]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: