480200 - get intermittent and bogus error message when executing an async callback

Status: RESOLVED INVALID

(Core :: XML, defect, P2)

Description

[kjullion]

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.

Comment 1

[kjullion]

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%.

Comment 2

[Ria Klaassen (not reading all bugmail)]

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

Comment 3

[kjullion]

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.

Comment 4

[Ria Klaassen (not reading all bugmail)]

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.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.