273158 - [FIXr]Page do not re-render if page.html#name -> page.html

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Mikael Kuisma]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

If you from a location "page.html#name" visitis location "page.html",
the page.html is never re-rendered, but only scrolled to top of page.
Javascript do not re-execute, the page is not cleared/re-renderd and so.


Reproducible: Always
Steps to Reproduce:
1. Goto page http://www.ping.se/mozilla.html
2. Click on [click here for mozilla.html#name]
3. Click on [click here for mozilla.html] and notice that the time of render do 
not change.


Actual Results:  
Page do not change. Time stamp displayed is the same time as when page loaded 
the first time.


Expected Results:  
The the original page mozilla.html is visited again, the page should be re-
rendered, and the time stamp should reflect this.


Also applies to Firefox 1.0
This bug will cause web sites with dynamic html contents to fail to work under 
some circumstances.

Comment 1

[Frank Wein [:mcsmurf]]

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

Comment 2

[Frank Wein [:mcsmurf]]

yes, reopening for now, this is a different case (not sure if this here is a bug
so, need still to get some feedback)...

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

this seems to be by design to me... why refetch the page when the user just
clicks a link to scroll to a specific section of the page?

Comment 4

[Boris Zbarsky [:bzbarsky]]

That's correct.  page.html and page.html# are the same thing and should be
treated identically.  If a reload is desired, one can call location.reload();
that's what it's there for.

Comment 5

[Mikael Kuisma]

Clearification 1: If page.html#name -> page.html should not cause page to be re-
renderd because it is "same thing", then page.html -> page.html should neither 
be re-rendered, but infact is.

Clearification 2: Please note that re-fetch is controlled by cache control, and 
has little to do with page rendering.

Clearification 3: If page.html is not re-rendered during thouse conditions, 
there is no way at all for a html page to re-render ("reload") itself via a 
link. Ofcause, javascript, user interaction and other non-html mechanisms may 
be used to re-render the page, but not html. Loading a page is quite a basic 
html mechanism, and I find it strange that it may exist a case were it is 
impossible to achieve.

Clearification 4: page.html -> page.html#name may not re-render. In this case I 
am talking about page.html#name -> page.html.

SCENARIO: Two frames, menu and contents. Contents may be some dynamic stuff 
like a shoping basket, local weather report, news or so and do contain named 
anchors. Menu frame contains 'A href=page.html target=contents' to load 
different contents.
Note that in this scenario, the menu frame links MAY or MAY NOT cause the 
contents frame to re-render or not, depending on if the location in the 
contents frame has a named anchor or not. This is ofcause a very undesirable 
behavour, and will cause random results.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> then page.html -> page.html should neither be re-rendered

Except that's clearly not an anchor traversal, and hence shouldn't be treated as
one.....

And yes, reloading the current page is not something that the HTML specification
actually provides for.

> Clearification 4: page.html -> page.html#name may not re-render. In this case
> I am talking about page.html#name -> page.html.

The point is, there is no substantive difference between these two cases.  This
is just going from an anchor in the middle of the page to the beginning of the
page...

Note that we _could_ "fix" this.  But I'm fairly certain that would break
existing pages that depend on the current behavior...  The fact that no one has
brought this up in the 4 years we've had this behavior makes me suspect that
pages actually expect it....

What do other browsers do?

Comment 7

[Frank Wein [:mcsmurf]]

(In reply to comment #6)
> What do other browsers do?

For IE 6.0:
page.html->page.html: page gets re-rendered
page.html->page.html#name: page gets NOT re-rendered
page.html#name->page.html: page gets re-rendered
page.html#name->page.html#name: page get NOT re-rendered

Comment 8

[Mikael Kuisma]

(In reply to comment #6)
> Note that we _could_ "fix" this.  But I'm fairly certain that would break
> existing pages that depend on the current behavior...  The fact that no one 
has
> brought this up in the 4 years we've had this behavior makes me suspect that
> pages actually expect it....
> What do other browsers do?

On the contrary, Mozillas behavior cause existing pages fail because of 
this "feature", typical as described in the scenario above. I have not seen 
this behavior in any non-Mozilla browser.

For Opera 7.54:
page.html->page.html: page gets re-rendered
page.html->page.html#name: page gets NOT re-rendered
page.html#name->page.html: page gets re-rendered
page.html#name->page.html#name: page get NOT re-rendered

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to implement that behavior

Comment 10

[Darin Fisher]

Comment on attachment 168033 [details] [diff] [review]
Patch to implement that behavior

>Index: docshell/base/nsDocShell.cpp

>+    if (hashNew <= 0) {
>+        return NS_OK;           // Strange URI or no new anchor
>     }
>+    else {

else after return is unnecessary.  sr=darin assuming r=biesi

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.

Comment 12

[Frank Wein [:mcsmurf]]

V. with a current Mozilla CVS trunk build.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

this caused bug 280215

Comment 14

[Boris Zbarsky [:bzbarsky]]

This caused bug 280215

Comment 15

[Frank Wein [:mcsmurf]]

*** Bug 302278 has been marked as a duplicate of this bug. ***

Comment 16

[Adonis Fung]

Attachment: testcase

Comment 17

[Adonis Fung]

Could someone reopen this bug??

Tested in both:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081116 Minefield/3.1b2pre

At page page.html, setting document.location.hash = '' caused page reload.
It should be considered as nothing changed before and after javascript execution since document.location.hash is always empty, but the page still reloads.

Reproducible: Always

Steps to Reproduce:
1. Go to https://bugzilla.mozilla.org/attachment.cgi?id=348507
2. Click on the only button
3. Notice that there comes the 2nd alert (attached to onload) after clicking the button

Actual Results:  
Page reloaded unexpectedly

Expected Results:
Page doesn't reload, i.e. no second prompt in the testcase submitted

All of the major browsers including Internet Explorer 6 & 7, Safari 3.1.2, Opera 9.62 and Chrome 0.3.154.9 (latest stable versions at the moment) follow the above expected behavior.

changing document.location.hash should not cause any page reload anyway.

Comment 18

[Boris Zbarsky [:bzbarsky]]

That sounds like a separate bug that should be filed separately.  I would be happy to look into it once that's been done.  Note that the claim is that UAs handle anchor navigation and equivalent location.hash sets differently, which I'm not sure is desirable.

Comment 19

[Adonis Fung]

Alright, I posted it as a new bug which can be accessed from here:
https://bugzilla.mozilla.org/show_bug.cgi?id=465263