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
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.
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.
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.
This regressed on 2007060504.
2007060504 -> Backbase site fails.
2007060405 -> Backbase works as it should.
I can repro this on minefield trunk nightly (M8). This works fine on 18.104.22.168. Can we get this fixed?
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; es-ES; rv:1.9a8pre) Gecko/2007091204 Minefield/3.0a8pre
Created attachment 280713 [details]
*** Bug 396113 has been marked as a duplicate of this bug. ***
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/ ).
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
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.
(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?
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.
Well, it only needs approval at this point. One review is sufficient for js/src.
Is this still an issue in current trunk build?
I can't reproduce anymore. Marking fixed as a result of bug 383682.
Fixed on the branch in bug 382509.
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 22.214.171.124 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.