Steps To Reproduce: 1. Open http://software.hixie.ch/utilities/cgi/data/data 2. Click [Generate] button Actual Results: Page transitioned as follows: (Your browser should have redirected you automatically. If you see this it probably has a bug.) Generated data: URI link appears as <a> link Expected Results: Page transitioned and data UTI should be loaded as a actual web page

s/UTI/URI/

Move old M2's low-priority bugs to M6 milestone.

I had basically finished this patch by the time that I found bug 590682. That being said, I don't think we need to block redirects to data: URIs on such a generic mechanism. This patch is larger than I'd like because the HTTP redirect stuff basically assumes that we're going to need a channel in the parent as well as one in the child. data: is probably the only protocol that doesn't need this (and redirects to data: are probably quite rare), so I don't think that adding a little more code here is a terrible thing. Jason, let me know if there's a better reviewer for this patch.

Comment on attachment 8580838 [details] [diff] [review] patch v1 I'm giving this review to honza.

Comment on attachment 8580838 [details] [diff] [review] patch v1 Review of attachment 8580838 [details] [diff] [review]: ----------------------------------------------------------------- LGTM, thanks! ::: netwerk/ipc/PNecko.ipdl @@ +78,5 @@ > SpeculativeConnect(URIParams uri); > HTMLDNSPrefetch(nsString hostname, uint16_t flags); > CancelHTMLDNSPrefetch(nsString hostname, uint16_t flags, nsresult reason); > + > + PDataChannel(uint32_t channelId); comment what the channelId is ::: netwerk/protocol/data/DataChannelParent.h @@ +19,5 @@ > +// to data:, we need to implement the HTTP redirection API, which requires a > +// class that implements nsIParentChannel, which calls NS_LinkRedirectChannels. > +// In addition, the HTTP code blindly calls NS_NewChannel on the redirected-to > +// URI, so we're guaranteed to create an nsDataChannel in the parent, as well as > +// in the child. You would need some IPC (at least placeholding) for data: anyway - even when we would create the target channel asynchronously on child (and let parent connect). The thing is that on the parent there are checks made on source+target channels whether to redirect or not. But these need to run on the content as well. So you need some mirroring here. @@ +39,5 @@ > + NS_IMETHOD OnDataAvailable(nsIRequest *aRequest, > + nsISupports *aContext, > + nsIInputStream *aInputStream, > + uint64_t aOffset, > + uint32_t aCount) MOZ_OVERRIDE MOZ_FINAL; why not use NS_DECL_NSIREQUESTOBSEVER and STREAMLISTENER?

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b130e931a8fa (with Honza's comments addressed)

QA Whiteboard: [bugday-20150624][good first verify][verified in Firefox 39.0 b7. Operating System - Windows 7 (64bit) only] Status: Resolved. Worked as expected.

I checked in latest Nightly Build ID 20150701030207, both in e10s and non-e10s . In both case the page is blank for me.

(In reply to Ashickur Rahman from comment #10) > Created attachment 8628738 [details] > Selection_003.png > > I checked in latest Nightly Build ID 20150701030207, both in e10s and > non-e10s . In both case the page is blank for me. Yes, because there is nothing to show for on the generated page.