235398 - back button doesn't work at ohmynews.com

Status: RESOLVED DUPLICATE of bug 237717

(Core :: Networking: HTTP, defect)

Description

[Jungshik Shin]

'Back button' doesn't work at http://www.ohmynews.com I always have to go to
'Go' menu and manually select two pages before the current page. 

- How to reproduce

1. go to http://www.ohmynews.com
2. Click on any article link (say, the front-page article at the top left : just
below the menu and to the right of the link for 'English')
3. An ad-page comes up 
4. A few second later, it's redirected to the article
5. Click on 'Back' button
6. Mozilla doesn't go back.
7. Go to 'Go' menu and see that there are three pages listed for ohmynews.com
8. Selecting the third item from the top, you can go back to the front page.

Now, this may as well be an evangelism issue because the way they use the
redirection doesn't seem to be right (I can't exactly figure out what). I'm
gonna attach the html source file of an advertisement page with the javascript
code for the redirection. Somehow, MS IE works around the problem if it's an
evagelism issue.

Comment 1

[Jungshik Shin]

Attachment: ohmynews 'advertise' page source

On purpose, I'm setting the mime type to text/plain so that you can take a look
at the source code without being redirected.

Comment 2

[Jungshik Shin]

For the accessibility, if nothing else, their way of redirection seems to be
bad. I'll write to the webmaster that they'd better use http header for the
redirection.

Comment 3

[Jungshik Shin]

I thought 'refresh' is a real http header, but it's not listed in http 1.0/1.1 
http 30x response and http location header can't be used for delayed redirection. 
So, the only option seems to be to use

<meta http-equiv="refersh" content="......"> 

although it's not recommeneded from the accessibility point of view.

Comment 4

[Patrick Quaedackers]

The Back button doesn't work because they use a javascript to go to a different
page.
They use the "document.location.replace()" function. This is according the
JavaScript standard whitch says that a URL in the document.location.replace
function should override the current URL.
That way the back button doesn't get back to the previous URL.
(see
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/location.html#1194240
)

Comment 5

[Jungshik Shin]

Thanks for the reference. That made it clear that there's a bug to fix here
because Mozilla doesn't work the way it's supposed to work according to the
reference you gave. 

There are three pages involved here.

page 1 : the front page of http://www.ohmynews.com

page 2 : the advertisement page (I've attached here) which is replaced by page 3
after about 4 seconds by location.replace

page 3 : the article page whose link I clicked in page 1.

When I clicks a link to the article I'm interested in in page 1, I'm shown page
2 (advertisement page) for about 4 seconds after which I'm shown page 3. 

Now in page3, when I press 'back' button, I expect Mozilla go back to page 1.
However, I'm just stuck. (page 2 is supposed to be skipped because it's replaced
by page 3 with 'location.replace'.) Besides, 'Go' menu has page 2 as well as
page 1 and page 3.  

Opera and MS IE work just fine. 

This might be a JS issue

Comment 6

[Boris Zbarsky [:bzbarsky]]

I just traced the location.replace() code and it seems to be doing the right things.

At the same time, I _am_ seeing this bug.

If you can create a minimal testcase and attach it to this bug, that would be
wonderful...

Comment 7

[Jungshik Shin]

What I thought would serve as a reduced test case didn't work. I meant I
couldn't reproduce the bug with that. I'll try to see if there's anything
unusual in 'http traffic' to and from www.ohmynews.com

Comment 8

[Isaac Hwak Han]

It seems that this was fixed by today's check-in of bug 237717. I want the fix
to be incorporated into 1.7 branch. ohmynews.com is one of the major sites
according to Alexa and http://www.rankey.com

Comment 9

[Boris Zbarsky [:bzbarsky]]

Why did that patch fix this bug?  It should not have affected anything except
loads in frames that start out as about:blank and are loaded after onload.  Is
there such a beast here?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Hmm... Actually, maybe there is.  The onload handler for the page inserts an
<iframe> into the document, right?

This is the part where that minimal testcase I asked for would have helped....

Comment 11

[Isaac Hwak Han]

Attachment: Reduced testcase

You're right. Here is a reduced testcase.

The only difference with bug 237717 is that this site inserts IFRAME by setting
<object>.innerHTML.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Ok, in that case this is a duplicate; marking so.  See my comments in that bug
regarding the 1.7 branch; we can continue the discussion there.

Thanks for making the testcase!

*** This bug has been marked as a duplicate of 237717 ***