Open Bug 836270 Opened 12 years ago Updated 1 year ago

Auto refresh from payment gateway not working

Categories

(Core :: Networking: HTTP, defect, P3)

Product:
Core
Component:
Networking: HTTP
Version:
18 Branch
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: lorraine, Unassigned)

Details

(Whiteboard: [necko-backlog])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17 Steps to reproduce: Using Sagepay forms gateway, after the bank has authorised payment the browser should redirect to success page on my website. Version is 18.0.1 on Mac OS Mountain Lion 10.8.2 Actual results: It stays on the 'Authorising...' page unless I press refresh (apple-R). HOWEVER (important) this only happens when my site is hosted on LAMP. On MAMP (development server), it works fine. Expected results: It should have redirected straight to the success page. All other browsers (including Firefox on XP) work as expected, it is only 18.0.1 on the Mac with a website hosted on Apache/MYSQL that's failing like this as far as I can tell.
Component: Untriaged → Networking
Product: Firefox → Core
Lorraine, would you be able to check whether this happens in the current development version of Firefox as well? http://nightly.mozilla.org has download links.
Component: Networking → Networking: HTTP
Hi Just checked and yes it does happen on the nightly build. I can provide you with a test site if it would help, but you will need quite a few instructions from me to be able to use it (as it's a bank testing environment I have to give you the test credit card and address details, that kind of thing). Let me know anyway. It's a bit of a funny one, all the software developers and my hosting provider are just blaming my mac (or is that "blaming me"). Sagepay aren't too interested but they probably should be there are quite a few comments online about people having abandoned transactions and I suspect it may be that this is one of the causes - the natural thing to do is hit the back button, which records the transaction @sagepay but abandons it... Cheers Lorraine
Thanks for checking that. A productive first step to investigate this would be for you to snag a log of the problem: https://developer.mozilla.org/en-US/HTTP_Logging has instructions for how to do so.
It would also be good to snag a log of the development server so we can compare the behaviour of the problem case with the working one.
Hi there I have produced these and attached. One correction (apologies) - I was convinced this had worked normally on the development server, but it seems that I have the same problem there too. Which is probably easier for you as it's not a specific to hosting thing (which didn't make so much sense did it?) Anyway, I have run the test on both development and test, so you may as well have both logs: to clarify, the problem happened against both MAMP and LAMP. Cheers .
Sorry - files too big. Here are a couple of links instead: http://tiltingatwindmills.co.uk/development-server.txt http://tiltingatwindmills.co.uk/testing-server.txt
That's right. To get that redirection to actually occur I have to hit the cmd-r (refresh). If I hit back, it cancels the transaction. With other browsers (incl. Firefox on XP) the redirection happens 'automatically' if that makes sense?
Could you clarify whether you refreshed the page in the HTTP log you provided? It would be good to see a log in which the problem occurs and you don't take any further steps to correct it.
Yes I did - in both cases! Until I hit refresh the 'scrolling orange bar' that sagepay displays whilst getting a bank authorisation showed UNTIL I hit refresh... then the correct (confirmation screen) is shown. If I hit the back button at this time, it cancels the transaction (verifiable through the test account).
Ok, what would be very useful for debugging would be two logs: one would be a log of the failure case (just close Firefox after the authorization page sits there for ~10 seconds), and one would be a log of a successful run from an XP version of Firefox.
Okey doke here they are - backed out on mac after about 20 seconds, PC just does it without interference http:/tiltingatwindmills.co.uk/pc-log.txt http:/tiltingatwindmills.co.uk/mac-log.txt
Also, just to be thorough, can you try reproducing the problem with a blank profile? http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles explains how to create a new one. I want to rule out any network-related preferences that might have been changed.
Good shout Josh - the empty profile is the problem. I'm not aware of making any network relate preferences changes at all, I thought I was just using Mozilla 'out of the box', I don't normally dabble. I am so sorry if I have wasted your time. What kind of thing might I have changed so that I can check it out?
Should have said "empty profile solves the problem"
You could go to about:config, type "network" in the filter box and see if anything is bolded in the list that results.
Never seen that screen before. Just the one item is emboldened. network.cookie.prefsMigrated is set to true I have no idea what that means, I guess it means something to you?
Curious; there's no reason that should cause this. Perhaps try to reproduce with your regular profile in safe mode (http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode) to see if any add-ons are at fault.
This could be a problem where we're caching the redirect, but it somehow doesn't happen from the cache correctly. Lorraine, there are some steps that would be useful here: 1) Back up your profile (the one that is seeing the failure). I.e. copy the directory. Probably best to do this while the browser is closed. http://support.mozilla.org/en-US/kb/back-and-restore-information-firefox-profiles 2) Set up NSPR logging to also log HTTP cache: i.e. set NSPR_LOG_MODULES to NSPR_LOG_MODULES=nsHttp:5:cache:5 3) Run browser, and go to site. I assume you'll see the error again. If you do, close browser, post the NSPR log to this bug ("log of error with http cache logging"). 4) run again. But first clear your HTTP cache (Preferences | Advanced | Network | Clear Now). Now try page and see what happens. If it works, then it's likely that it's the cache that's the issue here. If it is the cache, then it might be useful to have your backed-up profile (which can have privacy issues, etc: but we can discuss if/when we determine it's actually a cache bug, and whether we can reproduce easily ourselves).
Hi there I followed the process all the way through but no luck I am afraid, the 'hang' was still there. I have both logs if you would like them though, the first can be found http://tiltingatwindmills.co.uk/cache-log.txt Cheers L.
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Priority: P1 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.