Closed
Bug 452226
Opened 16 years ago
Closed 15 years ago
xmlhttprequest sync call releases pressed button before response gets back
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 333198
People
(Reporter: efischer, Unassigned)
Details
(Keywords: testcase)
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; FDM) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 This problem has been introduced in FF 3, since it worked fine in previous FF versions. I have a page with a simple button element with an onClick event that calls a xmlhttprequest in sync mode. In earlier versions of FireFox, the button stayed pressed/locked until I got the response from the sync request, but now in FF 3 as soon as the "send" is executed the button gets released. If the request takes a bit longer to respond, it is possible to press the button more than once firing new requests for each click. This is a critical problem if the request does modify DB data. The page has this button definition: <input type="button" name="btn" value=" Run " onClick="execXML();"> And function execXML uses these lines to call the sync xmlhttprequest: xmlhttp.open("POST", url, false); xmlhttp.send(data); Reproducible: Always Steps to Reproduce: 1. 2. 3.
The problem is that synchronous XMLHttpRequests return inmediatly after the call to .open(null) even though they shouldn't return until the XHR has completed. This page : http://jorgechamorro.com/cljs/013/ shows the problem clearly : just press the "SYNC" button in order to post a synchronous XHR. You should not be able to press the button again until after the previous XHR has ended, but you can... -- Jorge Chamorro.
Comment 2•16 years ago
|
||
I've noticed that in FF 3.0.1 the Sync XHR call does NOT block the user interface at all. Has anyone else noticed this? I'm wondering if there is a setting somewhere that I'm missing or if this was fixed in a greater version. (I'm stuck with the 3.0.1 build due to rules at work)
Reporter | ||
Updated•16 years ago
|
Severity: normal → critical
(In reply to comment #2) > I've noticed that in FF 3.0.1 the Sync XHR call does NOT block the user > interface at all. Has anyone else noticed this? Yes: http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/78a466cd5c112cea#c955519ad2e95ca6 -- Jorge
Comment 4•16 years ago
|
||
Good point Jorge, I noticed that thread, and a couple of others, shortly after posting. Another question, is this going to be the norm for browsers? Do we need to rewrite our web apps to deal with this? or is this a "problem" with the browser(s)? I'm concerned that this is becoming common browser behavior as they try to "speed up" javascript...
Comment 5•16 years ago
|
||
There is an option to those who wants to speed up it, asynchronous mode - the third argument in xmlhttp.open(...).
Reporter | ||
Comment 6•15 years ago
|
||
The problem is not about which is the best practice in communicating using xmlhttprequest. Xmlhttprequest specification defines two communication modes sync and async, but FireFox is not honouring the specification for sync requests. This is an old FireFox issue since early version 1 but has been "fixed" in older versions 1, probably as a side effect of some other bug fix because a lot of bugzillas reporting similar sync problems are still open since those early times and never were fixed. Now in FireFox 3, some code change, revived the bug again. I use a software that has a middleware inside web server that controls if a xmlhttprequests hangs around for more that N seconds (configurable) and then sends back to browser an alert and he can continue work. This middleware accesses directly a database for reads/updates and it relies on sync requests so that the client side programming gets incredible simple, no need to control if a request was done and set tens of flags and code to block buttons, fields, etc from user input. Resuming, if the specification has sync and async, FireFox should follow it and fix the sync problem. Other browsers (IE, Chrome/Safari, Opera) follow correctly the specification.
There is a simple code to try it: test.html: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/transitional.dtd"> <html> <head> <title>FF bug</title> <script type="text/javascript"> ajax = function() { var req = new XMLHttpRequest(); req.open( "POST", "wait.php", false ); console.log( 'Ajax non-synchronic send (2.1)' ); req.send( "" ); console.log( 'Ajax non-synchronic response (2.2)' ); } </script> </head> <body> <input type="button" value="Test (doubleclick)" onclick="ajax();" ondblclick="console.log( 'On ondblclick (3)' )" /> </body> </html> and wait.php: <?php sleep( 3 ); ?> FF 3.0 has a terrible bug. It seems like Javascript multithreading engine :)
Comment 8•15 years ago
|
||
--> Core::DOM, though comment 7 indicates it might be Core::JavaScript Engine
Component: General → DOM
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.5?
Product: Firefox → Core
QA Contact: general → general
Comment 9•15 years ago
|
||
Confirming (due to testcase) and carrying over blocking flag.
Comment 10•15 years ago
|
||
Isn't this just a duplicate of bug 333198? Please test in either a current trunk or current 1.9.1 branch build; both of those should have the bug fixed.
Comment 11•15 years ago
|
||
Duping. Someone please verify.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Updated•15 years ago
|
Flags: blocking1.9.2?
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•