Closed
Bug 1058551
Opened 10 years ago
Closed 10 years ago
[e10s] The data: URI kitchen web page does not work properly
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
VERIFIED
FIXED
mozilla39
People
(Reporter: alice0775, Assigned: mrbkap)
References
Details
Attachments
(2 files)
20.38 KB,
patch
|
mayhemer
:
review+
|
Details | Diff | Splinter Review |
26.19 KB,
image/png
|
Details |
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
Reporter | ||
Updated•10 years ago
|
Component: General → Document Navigation
Product: Firefox → Core
Reporter | ||
Comment 1•10 years ago
|
||
s/UTI/URI/
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → mrbkap
Blocks: old-e10s-m2
Assignee | ||
Updated•10 years ago
|
Assignee | ||
Comment 3•10 years ago
|
||
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 4•10 years ago
|
||
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 5•10 years ago
|
||
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+
Assignee | ||
Comment 6•10 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b130e931a8fa (with Honza's comments addressed)
Assignee | ||
Comment 7•10 years ago
|
||
Comment 8•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
status-firefox39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Updated•9 years ago
|
QA Whiteboard: [good first verify][verify in Nightly only]
Comment 9•9 years ago
|
||
QA Whiteboard: [bugday-20150624][good first verify][verified in Firefox 39.0 b7. Operating System - Windows 7 (64bit) only]
Status: Resolved. Worked as expected.
Updated•9 years ago
|
Status: RESOLVED → VERIFIED
Comment 10•9 years ago
|
||
I checked in latest Nightly Build ID 20150701030207, both in e10s and non-e10s . In both case the page is blank for me.
Comment 11•9 years ago
|
||
(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.
Description
•