Many console warnings appear for requests that might need but don't actually use cookies without developer assistance on how to fix
Categories
(DevTools :: Console, defect, P3)
Tracking
(Not tracked)
People
(Reporter: Mardak, Unassigned)
References
(Blocks 1 open bug)
Details
I noticed that opening new tabs results in a lot more warnings now that we show more images when the user has set cookie blocking, e.g., unvisited 3rd party:
8x: Request to access cookie or storage on “https://img-getpocket.cdn.mozilla.net/432x216/filters:format(jpeg):quality(60):no_upscale():strip_exif()/https…” was blocked because we are blocking all third-party storage access requests and content blocking is enabled.
8x: … https://img-getpocket.cdn.mozilla.net/216x108/…
I see that bug 1487600 originally added the warnings, so is there a better way we should be making requests for the article images? There aren't any cookies used for the cdn, but the message makes it seem like actual cookies were blocked.
Right now these are
<picture>
<img src="https://img-getpocket.cdn.mozilla.net/216x108/…" srcset="https://img-getpocket.cdn.mozilla.net/432x216/… 2x">
</picture>
Comment 1•5 years ago
|
||
We display a warning message anytime an operation requires the accessing of the 3rd party tracking resource's cookie jar.
In your example, the request for that image could require the sending of cookies. Checking if we should send cookies, we display the warning message, also if there are no cookie to be sent.
dev-tools team is working on a better way to display console warnings. Maybe this bug should be handled by them.
Comment 2•5 years ago
|
||
(In reply to Ed Lee :Mardak from comment #0)
I noticed that opening new tabs results in a lot more warnings now that we show more images when the user has set cookie blocking, e.g., unvisited 3rd party:
8x: Request to access cookie or storage on “https://img-getpocket.cdn.mozilla.net/432x216/filters:format(jpeg):quality(60):no_upscale():strip_exif()/https…” was blocked because we are blocking all third-party storage access requests and content blocking is enabled.
8x: … https://img-getpocket.cdn.mozilla.net/216x108/…
We are currently working on grouping similar warnings in the Console panel to reduce the number of messages displayed to the user and this bug is related to it.
Can you please provide full URLs, so we can test it on our machines?
Honza
Updated•5 years ago
|
Comment 3•5 years ago
|
||
Ed, trying to answer your question, I assume crossorigin="anonymous"
on the picture
element help.
"anonymous" keyword means that there will be no exchange of user credentials via cookies
:baku, sounds like we could expand on the Learn More
pages to make those warnings more actionable?
Reporter | ||
Comment 4•5 years ago
|
||
(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #2)
Can you please provide full URLs, so we can test it on our machines?
An en-US nightly 68 build with browser.search.region
set to US or CA should have the new version of new tab with many more pocket articles by default, so setting the cookie blocking should result in the many warnings when opening a new tab.
Reporter | ||
Comment 5•5 years ago
|
||
(In reply to :Harald Kirschner :digitarald from comment #3)
Ed, trying to answer your question, I assume
crossorigin="anonymous"
on thepicture
element help.
Ah thanks for the pointer! Looks like setting it on the <img crossorigin="anonymous" …/>
makes the warnings go away.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 7•5 years ago
|
||
I split out to bug 1550842 the new tab issue triggering this issue given that this was moved to devtools for maybe at least one of these potential reasons:
dev-tools team is working on a better way to display console warnings. Maybe this bug should be handled by them.
We are currently working on grouping similar warnings in the Console panel to reduce the number of messages displayed to the user and this bug is related to it.
:baku, sounds like we could expand on the Learn More pages to make those warnings more actionable?
We can rename the bug to be more general now that the new-tab-specific trigger has been fixed.
Updated•2 years ago
|
Description
•