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

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect)

Description

[Alice0775 White]

+++ This bug was initially created as a clone of Bug #1244326 +++

Reproducible: always reproduce with clean profile and safemode.

Steps to reproduce:
1. Open about:home
2. Open http://www.salon.com/
3. Wait for few seconds
4. Repeat from step 1 if need

Actual results:
Jumps to previous page. i.e., about:home.


Expected results:
Should have stayed on the page


Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fdcdc0dbc52c&tochange=e3e717e9b628

Suspect e3e717e9b628	Olli Pettay — Bug 855443 - Assertion failure in nsSHEntry.cpp, don't just append a new SHEntry to parent if we already have an SHEntry for the loading page, r=bz

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Alice, you're truly wonderful!
I'll look at this during the coming week.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

So far I haven't managed to reproduce this.
This could rely on whatever ads http://www.salon.com/ has, and those might be different for me.

Anyhow, does this require about:home as the initial page? Since if so, that would hint issues in
about:* handling in session history.

Comment 3

[Alice0775 White]

(In reply to Olli Pettay [:smaug] from comment #2)

> Anyhow, does this require about:home as the initial page? 

not only about:home but also any web page

Comment 4

[blindpet]

This is my exact issue https://bugzilla.mozilla.org/show_bug.cgi?id=1244326

Alice are you using CloudFlare's Rocket Loader by any chance?

Comment 5

[Alice0775 White]

(In reply to blindpet from comment #4)
> This is my exact issue https://bugzilla.mozilla.org/show_bug.cgi?id=1244326
> 
> Alice are you using CloudFlare's Rocket Loader by any chance?

No.

Comment 7

[Alice0775 White]

I can reproduce the problem when open http://smith-wessonforum.com/forum.php
see Bug 1244560

Comment 8

[Loic]

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.

Comment 9

[Alice0775 White]

(In reply to Loic from comment #8)
> 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.

This is a another bug. because regression range is different.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

So Bug 855443 made us work correctly in a certain case, so I guess just by accident this particular issue doesn't happen in builds before that (because we weren't creating correct session history before the fix). And it is also so old regression, so my guess is that this is still the same issue as with 
Bug 1244560. Trying to find good contacts to Google AdSense team.

Comment 11

[arni2033]

Attachment: bug 1244517 - irrelevant testcase.zip

Could somebody please explain to me, why is this bug so important since frames history wasn't thought through and is kind of broken by-design? In this attachment, both frames do completely legitimate things, and the page gives the same result as the site in comment 0 (even before bug 855443)

STR:
1. Save "irrelevant testcase" and extract all files in one folder
2. Open http://example.com/ in a new tab
3. Drag file "testcase - frames history.html" to the tab from Step 2
4. Wait 2 seconds

AR:  http://example.com/ is loaded in that tab instead of "testcase - frames history.html"
ER:  No history jumps

I'm pretty sure this scenario is supposed to be wrong by Mozilla, but what's wrong exactly?
In Chrome and IE frame history doesn't mess up normal history, so they are unaffected for all "iframe+history bugs" on Bugzilla (including the old ones).

Comment 12

[blindpet]

(In reply to arni2033 from comment #11)
> Created attachment 8715053 [details]
> bug 1244517 - irrelevant testcase.zip
> 
> Could somebody please explain to me, why is this bug so important since
> frames history wasn't thought through and is kind of broken by-design? In
> this attachment, both frames do completely legitimate things, and the page
> gives the same result as the site in comment 0 (even before bug 855443)
> 
> STR:
> 1. Save "irrelevant testcase" and extract all files in one folder
> 2. Open http://example.com/ in a new tab
> 3. Drag file "testcase - frames history.html" to the tab from Step 2
> 4. Wait 2 seconds
> 
> AR:  http://example.com/ is loaded in that tab instead of "testcase - frames
> history.html"
> ER:  No history jumps
> 
> I'm pretty sure this scenario is supposed to be wrong by Mozilla, but what's
> wrong exactly?
> In Chrome and IE frame history doesn't mess up normal history, so they are
> unaffected for all "iframe+history bugs" on Bugzilla (including the old
> ones).

I can explain to you from a site admin's point of view. This bug never happened before and it currently ruins the user experience both for speed (for me having to turn off Rocket Loader) and general browsing. Enough users are affected that this bug can affect Firefox's reputation. The fact that it only seems to affect Firefox and no other browser is significant. I hope you devs can figure it out. If iframe history is broken by design and that is the core issue it should be rectified.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

As far as I know, this is not a regression in Firefox, but at least in the cases I've managed to reproduce a bug in google's ad scripts. And I've contacted Google using the normal channels I know about, and tried also otherwise contact the relevant team, since this is totally horrible bug.

blindpet, if you have a testcase which doesn't have anything to do with google's scripts, I'd really would like to be able to test it.


(In reply to arni2033 from comment #11)
> Created attachment 8715053 [details]
> bug 1244517 - irrelevant testcase.zip
arni2033 , could you please file a new bug about that.
I need to read HTML spec about what it says about that case.

> I'm pretty sure this scenario is supposed to be wrong by Mozilla, but what's
> wrong exactly?
Not sure what you mean here? We're trying to implement WhatWG HTML spec, and if we aren't following it,
there is a bug (either in the spec or in the implementation).
Though, session history is complicated and HTML spec is known to miss many edge cases of session history handling.

> In Chrome and IE frame history doesn't mess up normal history, so they are
> unaffected for all "iframe+history bugs" on Bugzilla (including the old
> ones).
Chrome certainly has major issues with iframe+session history. 
It is possible to use go(-1) in Chrome in such way to a page which was never loaded to an iframe gets loaded to it.
But that is totally of topic to this bug.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

[e-mail], any chance for a testcase showing this issue with Rocket Loader?
(especially with Google ads disabled)

Comment 15

[blindpet]

(In reply to Olli Pettay [:smaug] (high review load) from comment #14)
> [e-mail], any chance for a testcase showing this issue with Rocket
> Loader?
> (especially with Google ads disabled)

I have turned off all Google ads on the dev site htpcguides.casa with Rocket Loader still enabled

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

...and you can reproduce the bug?

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

(oh, I should have asked in bug 1244326, which was about htpcguides. Oh well. Doesn't matter too much where to ask. Still trying to find out if there is a case where the 'back' happens without Google ads.)

Comment 18

[blindpet]

(In reply to Olli Pettay [:smaug] (high review load) from comment #17)
> (oh, I should have asked in bug 1244326, which was about htpcguides. Oh
> well. Doesn't matter too much where to ask. Still trying to find out if
> there is a case where the 'back' happens without Google ads.)

Doesn't seem to be reproducible without google ads turned on, it must have been a coincidence that turning off Rocket loader resolved the issue since a different google ad was probably being shown.

Comment 19

[Andrew Overholt [:overholt]]

It seems this may have been fixed on Google's end. Can you please confirm?

Comment 20

[Alice0775 White]

I cannot reproduce the problem with str of comment#0 on Latest Nightly48.0a1 as well as Firefox45.0.1.