[e10s] The data: URI kitchen web page does not work properly

VERIFIED FIXED in Firefox 39

Status

()

defect
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: alice0775, Assigned: mrbkap)

Tracking

Trunk
mozilla39
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10sm6+, firefox39 fixed)

Details

Attachments

(2 attachments)

Reporter

Description

5 years ago
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

5 years ago
Component: General → Document Navigation
Product: Firefox → Core
Reporter

Comment 1

5 years ago
s/UTI/URI/
Assignee: nobody → mrbkap
Blocks: old-e10s-m2
Move old M2's low-priority bugs to M6 milestone.
Posted patch patch v1Splinter Review
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

4 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 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://hg.mozilla.org/mozilla-central/rev/6fb980e58948
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
QA Whiteboard: [good first verify][verify in Nightly only]

Comment 9

4 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.
Status: RESOLVED → VERIFIED

Comment 10

4 years ago
Posted image 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.
(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.