Bugzilla

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #11)
> (In reply to :Gijs (he/him) from comment #6)
> > I'm also not 100% sure how to fix this. Christoph, when reader mode is invoked without a document but with just a URL, it has to fetch the content itself. It's using XHR for that (in order to parse the returned HTML doc) and [manually follows meta redirects](https://searchfox.org/mozilla-central/rev/951a0342d600a1db263cac35ac85dbd4b3305aeb/toolkit/components/reader/ReaderMode.jsm#296). Is there some way we can communicate to the second XHR that is following the meta redirect, ie that it's a redirect chain, such that we wouldn't send samesite cookies?
> 
> The same-site cookie code checks for cross-origin redirects within [IsSameSiteForeign](https://searchfox.org/mozilla-central/source/netwerk/cookie/CookieCommons.cpp#544-558). So we could potentially query the loadinfo from the XHR request and fake a redirectEntry using `loadinfo->appendRedirectHistoryEntry()` so that `IsSameSiteForeign` can do it's job. I guess that could work.

Doesn't look like there are any JS consumers that create `nsIRedirectHistoryEntry` instances outside of tests. How safe is creating a JS "mock" one - `nsIRedirectHistoryEntry` isn't marked as builtinclass, but it feels pretty scary to pass a (mainthread only) JS thing into an API like that to leave it attached to the loadinfo and just hope nobody touches it away from the main thread... am I missing something?

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #11)
> (In reply to :Gijs (he/him) from comment #6)
> > I'm also not 100% sure how to fix this. Christoph, when reader mode is invoked without a document but with just a URL, it has to fetch the content itself. It's using XHR for that (in order to parse the returned HTML doc) and [manually follows meta redirects](https://searchfox.org/mozilla-central/rev/951a0342d600a1db263cac35ac85dbd4b3305aeb/toolkit/components/reader/ReaderMode.jsm#296). Is there some way we can communicate to the second XHR that is following the meta redirect, ie that it's a redirect chain, such that we wouldn't send samesite cookies?
> 
> The same-site cookie code checks for cross-origin redirects within [IsSameSiteForeign](https://searchfox.org/mozilla-central/source/netwerk/cookie/CookieCommons.cpp#544-558). So we could potentially query the loadinfo from the XHR request and fake a redirectEntry using `loadinfo->appendRedirectHistoryEntry()` so that `IsSameSiteForeign` can do it's job. I guess that could work.

Doesn't look like there are any JS consumers that create `nsIRedirectHistoryEntry` instances outside of tests. How safe is creating a JS "mock" one - `nsIRedirectHistoryEntry` isn't marked as builtinclass, but it feels pretty scary to pass a (mainthread only) JS thing into an API like that to leave it attached to the loadinfo and just hope nobody touches it away from the main thread... am I missing something?

Edit: also, what does "internal" in the code comment at https://searchfox.org/mozilla-central/rev/a23e65c5d69a821f61d14c8ec1f69a120e3f77d1/netwerk/base/nsILoadInfo.idl#852 mean?

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #11)
> (In reply to :Gijs (he/him) from comment #6)
> > I'm also not 100% sure how to fix this. Christoph, when reader mode is invoked without a document but with just a URL, it has to fetch the content itself. It's using XHR for that (in order to parse the returned HTML doc) and [manually follows meta redirects](https://searchfox.org/mozilla-central/rev/951a0342d600a1db263cac35ac85dbd4b3305aeb/toolkit/components/reader/ReaderMode.jsm#296). Is there some way we can communicate to the second XHR that is following the meta redirect, ie that it's a redirect chain, such that we wouldn't send samesite cookies?
> 
> The same-site cookie code checks for cross-origin redirects within [IsSameSiteForeign](https://searchfox.org/mozilla-central/source/netwerk/cookie/CookieCommons.cpp#544-558). So we could potentially query the loadinfo from the XHR request and fake a redirectEntry using `loadinfo->appendRedirectHistoryEntry()` so that `IsSameSiteForeign` can do it's job. I guess that could work.

Doesn't look like there are any JS consumers that create `nsIRedirectHistoryEntry` instances outside of tests. How safe is creating a JS "mock" one - `nsIRedirectHistoryEntry` isn't marked as builtinclass, but it feels pretty scary to pass a (mainthread only) JS thing into an API like that to leave it attached to the loadinfo and just hope nobody touches it away from the main thread... am I missing something?

Edit: also, what does "internal" [redirect] in the code comment at https://searchfox.org/mozilla-central/rev/a23e65c5d69a821f61d14c8ec1f69a120e3f77d1/netwerk/base/nsILoadInfo.idl#852 mean?