Closed Bug 661604 Opened 9 years ago Closed 4 years ago

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

Categories

(Core :: Networking: HTTP, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
e10s + ---
firefox9 - ---
firefox42 --- fixed

People

(Reporter: jdm, Assigned: mrbkap)

References

(Blocks 3 open bugs)

Details

(Keywords: mobile)

Attachments

(1 file)

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.
It's this entry from |origins|:

{ origin: 'null',
     file: 'http://example.org/tests/content/base/test/file_CrossSiteXHR_inner_data.sjs'
},
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...
See Also: → 590682
Blocks: 676653
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 .
So I guess that's also the reason why http://tinyurl.com/yzsu9go doesn't redirect to the data url in Fennec, right?
Keywords: mobile
Blocks: 682949
Martijn - Can you give more information for why this bug should be tracked?
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.
Drivers decided this is not tracking.
Blocks: fxe10s
Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".
tracking-e10s: --- → +
For the record wchen rs'd the patch in person.
https://hg.mozilla.org/mozilla-central/rev/709ecb70dc99
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.