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)
Tracking
()
RESOLVED
DUPLICATE
of bug 313646
People
(Reporter: heinz_schweitzer, Assigned: smaug)
References
()
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.
Reporter | ||
Updated•15 years ago
|
Just wondering who told you to file this so I can CC them if possible.
Keywords: regressionwindow-wanted
Comment 2•15 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.
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.
Comment 5•15 years ago
|
||
Hu? That's not my test page. It was created by the bug reporter.
Comment 6•15 years ago
|
||
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
Assignee | ||
Comment 7•15 years ago
|
||
So is this a dup of Bug 313646?
Comment 8•15 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.
Assignee | ||
Comment 9•15 years ago
|
||
A *minimal* testcase would be very useful here. And also the regression range if this isn't a dup of bug 313646.
Comment 10•15 years ago
|
||
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•15 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 ?
Comment 12•15 years ago
|
||
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•15 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)
Comment 14•15 years ago
|
||
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•15 years ago
|
||
Ok I will try and create a minimum testcase, but give me a day ... or two.
Comment 16•15 years ago
|
||
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.
Comment 17•15 years ago
|
||
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
Updated•15 years ago
|
Flags: blocking1.9.2+
Target Milestone: mozilla1.9.2 → ---
Version: 1.9.1 Branch → Trunk
Updated•15 years ago
|
Keywords: regressionwindow-wanted
You need to log in
before you can comment on or make changes to this bug.
Description
•