Closed Bug 503061 Opened 15 years ago Closed 15 years ago

AJAX app is not working correct when async is false

Categories

(Core :: XML, defect, P2)

Product:
Core
Component:
XML
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 313646

People

(Reporter: heinz_schweitzer, Assigned: smaug)

References

(
URL
)

Details

(Keywords: compat, regression) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5

Under the URL given above you have a table where you can insert/delete/update
rows using XMLHttpRequests with the async flag set to false.
This leads to incorrect bahaviour as you will NOT see a succes message 
above the table, because the responsehandlers are not called.
When setting the async flag to true everything works as expected. 

This is working the correct way with Fx1.x up to Fx2.x and IE6 IE7 Safari4.0
and Chrome.

Reproducible: Always

Steps to Reproduce:
1.insert a row by pressing the 'i' button
2.
3.
Actual Results:  
a row is inserted but no success message

Expected Results:  
a row is inserted and a messag like "insert success <id>" is displayed above the table.

I have been told to file this as a regression bug.
Keywords: regression
OS: Windows Server 2003 → Windows XP
Version: unspecified → 3.5 Branch
Just wondering who told you to file this so I can CC them if possible.
Keywords: regressionwindow-wanted
Original thread:
http://forums.mozillazine.org/viewtopic.php?f=25&t=1337335

According to the mentioned W3C documents ( http://www.w3.org/TR/XMLHttpRequest/#send ) there is no condition for dispatching readystatechange if the request is synchronous. It can be interpreted that this event must dispatched even in synchronous mode.
Component: General → XML
Product: Firefox → Core
QA Contact: general → xml
Version: 3.5 Branch → 1.9.1 Branch
I can confirm the behavior as your described but don't understand the code so a dev will need to look into this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.2?
Volkmar, not sure if this is related or not but deleting rows doesn't work on your test page.
Hu? That's not my test page. It was created by the bug reporter.
Olli, can you have a look at this regression? If it's not something you're familiar with just let me know and I'll find someone else.
Assignee: nobody → Olli.Pettay
Flags: blocking1.9.2? → blocking1.9.2+
Keywords: compat
Priority: -- → P2
Target Milestone: --- → mozilla1.9.2
So is this a dup of Bug 313646?
Yes and no. According to the OP it worked in Firefox 2 but not in Firefox 3. (see the mentioned mozillazine thread)
If this is correct then bug 313646 was fixed eventually but now it regressed.
A *minimal* testcase would be very useful here.
And also the regression range if this isn't a dup of bug 313646.
I just tested and found the same behavior in all of FF 3.5, 3.0, 2.0, 1.5, and 1.0 on Windows XP, so I'm tempted to say that this is a dup of bug 313646.

Heinz, it would be helpful if you could test the page you gave us in Firefox 2 and see how it behaves for you.  You can download FF2 from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0.0.20-candidates/build1/
Justin, it is working perfect with FF 2.0.0.20
It is not working with any version of FF 3.x
Is there anything else I can do ?
I just tested again with FF 2.0.0.20 on Windows XP.  I loaded the page, clicked one of the "i" buttons, and did not see a "insert success" message like I do when I use Chrome.  I've put up screenshots of this process at http://people.mozilla.org/~jlebar/bugs/bug503061.htm

Am I doing something wrong?
???????
I am using this one and it works for me:

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729)
Heinz, I'm really not sure what's going on here.

I suspect that if we fix bug 313646, your problem will go away, but it's possible that yours is a different bug.  One way we could know that yours is a different issue is by fixing 313646 and observing that your problem isn't solved.  Alternatively, if you could create a smaller testcase for this problem, we might be able to inspect the test case and see that it's different from the testcase in bug 313646.

In the meantime, I'm going to try your testcase on a few other machines, and I'm going to see if I can kill two birds with one stone by fixing that other bug.
Ok I will try and create a minimum testcase, 
but give me a day ... or two.
You might want to wait a bit on that testcase.  I have a patch for bug 313646 which, at least on my system, appears to make your site work correctly.  I'm going to upload it in a few minutes.

I still don't know why we get different behavior on FF2, but maybe that's not important at this point.
Since I can't verify that this bug has a different regression range than bug 313646, and since the patch I just uploaded to that bug fixes the OP's testcase here, I'm going to mark this as a dup.

If the fix we end up checking in for bug 313646 doesn't fix this testcase, then we can dedup this one.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Flags: blocking1.9.2+
Target Milestone: mozilla1.9.2 → ---
Version: 1.9.1 Branch → Trunk
You need to log in before you can comment on or make changes to this bug.