452226 - xmlhttprequest sync call releases pressed button before response gets back

Status: RESOLVED DUPLICATE of bug 333198

(Core :: DOM: Core & HTML, defect)

Description

[Ernesto Fischer]

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.

Comment 1

[Jorge]

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

[Drew Thoams]

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)

Comment 3

[Jorge]

(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

[Drew Thoams]

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

[Grigory Danileyko]

There is an option to those who wants to speed up it, asynchronous mode - the third argument in xmlhttp.open(...).

Comment 6

[Ernesto Fischer]

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.

Comment 7

[sosoba]

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

[Mike Beltzner [:beltzner, not reading bugmail]]

--> Core::DOM, though comment 7 indicates it might be Core::JavaScript Engine

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Confirming (due to testcase) and carrying over blocking flag.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

[Johnny Stenback (:jst)]

Duping. Someone please verify.