AJAX site does not work properly, works in IE

RESOLVED FIXED

Status

()

Core
General
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: ashughes, Assigned: mrbkap)

Tracking

({fixed1.8.1.13, regression})

Trunk
x86
All
fixed1.8.1.13, regression
Points:
---
Bug Flags:
blocking1.9 ?
blocking1.8.1.13 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed by 383682, URL)

Attachments

(1 attachment)

This bug is from the following litmus test case: http://litmus.mozilla.org/show_test.cgi?id=4408
It occurs using GPa7rc1 on all platforms but works using FF2006 and IE7.

The problem is that navigating to the site, the application loads but the "application loading" dialog does not disappear.  You can click on flights, and it will add the total, but the flights do not move from the flight list to the shopping cart.

Steps to reproduce:
1. Navigate to provided url
2. Wait for all content to be displayed
3. Click on a "select" link

Actual results:
The "application loading" dialog remains on the screen and the cost of the selected flight is added to the total.  The flight is not removed from the available flights list, nor is it added to the shopping cart.

Expected results:
The "application loading" dialog should disappear after the application is loaded and flights should be moved from the available flights list to the shopping cart when selected.

This appears to be a regression.  I will work on finding a regression window as soon as testday is over, unless someone else wants to take this on.

Comment 1

10 years ago
I really hate testcases like this because a) site can change and b) this failing is not necessarily an indication that XMLHTTPRequest isn't working properly.
Component: General → General
Keywords: regression
Product: Firefox → Core
QA Contact: general → general
This regressed on 2007060504.

2007060504 -> Backbase site fails.
2007060405 -> Backbase works as it should.
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2007-06-04+04%3A00&maxdate=2007-06-05+05%3A00

Comment 4

10 years ago
I can repro this on minefield trunk nightly (M8).  This works fine on 2.0.0.6.  Can we get this fixed?

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; es-ES; rv:1.9a8pre) Gecko/2007091204 Minefield/3.0a8pre

Screenshot attached.
Flags: blocking1.9?

Comment 5

10 years ago
Created attachment 280713 [details]
Backbase screenshot

Updated

10 years ago
Duplicate of this bug: 396113
This might very well be a regression of bug 382509 (I think it's likely)
I saw this line in this.eval(a$); in the bpc_02.js file (wrapped in a try..catch block, so no errors are caught) (this is from http://devnet.backbase.com/demos/pim/ ).
Blocks: 382509
ispiked: I am all ears if you have suggestions on a better way to test this. Right now this is all we have from a manual test case standpoint.

(In reply to comment #1)
> I really hate testcases like this because a) site can change and b) this
> failing is not necessarily an indication that XMLHTTPRequest isn't working
> properly.
> 

Flags: in-testsuite?
Well, the site in question uses all kinds of code, so by visiting that site and comparing the behavior on branch, you're a lot.
So I think it's useful to test these sites full of javascript stuff, only disadvantage is that it's hard to deduce what has regressed when something has stopped working. 
(In reply to comment #8)
> ispiked: I am all ears if you have suggestions on a better way to test this.
> Right now this is all we have from a manual test case standpoint.
> 
> (In reply to comment #1)
> > I really hate testcases like this because a) site can change and b) this
> > failing is not necessarily an indication that XMLHTTPRequest isn't working
> > properly.
> > 
> 

Perhaps we can create a staging area for our own test cases based on these sites that we use for test cases currently.  On the other hand, but using real world sites, it gives us real world results.  Perhaps this should be discussed at the next QA Execution meeting?
(Assignee)

Comment 11

10 years ago
The patch in bug 383682 fixes this for me.
(In reply to comment #11)
> The patch in bug 383682 fixes this for me.
> 

I am assuming that this patch will go into tonights nightly.  If this is the case, I will check if this is fixed tomorrow.
(In reply to comment #12)
> I am assuming that this patch will go into tonights nightly.  If this is the
> case, I will check if this is fixed tomorrow.

Still needs review and approval1.9 first before mrbkap can check-in the fix. Maybe brendan can get to it soon.
(Assignee)

Comment 14

10 years ago
Well, it only needs approval at this point. One review is sufficient for js/src.
Is this still an issue in current trunk build?
(Assignee)

Comment 16

10 years ago
I can't reproduce anymore. Marking fixed as a result of bug 383682.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Flags: blocking1.8.1.13+
Whiteboard: fixed by 383682
Assignee: nobody → mrbkap
Fixed on the branch in bug 382509.
Keywords: fixed1.8.1.13
The original test site doesn't exist anymore (it redirects to the root site). I see no issues on http://devnet.backbase.com/demos/pim/ with 2.0.0.12 so I can't reproduce the original bug.
The original URL was extracted from the litmus test cases.  If this site no longer exists and we have a new URL to test from, the testcase should be updated to reflect this.
A new url is what I'm seeking. I don't understand the bug since the title is pretty vague.
Read the original description; it is much more descriptive.  Feel free to update the summary if you can find a better wording.  
Yes, I read the description. That isn't the point. Without a site to repro the issue, it doesn't matter what the title says. We're not going to be able to verify that it is fixed since the root issue was never nailed down in any of the discussion here and it was fixed by the checkin for another bug.
You need to log in before you can comment on or make changes to this bug.