Closed
Bug 491571
Opened 16 years ago
Closed 16 years ago
Synchronous XMLHttpRequest send() allows concurrent browser events, breaks synchronism
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 333198
People
(Reporter: fernando.colombo, Unassigned)
Details
Attachments
(1 file)
|
1.02 KB,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.59 Safari/525.19
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.11pre) Gecko/2009050506 GranParadiso/3.0.11pre
After a synchronous XMLHttpRequest.send() is invoked and before it returns, FireFox may trigger mouse and keyboard events in the same script. While this can be seen as a performance improvement, it can break the logic of many pages that rely on synchronous and ordered processing of events.
I've also tested on Safari, Chrome, IE7 and IE8. This behavior is only found on FireFox. All others queue user events so they run only after the current event handler (blocking on send()) finishes properly. I think that if a page wishes to handle requests asynchronously, it should set the asynchronous flag to true in the open() method. Nevertheless, the browser should never execute an event handler before proper completion (by error or normally) of an ongoing event handler, as it causes multithread-like behavior that is difficult to handle, since most scripting languages does not support synchronization primitives such as monitors and critical sections.
Reproducible: Sometimes
Steps to Reproduce:
Deploy the following page on a JSP container, load in firefox, and start typing really fast on the edit-box. An alert message means the error has occurred.
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<%
if (request.getParameter("wait") != null) {
Thread.sleep(200);
}
%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Event while synchronous send</title>
</head>
<body>
<script type="text/javascript">
var sending = false;
function logEvent(evt) {
if (sending) {
alert("There's a bug in the electrical system!");
}
req = new XMLHttpRequest();
req.open("POST", "event-while-sync-send.jsp?wait=true", false);
req.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded");
sending = true;
req.send("yaba");
sending = false;
if (req.readyState != 4) {
alert("unexpected readyState: " + req.readyState);
return;
}
if (req.status != 200) {
alert("unexpected status: " + req.status);
return;
}
}
</script>
<form>
<p><input type="TEXT" onkeypress="logEvent(event)" />
</form>
</body>
</html>
Actual Results:
Please look "Steps to Reproduce".
Expected Results:
While a script event handler is blocked by a synchronous XMLHttpRequest, no event should be processed by the browser. No change should ever happen on that page, including controls. All events must be queued for further processing.
At least that's the behavior of IE7, IE8, Safari and Chrome.
|
||
Comment 1•16 years ago
|
||
This now fixed on Firefox 3.5. Because it's a large change it won't be applied on Firefox 3.0.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
|
Reporter | |
Comment 2•16 years ago
|
||
Deploy this test-case file on a JSP container, load it on FireFox, and then type really fast on the input box. An alert message indicates the bug has happened. Also, whatever you type must be displayed on input box, otherwise FireFox is eating key presses.
|
|
||
Comment 3•16 years ago
|
||
Yes, I can reproduce this issue on Firefox 3.0.10.
However, this issue is fixed in the next version of Firefox (3.5). It will be released soon, but you can already try the beta version (http://www.mozilla.com/en-US/firefox/all-beta.html) to see that the testcase is fixed there.
|
|
Reporter | |
Comment 4•16 years ago
|
||
I performed a test on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4.
The behavior is still different from Safari, Chrome, IE, etc. FireFox is
suppressing events, which may cause typographical errors (data loss?) on text
input and text areas. I think the correct behavior would be queueing such
events, so they can be processed after the event waiting on XHR send() has finished.
You need to log in
before you can comment on or make changes to this bug.
Description
•