AJAX app is not working correct when async is false

RESOLVED DUPLICATE of bug 313646

Status

()

Core
XML
P2
major
RESOLVED DUPLICATE of bug 313646
9 years ago
8 years ago

People

(Reporter: Heinz Schweitzer, Assigned: smaug)

Tracking

({compat, regression})

Trunk
x86
Windows XP
compat, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

Updated

9 years ago
Keywords: regression
OS: Windows Server 2003 → Windows XP
Version: unspecified → 3.5 Branch

Comment 1

9 years ago
Just wondering who told you to file this so I can CC them if possible.
Keywords: regressionwindow-wanted

Comment 2

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

Updated

9 years ago
Component: General → XML
Product: Firefox → Core
QA Contact: general → xml
Version: 3.5 Branch → 1.9.1 Branch

Comment 3

8 years ago
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?

Comment 4

8 years ago
Volkmar, not sure if this is related or not but deleting rows doesn't work on your test page.

Comment 5

8 years ago
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?

Comment 8

8 years ago
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/
(Reporter)

Comment 11

8 years ago
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?
(Reporter)

Comment 13

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

Comment 15

8 years ago
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
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 313646

Updated

8 years ago
Flags: blocking1.9.2+
Target Milestone: mozilla1.9.2 → ---
Version: 1.9.1 Branch → Trunk
Keywords: regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.