Closed Bug 1058551 Opened 6 years ago Closed 5 years ago
[e10s] The data: URI kitchen web page does not work properly
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
Component: General → Document Navigation
Product: Firefox → Core
Assignee: nobody → mrbkap
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.
Attachment #8580838 - Flags: review?(jduell.mcbugs)
Comment on attachment 8580838 [details] [diff] [review] patch v1 I'm giving this review to honza.
Attachment #8580838 - Flags: review?(jduell.mcbugs) → review?(honzab.moz)
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?
Attachment #8580838 - Flags: review?(honzab.moz) → review+
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b130e931a8fa (with Honza's comments addressed)
QA Whiteboard: [good first verify][verify in Nightly only]
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.
You need to log in before you can comment on or make changes to this bug.