1182112 - Test loading XML documents if XSLT loading fails

Status: RESOLVED FIXED

(Core :: DOM: Service Workers, defect)

Comment 1

[Albert [:albert]]

releasing this since I don’t have time to work on it, so letting someone else to take it.

Comment 2

[Andrew Overholt [:overholt]]

https://dxr.mozilla.org/mozilla-central/source/dom/xslt/base/txURIUtils.cpp#60

Ehsan and jdm think this case happens with XML documents at data URLs.

Comment 3

[Andrea Marchesini [:baku]]

Attachment: force.patch

Me and Ehsan discussed this on IRC and we agreed that only data: documents are without channels. For this reason, if we have to create a new channel, we should not intercept it with ServiceWorkers.

Comment 4

[(no longer active)]

Comment on attachment 8664906 [details] [diff] [review]
force.patch

Review of attachment 8664906 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/xslt/base/txURIUtils.cpp
@@ +72,5 @@
>          }
> +
> +        nsCOMPtr<nsIHttpChannelInternal> internalChannel = do_QueryInterface(channel);
> +        if (internalChannel) {
> +            internalChannel->ForceNoIntercept();

Please add a comment explaining why this is needed.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

I'm not too familiar with our xslt code, but is this about documents loaded from data: or 
data-documents (created for example using document.implementation.createHTMLDocument())?
I guess about the latter.

But I don't know what ForceNoIntercept() does and why it is needed here.
In fact, it isn't clear to me why we need the artificial channel there anymore.
It was added in https://bugzilla.mozilla.org/show_bug.cgi?id=322683.
Even if channel wasn't passed, correct principal is explicitly set.

Comment 6

[Andrea Marchesini [:baku]]

Attachment: 264237.diff

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c281d27fbffc

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c281d27fbffc