661604 - test_CrossSiteXHR_origin.html times out cross-process || ASSERTION: Redirecting to a protocol that doesn't support universal protocol redirect

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Josh Matthews [:jdm]]

I haven't narrowed down precisely where in the test this occurs, because it's really complicated. However, we end up redirecting from an HTTP channel to a data: one that looks like this:

text/html,%3C%21DOCTYPE%20HTML%3E%0A%3Chtml%3E%0A%3Chead%3E%0A%3Cscript%3E%0Awindow.addEventListener%28%22message%22%2C%20function%28e%29%20%7B%0A%0A%20%20sendData%20%3D%20null%3B%0A%0A%20%20req%20%3D...

This obviously isn't hooked up the work cross-process, so it's opened in the parent and the test fails to make any further progress.

Comment 1

[Josh Matthews [:jdm]]

It's this entry from |origins|:

{ origin: 'null',
     file: 'http://example.org/tests/content/base/test/file_CrossSiteXHR_inner_data.sjs'
},

Comment 2

[Honza Bambas (:mayhemer)]

So, this redirects to a data: channel, right?

How is data: uri processed in Fennec?  AFAIK it is fully handled on the content process, right?

During redirects the problem is that we create the target channel on the chrome process and we also AsyncOpen it there.  On the child process we create a child implementation that (in case of http:) 'connects' with the parent real channel via the redirect channel id.

For data: we want something backwards.  We want the parent real channel be something empty that gets the data if needed, but actually doing nothing.  The work will be made by data channel (the 'real' implementation) on the content process.

We have a bug 590682 that handles opposite scenario: when a channel wants to be fully handled on the parent process and doesn't have a special implementation for the child process, we use a generic no-op channel wrapping the URI and forwarding events only.

For this to get fixed, we probably need some kind of a 'generic' channel for the parent side, so the exact opposite...

Comment 3

[Martijn Wargers (dead)]

Here is a testcase, that you can view online: http://www.kantjils.nl/moz/mochitestjs/body_onload_script_redirect.html

I made this testcase, because I looked into the mochitest timeouts in:
http://mxr.mozilla.org/mozilla-central/source/layout/style/test/test_visited_image_loading.html?force=1
and visited_image_loading_frame_empty.html .

Comment 4

[Martijn Wargers (dead)]

So I guess that's also the reason why http://tinyurl.com/yzsu9go doesn't redirect to the data url in Fennec, right?

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Martijn - Can you give more information for why this bug should be tracked?

Comment 6

[Martijn Wargers (dead)]

No specific information, but I just would like to see these ipc related bugs get fixed. But I guess this surely will be fixed once Firefox desktop gets e10s.

Comment 7

[[:Cww]]

Drivers decided this is not tracking.

Comment 8

[Chris Peterson [:cpeterson]]

Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

This was fixed by bug 1058551.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d83e49b39d3f

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Patch

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/709ecb70dc99

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

For the record wchen rs'd the patch in person.

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/709ecb70dc99