When mixed content blocking is enabled in WebKit, mixed content XMLHttpRequests just appear to stall - they forever remain in readyState 1, and don't get any final events. I suspect that they likely leak at some level too. Steps to reproduce: 1. Put any simple XMLHttpRequest test case into LayoutTests/tests/http that loads from http://127.0.0.1:8000 2. Run this command (it essentially runs the server for us, as run-webkit-httpd doesn't support https): run-webkit-tests LayoutTests/http/tests/xmlhttprequest/readystatechange.html --repeat 100000 3. Open your test using https, observe that the load stalls.
security/mixedContent/resources/insecure-xhr-in-main-frame-window.html will be one such test to run once i update it in bug 145718.
Note that the WIP mixed content spec strongly implies that we should fire the XHR's onerror event when we block it, but it doesn't actually tell us to do so: it seems to presume that we're *already* doing it [1]. I couldn't find a specification for that anywhere, but is seems like the Right Thing. I have a patch for this in bug #140793, but the patch is old and not completely right: it causes two mixed content warnings to be emitted for just one XHR. I think the spurious one is coming from the CachedResourceLoader. Unfortunately I don't plan to work on this more in the near future. [1] http://www.w3.org/TR/mixed-content/#websockets-integration
IIRC, Firefox raised an exception from send() in my testing.
I wonder if this was fixed by bug #146706. TODO: test it out! (In reply to comment #3) > IIRC, Firefox raised an exception from send() in my testing. To be clear: the candidate recommendation strongly implies we should fire onerror and not throw an exception: "These changes together mean that we’ll no longer throw a SecurityError exception directly upon constructing a WebSocket object, but will instead rely upon blocking the connection and triggering the fail the WebSocket connection algorithm, which developers can catch by hooking a WebSocket object’s onerror handler. This is consistent with the behavior of XMLHttpRequest, EventSource, and Fetch."
Created attachment 278532 [details] test While playing with HSTS, I came across this. We call the onreadystatechange with readyState == 1 then readyState == 4 and status 0, then call the onerror. Chrome and Firefox just call onreadystatechange with readyState == 1 then stop. I think our behavior is more correct, but I don't see it specified anywhere.
(In reply to comment #5) > Created attachment 278532 [details] > test > > While playing with HSTS, I came across this. We call the onreadystatechange > with readyState == 1 then readyState == 4 and status 0, then call the > onerror. This seems like desirable behavior, and it's still implied by the candidate recommendation (see comment #2) that's being developed by Chrome folks. Alex, I think this is a duplicate of bug #146706, which is now fixed; do you agree? > Chrome and Firefox just call onreadystatechange with readyState > == 1 then stop. I think our behavior is more correct, but I don't see it > specified anywhere. I guess this was our behavior prior to bug #146706. The old behavior broke YouTube for us with adblocker enabled; YouTube would wait for a horrible timeout before starting to play videos, because it thought the ad was still loading.
(In reply to comment #4) > I wonder if this was fixed by bug #146706. TODO: test it out! > > (In reply to comment #3) > > IIRC, Firefox raised an exception from send() in my testing. > > To be clear: the candidate recommendation strongly implies we should fire > onerror and not throw an exception: > > "These changes together mean that we’ll no longer throw a SecurityError > exception directly upon constructing a WebSocket object, but will instead > rely upon blocking the connection and triggering the fail the WebSocket > connection algorithm, which developers can catch by hooking a WebSocket > object’s onerror handler. This is consistent with the behavior of > XMLHttpRequest, EventSource, and Fetch." This is described in https://fetch.spec.whatwg.org/#main-fetch, xhr being based on fetch in xhr.spec.whatwg.org
I think this bug is a duplicate of bug #146706. *** This bug has been marked as a duplicate of bug 146706 ***