Suppress cookie dialog for prefetched documents I think we should consider making nsCookiePromptService::CookieDialog refuse to accept cookies if the parent window parameter is null. Or, we should make the caller do this check. Another choice would be to inspect the channel passed to nsCookiePermission::CanSetCookie to see if it doing prefetching. Thoughts?
why does prefetch's channel have notificationCallbacks set? and if it doesn't, why is there a cookie dialog? (I don't think prefetch should show nsIAuthPrompt dialogs either...)
> and if it doesn't, why is there a cookie dialog? it doesn't have it set. the cookie dialog code uses windowwatcher to get a parent dialog if non is supplied. see my suggested fix in comment #0. i think there is no auth prompt for prefetched documents precisely because there are no notification callbacks assigned on the channel, and there is no load group either.
Wasn't there a bug where it was agreed that prefetching should just delay the cookie stuff until the page was really loaded, at which time the headers should take effect?
(In reply to comment #3) > Wasn't there a bug where it was agreed that prefetching should just delay the > cookie stuff until the page was really loaded, at which time the headers should > take effect? That would be my understanding of privacy. Why tell users they can block cookies whenever they understand how to, when websites just can set the prefetch labels to enable prefetching of content and silent cookies related to that content, if I correctly understand the topic of this bug.
the default behavior would be to block cookies when prefetching if there is no available prompt.
> the default behavior would be to block cookies when prefetching if there is no > available prompt. That doesn't sound right. The behaviour as far as the user sees should be indistinguishable when we do prefetching and when we don't, with the exception of the prefetching being faster. That means prompts appearing in the same places, cookies being set in the same places, etc. Most notably for this case, it means prompts appearing after the user clicks the link, not before, and cookies being set after the user goes to the page, and not before.
sorry if i'm out of touch here... can we store the headers somewhere and 'play' them to the cookieservice (and other services of interest) on user click? i'm unsure what's involved in caching them for this purpose, but it seems like the cleanest solution. of course, dialogs should die, but that's a separate argument ;)
Would it be better (for this, security and other reasons) to just not do cross-domain link prefetching? Gerv
*** Bug 313577 has been marked as a duplicate of this bug. ***
12 years ago
pre-fetched URLs are possibly being given the oppertunity to set cookies before the user actually visits the page in question. Eg - google currently seems to use prefetch for the first URL in the search results and I do see sites setting cookies via the prefetch reference. This wouldn't be so much of a possible privacy violation but this allows a site in another domain (ie, not the domain you're looking at right now, so not google.com as an example) to set a cookie without you having visited that site.
this could be fixed using the new LOAD_ANONYMOUS flag from bug 389508