User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36 Steps to reproduce: After your most recent 44 update this site htpcguides.com is broken. Go to http://www.htpcguides.com and click the Raspberry Pi vs Banana Pi link, page opens and after a second it brings you straight back to the home page. The same thing happens if you search for something and click a search result, you are brought back to the home page. Does not happen in Chrome or Edge. Actual results: Goes to desired page but then immediately back again Expected results: Should have stayed on the Raspberry Pi page This does not happen in Chrome or Microsoft Edge
Hardware: Unspecified → x86_64
Update: this turns out to be an imcompatibility with rocketloader and firefox, again this issue does not occur with Edge or Chrome (at least on Windows).
I believe I've narrowed it down to gleam being the culprit mixed with rocket loader and firefox. When I change gleam to use defer instead of async, the strange behavior seems to stop. However, Chrome and Edge continue to be OK so this is still a bug as far as I can tell.
WFM, not a Firefox issue probably.
(In reply to Loic from comment #4) > WFM, not a Firefox issue probably. Definitely a firefox bug if you read all the comments. It ONLY happens in Firefox, have had it confirmed from other users. Will recommend users do not use Firefox until this is fixed.
What's Rocket Loader?
Ok, I see the issue with a fresh profile.
I tested with an old version (FF17) and the issue is here too. So issue on cloud provider probably.
If you want to test, all releases are here: http://ftp.mozilla.org/pub/firefox/releases/
It is easier for me to just tell the users to use a different browser. Only Firefox is affected (Ubuntu as well I tested, same bug). Chromium on Ubuntu works as expected. I can't see how this is not a Firefox bug with Rocket Loader.
You said it worked before FF44. I tested with FF17 (you can do it with every previous version if you want), same result, so not a bug introduced in FF44. It's probably an issue with your website config or your cloud that changed settings.
Yes it did work before FF44, it could have been a simultaneous update with CloudFlare Rocket Loader and FF44 that are incompatible together fortuitously at the same time. That said, it is unmistakebly an issue that involves only the Firefox browser and no others. It would be in Mozilla's interest to resolve this issue with CloudFlare. So I can change the bug to all versions of Firefox instead of just version 44 if you want to be more technically correct. Should I choose unspecified or trunk then so it gets the attention it needs to get fixed?
Do you have proof it's a bug in FF or you claim that in the wind?
I have proof, to reiterate: this ONLY happens in FIREFOX, it does not happen in ANY OTHER BROWSER. If you tested diligently you would see that. How much more proof do you need, I have already tested very thoroughly, have you? I tested the same exact scenario in Firefox, Edge and Chrome on both Microsoft Windows and Ubuntu 15.x. The problem only exists in Firefox, the logical conclusion is that it is a Firefox problem.
Component: Untriaged → Document Navigation
Product: Firefox → Core
Need a testcase here. (Unfortunately if FF has had the same behavior here forever, or at least since FF17, finding the regression range wouldn't help.) Reporter, do you have any hints which code is being handled differently? Since right now the page seems to work fine in FF44. (It is for example very much possible that Firefox follows the current HTML spec here, but the wordpress plugin relies on the behavior of Chrome and Edge. In which case it is possible that the spec and Firefox implementation needs to be changed. Or that Firefox doesn't follow the spec, but other browsers do.)
3 years ago
(In reply to Olli Pettay [:smaug] from comment #17) > (Unfortunately if FF has had the same behavior here forever, or at least > since FF17, finding the regression range wouldn't help.) That wasn't quite right. regression range is _always_ useful. But the more recent, the better.
I'm seeing a couple of similar reports on SUMO: https://support.mozilla.org/en-US/questions/1107197 https://support.mozilla.org/en-US/questions/1107306 https://support.mozilla.org/en-US/questions/1107186
Keywords: regression, regressionwindow-wanted
Reproducible: always reproduce with clean profile and safemode. Steps to reproduce: 1. Open about:home 2. Open http://www.salon.com/ or http://www.lifeadvancer.com/comfort-zone-reasons 3. Wait for few seconds Actual results: Jumps to previous page. i.e., about:home. And also notice that back button disabled and foreword button is enabled. Further, clicking foreword button does same. Expected results: Should have stayed on the page This is not a recent bug. At least I can reproduce Firefox4.0
Status: UNCONFIRMED → NEW
status-firefox44: --- → wontfix
status-firefox45: --- → affected
status-firefox46: --- → affected
status-firefox47: --- → affected
status-firefox-esr38: --- → wontfix
status-firefox-esr45: --- → ?
Ever confirmed: true
Keywords: regressionwindow-wanted → reproducible
Another example: http://www.seeyar.fr/ Click on an article of this blog (like http://www.seeyar.fr/supprimer-la-suggestion-dans-la-barre-dadresse-de-lexplorateur-de-fichier/) and after 2-3 sec, Firefox brings you back to the homepage.
Loic, is that some recent regression?
I don't think so, I just tried with the old FF17, the issue is reproducible but just one time (per link). If I click again on the article, Firefox doesn't go back to the homepage a 2nd time. With FF44, every time I click on the same article, I go back to the homepage, it's clearly more prominent with the current release.
Hello, I saw this issue since 2 weeks, 2 things: 1. All Internet browser work only firefox (v44 and v43 too...) 2. When Rocket cloudflare is off, this fix issue. Conclusion: incompatybility between rocket loader and firefox. Conclusion? :D
We need a reduced testcase to narrow down the uderlying regression. Could you provide a minimal webpage showing the issue?
So there are several related bugs filed. At least in some cases this seems to be a change in Google ads to call history.go(-1) See https://bugzilla.mozilla.org/show_bug.cgi?id=1244560#c3 Or, perhaps there has been a change to Rocker Loader which isn't compatible with google ads?
But yes, I'd prefer any testcase using rocket loader (since so far I haven't managed to reproduce with that. Only with some page which happens to have google ads)
(In reply to Alice0775 White from comment #22) > 2. Open http://www.salon.com/ or > http://www.lifeadvancer.com/comfort-zone-reasons I can reproduce with lifeadvancer, and there it is ["http://pagead2.googlesyndication.com/pagead/js/r20160128/r20151006/show_ads_impl.js":197] which is calling history.go(-1); So the same issue as in bug 1244560 comment 3.
what are the next steps here Andrew?
We have reported an issue in Google Ads to Google. They are explicitly calling history.go(-1). dougt, do you still have some page where this is happening?
What smaug said.
Over in bug 1245042 it appears this is fixed. WORKSFORME because I don't know what we use for FIXEDBYTHIRDPARTY.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
status-firefox45: affected → unaffected
status-firefox46: affected → unaffected
status-firefox47: affected → unaffected
You need to log in before you can comment on or make changes to this bug.