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

VERIFIED FIXED in mozilla1.8alpha6

Status

()

Core
Document Navigation
--
major
VERIFIED FIXED
13 years ago
8 years ago

People

(Reporter: Mikael Kuisma, Assigned: bz)

Tracking

Trunk
mozilla1.8alpha6
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

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

13 years ago

*** This bug has been marked as a duplicate of 122053 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE

Comment 2

13 years ago
yes, reopening for now, this is a different case (not sure if this here is a bug
so, need still to get some feedback)...
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Updated

13 years ago
Assignee: general → adamlock
Component: General → Embedding: Docshell
Product: Mozilla Application Suite → Core
QA Contact: general → adamlock
Version: unspecified → Trunk
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?
OS: Windows 2000 → All
Hardware: PC → All
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → INVALID
(Reporter)

Comment 5

13 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
> 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

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

Comment 8

13 years ago
(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
Created attachment 168033 [details] [diff] [review]
Patch to implement that behavior
(Assignee)

Updated

13 years ago
Attachment #168033 - Flags: superreview?(darin)
Attachment #168033 - Flags: review?(cbiesinger)
(Assignee)

Updated

13 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 10

13 years ago
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
Attachment #168033 - Flags: superreview?(darin) → superreview+
Attachment #168033 - Flags: review?(cbiesinger) → review+
(Assignee)

Updated

13 years ago
Assignee: adamlock → bzbarsky
Summary: Page do not re-render if page.html#name -> page.html → [FIXr]Page do not re-render if page.html#name -> page.html
Target Milestone: --- → mozilla1.8alpha6
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → FIXED
V. with a current Mozilla CVS trunk build.
Status: RESOLVED → VERIFIED
this caused bug 280215
This caused bug 280215
*** Bug 302278 has been marked as a duplicate of this bug. ***

Comment 16

9 years ago
Created attachment 348507 [details]
testcase

Comment 17

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

9 years ago
Alright, I posted it as a new bug which can be accessed from here:
https://bugzilla.mozilla.org/show_bug.cgi?id=465263
Flags: in-testsuite?
Depends on: 280215
You need to log in before you can comment on or make changes to this bug.