User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release) Build ID: 20140416030202 Steps to reproduce: Select "File > New e10s Window". In the new window open https://www.icloud.com/ and input your account data to log in. Actual results: I get an error popup (see attached image). Expected results: The login should work.

I don't have access to MacOSX 10.9 and that's a basic requirement for iCloud. Florin, could one of your team take a look? Thanks!

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0 I was able to reproduce this issue using latest Nightly, build ID: 20140422030204 on Mac OS X 10.9.2. Right after the log in I've encountered the mentioned error. This does not reproduce using normal window. Please let me know if I can provide further assistance regarding this matter.

Thanks Cornel! We should probably look for a regression window and check if this is true for 32 and 33 as well.

The issue reproduces on Nightly 32 and 33 (latest) too. It also can be seen back to Nightly 26 2013-09-15 where the pref browser.remote.tabs must be manually modified in order to have new e10s windows, so it's not a regression.

Petruta: can you still reproduce this icloud.com bug?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:34.0) Gecko/20100101 Firefox/34.0 The issue still reproduces under Mac OSX 10.9.4 on latest Nightly 34.0a1 20140724030201 in e10s windows.

Interesting - one of the requests that the web client makes to icloud.com (specifically, one to https://p17-contactsws.icloud.com/co/mecard/), returns a lot of garbage when using an e10s tab. It returns propery JSON when using a non-e10s tab. The data it's retrieving isn't private to me, so here's a screenshot of the response from the server. It returns a proper HTTP response code, and the headers seem fine, but the response body is just a mess. The front-end client flips out when it hits that stuff, and shows the error. So something is, I believe, getting garbled in Necko. jduell, is this likely to be in the same neighbourhood as bug 1036433, or is this something new?

Smells like either bug 1043256--the data is probably getting decrypted twice under e10s. Is this a chunked HTTP response? (a wireshark or HTTP log would be helpful if someone's got time: or we can just see if this goes away when we fix bug 1043256)

(In reply to Jason Duell (:jduell) from comment #8) > Smells like either bug 1043256--the data is probably getting decrypted twice > under e10s. Is this a chunked HTTP response? The Transfer-Encoding header for the response says "chunked" - is that enough to assume that it's actually a chunked HTTP response, or should I look closer?

Yup, that's chunked. This looks like bug 1043256.

Works in today's nightly. Thank you!