If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

get intermittent and bogus error message when executing an async callback

RESOLVED INVALID

Status

()

Core
XML
P2
normal
RESOLVED INVALID
9 years ago
9 years ago

People

(Reporter: kjullion, Assigned: sicking)

Tracking

({regression})

Trunk
mozilla1.9.1
x86
Windows XP
regression
Points:
---
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)

Going to the URL provided (you will have to accept a self signed certificate as an exception) the steps are on the provided aspx page.  In essence about 5% of the time when you edit data in the provided textbox and then click the provided link you get an alert which states "The server method '<MethodName>' failed."  The problem is I don't get this message ever with MSIE or with Safari.  It first became known to me about the time of FF3.0.0  

What is happening is that when the LostFocus (onBlur) event fires for the Textbox then I'm updating a backend database using an AJAX callback which executes an ASP.NET webservice.  The code works fine, as I mentioned, about 95% of the time, and even when the alert does come up the callback has completed and the backend database is correctly changed.  I am unable to find a way to debug this, as the clicking of the link means that the current page's context is lost and so debugging is very difficult.  

I created this simplistic sample as an example of an actual realworld project in which I've been trying to solve this for quite a while now.

Reproducible: Sometimes

Steps to Reproduce:
1. enter some text in the textbox
2. click the link above the textbox, the link is a href to the current page
3. 19 times out of 20 you will see the page repaint and no error is reported and the database is updated.  
4. about 1 time out of 20 a message/alert appears, even though the underlying database is correctly updated by the webservice.
Actual Results:  
Actual results are the same as expected results in that the database update is occuring as it is supposed to, the only problem is that once in a while the user sees a bogus alert message

Expected Results:  
no alert/message box prompt is what I would expect to see.
(Reporter)

Comment 1

9 years ago
Turns out the frequency of this alert error is MUCH greater, probably about 18 times out of 20 (or 90%) with the server that I've hosted this sample on.  In my local dev environment the frequency of the alert error is more like 5%.
I get a server error.

Server Error in '/TestKevin' Application.
Unspecified error
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Data.OleDb.OleDbException: Unspecified error
(Reporter)

Comment 3

9 years ago
Hi,
I just tried the https://74.236.32.6:447/TestKevin/FF3-Error.aspx test page at 3:35pm on 3/3/2009 and it worked fine for me.  It's just a sample, so try putting in a small amount of text (less than 30 characters of text).   Otherwise if you are continuing to get this error perhaps we are using different environments; mine is FF 3.0.6 with NoScript add-on version 1.9.0.6.

I should add the frequency of the error I'm seeing is actually much greater than 1 on 20.  It's more like half the time.
In order to determine what patch caused the bug I had to run tens of builds doing requests, although for only 3 letter words.
Assuming it fails 100% of the time, this would be the regression range:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-01-20+12%3A00&maxdate=2006-01-20+22%3A00
If this is correct it could be caused by Bug 323908 or Bug 304980 I guess.
Status: UNCONFIRMED → NEW
Component: General → XML
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
QA Contact: general → xml
Version: unspecified → Trunk
Flags: wanted1.9.2?
Flags: blocking1.9.1?
Flags: wanted1.9.2? → blocking1.9.2?

Updated

9 years ago
Assignee: nobody → jonas
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1
Wow, thanks Ria. Thanks to your detective work this was trivial to investigate.

This was caused by bug 304980. I'll investigate how IE behaves and see what makes sense to do.
Status: NEW → ASSIGNED
Depends on: 304980
Ok, so I think I know what is going on here:

1. User types text into textbox
2. User clicks link
3. Clicking the link unfocuses the textbox which fires onblur
4. The onblur handler starts an XMLHttpRequest to the server
5. We keep processing the link click in step 2 which navigates away from the
   current page.
6. Navigating away from the current page cancels all network transactions,
   including the XHR one started in step 4.
7. Canceling the XHR fires the onreadystatechange handler which shows an alert
   which correctly says that the transaction has been canceled.

So the XMLHttpRequest posting *is* actually failing. The reason this didn't happen in firefox 2 was that our XHR implementation wasn't compatible with IEs, which meant that in step 7 the code didn't detect that the transaction had failed. Bug 304980 fixed that so that the code now properly detects the failure.


I'm surprised that this doesn't happen in IE. Maybe they don't cancel current XHR requests when the user leaves a page.

To fix this you could make add an onclick handler to the link that cancels the click if there's a database update in progress and then reclicks the link once the transaction is done.

In any case, we're behaving as expected here.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: blocking1.9.2?
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.