Closed Bug 834357 Opened 12 years ago Closed 12 years ago

ajax mini cart function does not work properly on certain site since Firefox 18.0

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
18 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox18 - wontfix
firefox19 - ---
firefox20 - ---
firefox21 - ---
firefox-esr17 --- unaffected

People

(Reporter: jdm, Assigned: mcmanus)

References

(
URL
)

Details

(Keywords: qawanted, regression)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 Build ID: 20121128204232 Steps to reproduce: I run a website and your newest version 18.0.1 in which was installed on most of my systems today has caused our add to cart function to cease to work. I have tested it and made use that it was in fact the update. I have uninstalled 18 and installed 17. 17 does not have this issue. Also, IE, Chrome and Safari do not have this bug. We need a fix asap! We are a large automotive website and this will hurt sales with the 15% of our customers who use your browser with your website. I am a big fan of your browser. Actual results: The add to cart function does not function. You may try it with this page: http://www.dieselpowerproducts.com/p-7453-vis-racing-carbon-fiber-oem-hood-2002-09-dodge-ram.aspx It is site wide and on all 4 of our websites. 17 has no problems and I have never seen this problem in the past. Expected results: the product should easily be added to cart. We use ajax for our mini cart function.
URL: http://www.dieselpowerproducts.com/
Severity: normal → critical
This is not a security bug. It would be very helpful if you could help us identify the problem by finding the regression range in our nightly builds where this first appeared.
Group: core-security
Keywords: regression, regressionwindow-wanted
I never set it as a security bug. It is just a very big bug. If you can send me a list of nightly executable, i can install each one and test them against the site. I know that 17.0.1 had no problems and the newest version which is updating automatically like a virus on computers in the US has the bug.
I just checked analytic and over 25% of our firefox users have installed version 18. We need a solution and fast!
Right now we are thinking the bug could be related to the new javascript compiler that is included in 18, but we do not know yet.
Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/c66a8c55e6dd Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120914131502 Bad: http://hg.mozilla.org/mozilla-central/rev/9fff2012b66c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120914181001 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c66a8c55e6dd&tochange=9fff2012b66c Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/19d45bb5e12c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120914132502 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/6d71ff5b4b36 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120914135001 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=19d45bb5e12c&tochange=6d71ff5b4b36 In local build: Last Good: ece7fb2526fb First Bad: 828f91de7143 Triggered by: 828f91de7143 Patrick McManus — bug 769764 move proxy resolution to separate thread and remove sync api r=biesi sr=josh
Blocks: 769764
Status: UNCONFIRMED → NEW
status-firefox18: --- → affected
status-firefox-esr17: --- → unaffected
tracking-firefox19: --- → ?
tracking-firefox20: --- → ?
tracking-firefox21: --- → ?
Component: Untriaged → General
Ever confirmed: true
Keywords: regressionwindow-wanted
Product: Firefox → Core
Component: General → Networking
I did test 19.0.b1 and it was affected in that version.
ah, the offending patch of bug 769764 was backed out once and was landed again as follows. Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/c7b8d71aa25d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120927095854 Bad: http://hg.mozilla.org/mozilla-central/rev/2d96ee8d9dd4 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120927200536 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c7b8d71aa25d&tochange=2d96ee8d9dd4 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/c5a7b7544f12 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120927094355 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/0129800fa8a1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120927103456 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c5a7b7544f12&tochange=0129800fa8a1 Suspected: dcae72a1333c Patrick McManus — bug 769764 move proxy resolution to separate thread and remove sync api r=biesi sr=josh
tracking-firefox18: --- → ?
Summary: Conflict with 18.0.1 and 19.0.b1 → ajax mini cart function does not work properly on certain site since Firefox 18.0
We were unable to wait for a firefox fix, so we have resolved it on our site. We have a message on our site mentioning to press ctrl + f5 until the cookies are reset in 6 days. Thanks for the time you guys have put into this. I hope firefox resolves this for other websites. The problem was related to the postback when a customer pressed add to cart. With firefox it has always done a postback. With the update, the post back lost the customers add to cart function.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Patrick, can you please help with investigation here as bug 769764 is suspected here ? Also adding qawanted here to help check if it is reproducible on windows . I tried steps in comment 0 on Mac OSx 10.8.2 and was able to get the expected result.
Assignee: nobody → mcmanus
Status: RESOLVED → REOPENED
Keywords: qawanted
QA Contact: jbecerra
Resolution: WORKSFORME → ---
(In reply to bhavana bajaj [:bajaj] from comment #9) > Patrick, can you please help with investigation here as bug 769764 is > suspected here ? > Also adding qawanted here to help check if it is reproducible on windows . > > I tried steps in comment 0 on Mac OSx 10.8.2 and was able to get the > expected result. Hi Bhavana, As i mentioned in comment 8, we fixed the bug ourselves. It was hurting sales quite a bit, so we were unable to wait for firefox to get around to fixing it. No one will be able to replicate the problem now. I have set the status to resolved.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WORKSFORME
I am not able to reproduce this, but they fixed it on their end. I am going to ask the reporter if they have a development or staging server where we can try to check it.
(In reply to jdm from comment #10) > (In reply to bhavana bajaj [:bajaj] from comment #9) > > Patrick, can you please help with investigation here as bug 769764 is > > suspected here ? > > Also adding qawanted here to help check if it is reproducible on windows . > > > > I tried steps in comment 0 on Mac OSx 10.8.2 and was able to get the > > expected result. > > Hi Bhavana, > As i mentioned in comment 8, we fixed the bug ourselves. It was hurting > sales quite a bit, so we were unable to wait for firefox to get around to > fixing it. No one will be able to replicate the problem now. I have set the > status to resolved. We thought that you fixed it with a workaround asking the user to refresh the page (as you noted in comment 8). If you don't have a reduced test case or reproduce case for us to test, we won't be able to fix in-product and WFM is a fine resolution.
s/reproduce/reproducible/
(In reply to juan becerra [:juanb] from comment #11) > I am not able to reproduce this, but they fixed it on their end. I am going > to ask the reporter if they have a development or staging server where we > can try to check it. I am sorry, but we fixed it on our development server first. The problem was: Using Ajax, we were making an asynchronous request with a post back. Essentially what was happening was that the post back was voiding the asynchronous request. Each time the asynchronous request was being made, the post back was killing it. We spent yesterday and thusmorning working on it and fixed it on our dev site first, then we fixed it on our live server.
(In reply to Alex Keybl [:akeybl] from comment #12) > (In reply to jdm from comment #10) > > (In reply to bhavana bajaj [:bajaj] from comment #9) > > > Patrick, can you please help with investigation here as bug 769764 is > > > suspected here ? > > > Also adding qawanted here to help check if it is reproducible on windows . > > > > > > I tried steps in comment 0 on Mac OSx 10.8.2 and was able to get the > > > expected result. > > > > Hi Bhavana, > > As i mentioned in comment 8, we fixed the bug ourselves. It was hurting > > sales quite a bit, so we were unable to wait for firefox to get around to > > fixing it. No one will be able to replicate the problem now. I have set the > > status to resolved. > > We thought that you fixed it with a workaround asking the user to refresh > the page (as you noted in comment 8). If you don't have a reduced test case > or reproduce case for us to test, we won't be able to fix in-product and WFM > is a fine resolution. We corrected the bug inside our site so there is no longer a post back to load the shopping cart. This resolved it. The purpose of the cntl +f5 is because we edited the javascript and it requires a full refresh to load the new js.
Patrick - please renominate for tracking if you're able to come up with a testcase and think this may affect a number of sites.
tracking-firefox19: ? → -
tracking-firefox20: ? → -
tracking-firefox21: ? → -
You need to log in before you can comment on or make changes to this bug.