Last Comment Bug 273158 - [FIXr]Page do not re-render if page.html#name -> page.html
: [FIXr]Page do not re-render if page.html#name -> page.html
Status: VERIFIED FIXED
:
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: -- major (vote)
: mozilla1.8alpha6
Assigned To: Boris Zbarsky [:bz]
: Adam Lock
Mentors:
http://www.ping.se/mozilla.html
: 302278 (view as bug list)
Depends on: 280215
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-04 12:17 PST by Mikael Kuisma
Modified: 2009-07-11 06:16 PDT (History)
7 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch to implement that behavior (2.28 KB, patch)
2004-12-06 08:57 PST, Boris Zbarsky [:bz]
cbiesinger: review+
darin.moz: superreview+
Details | Diff | Splinter Review
testcase (186 bytes, text/html)
2008-11-16 21:20 PST, Adonis Fung
no flags Details

Description Mikael Kuisma 2004-12-04 12:17:55 PST
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] 2004-12-04 15:12:48 PST

*** This bug has been marked as a duplicate of 122053 ***
Comment 2 Frank Wein [:mcsmurf] 2004-12-05 04:22:41 PST
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) 2004-12-05 05:55:08 PST
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 [:bz] 2004-12-05 10:05:55 PST
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 2004-12-05 17:16:47 PST
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 [:bz] 2004-12-05 18:31:59 PST
> 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] 2004-12-05 22:39:36 PST
(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 2004-12-06 01:44:06 PST
(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 [:bz] 2004-12-06 08:57:24 PST
Created attachment 168033 [details] [diff] [review]
Patch to implement that behavior
Comment 10 Darin Fisher 2004-12-06 15:48:04 PST
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 [:bz] 2004-12-08 11:21:05 PST
Fixed on trunk.
Comment 12 Frank Wein [:mcsmurf] 2004-12-31 07:36:40 PST
V. with a current Mozilla CVS trunk build.
Comment 13 Christian :Biesinger (don't email me, ping me on IRC) 2005-01-28 09:42:51 PST
this caused bug 280215
Comment 14 Boris Zbarsky [:bz] 2005-01-28 10:07:05 PST
This caused bug 280215
Comment 15 Frank Wein [:mcsmurf] 2005-08-02 06:32:31 PDT
*** Bug 302278 has been marked as a duplicate of this bug. ***
Comment 16 Adonis Fung 2008-11-16 21:20:10 PST
Created attachment 348507 [details]
testcase
Comment 17 Adonis Fung 2008-11-16 21:33:25 PST
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 [:bz] 2008-11-17 07:13:36 PST
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 2008-11-17 07:22:08 PST
Alright, I posted it as a new bug which can be accessed from here:
https://bugzilla.mozilla.org/show_bug.cgi?id=465263

Note You need to log in before you can comment on or make changes to this bug.