clicking link brings you to new page but then immediately back to previous page

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: blindpet, Unassigned)

Tracking

({regression, reproducible})

44 Branch
x86_64
All
regression, reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox44 wontfix, firefox45 unaffected, firefox46 unaffected, firefox47 unaffected, firefox-esr38 wontfix, firefox-esr45 ?)

Details

(Whiteboard: dom-triaged, URL)

(Reporter)

Description

3 years ago
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
(Reporter)

Updated

3 years ago
Hardware: Unspecified → x86_64
(Reporter)

Comment 1

3 years ago
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).
(Reporter)

Comment 2

3 years ago
To clarify CloudFlare makes Rocket Loader and it's a feature to enable the async loading of javascript files.
(Reporter)

Comment 3

3 years ago
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.

Comment 4

3 years ago
WFM, not a Firefox issue probably.
(Reporter)

Comment 5

3 years ago
(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.

Comment 6

3 years ago
What's Rocket Loader?

Comment 7

3 years ago
Ok, I see the issue with a fresh profile.
(Reporter)

Comment 8

3 years ago
I explained it above

'To clarify CloudFlare makes Rocket Loader and it's a feature to enable the async loading of javascript files.'

I have told CloudFlare about it as well so you can work with them to fix it.

This issue did not exist pre-update 44.

https://support.cloudflare.com/hc/en-us/articles/200168056-What-does-Rocket-Loader-do-

Comment 9

3 years ago
I tested with an old version (FF17) and the issue is here too.

So issue on cloud provider probably.

Comment 10

3 years ago
If you want to test, all releases are here: http://ftp.mozilla.org/pub/firefox/releases/
(Reporter)

Comment 11

3 years ago
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.

Comment 12

3 years ago
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.
(Reporter)

Comment 13

3 years ago
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?
(Reporter)

Updated

3 years ago
OS: Unspecified → All
Version: 44 Branch → unspecified
(Reporter)

Comment 14

3 years ago
OK an update, this had to do with a WordPress plugin that modifies a href links to open in a new window. Disabling the plugin resolves the issue. I have been told FF interprets javascript differently so will still consider this a FF bug.

Comment 15

3 years ago
Do you have proof it's a bug in FF or you claim that in the wind?
(Reporter)

Comment 16

3 years ago
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.)
Flags: needinfo?(blindpet)
Whiteboard: dom-noted
(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.

Updated

3 years ago
Blocks: 1244511

Updated

3 years ago
Duplicate of this bug: 1244511

Comment 22

3 years ago
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
(Reporter)

Comment 23

3 years ago
(In reply to Olli Pettay [:smaug] from comment #17)
> 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.)

My apologies, I've gone nuts trying to resolve this. It was not the a href rewrite plugin like I thought. It is Firefox and Rocket Loader together which must have something to do with javascript since Rocket Loader loads javascript separately. I have disabled it on my production site but you can see the behavior on the dev site http://www.htpcguides.casa for testing.
Flags: needinfo?(blindpet)

Updated

3 years ago
Blocks: 1244517

Comment 24

3 years ago
Regarding http://www.salon.com/, I found a regression range, and filed Bug 1244517
Duplicate of this bug: 1244560

Comment 26

3 years ago
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?

Comment 28

3 years ago
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.

Updated

3 years ago
Blocks: 1245042

Comment 29

3 years ago
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

Comment 30

3 years ago
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.

Comment 34

3 years ago
(In reply to blindpet from comment #8)
> I explained it above
Actually, I noticed the issue with FF43 and updated my machine to FF44 in the hopes of fixing it. 


> 'To clarify CloudFlare makes Rocket Loader and it's a feature to enable the
> async loading of javascript files.'
> 
> I have told CloudFlare about it as well so you can work with them to fix it.
> 
> This issue did not exist pre-update 44.
> 
> https://support.cloudflare.com/hc/en-us/articles/200168056-What-does-Rocket-
> Loader-do-
Whiteboard: dom-noted → dom-triaged
what are the next steps here Andrew?
Flags: needinfo?(overholt)
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?
Flags: needinfo?(dougt)
What smaug said.
Flags: needinfo?(overholt)
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
Flags: needinfo?(dougt)
Resolution: --- → WORKSFORME
status-firefox45: affected → unaffected
status-firefox46: affected → unaffected
status-firefox47: affected → unaffected
Version: unspecified → 44 Branch
You need to log in before you can comment on or make changes to this bug.