Last Comment Bug 186371 - urls with local anchors won't reload if you press enter in Location bar (or click "go" button)
: urls with local anchors won't reload if you press enter in Location bar (or c...
Status: NEW
:
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: -- normal with 5 votes (vote)
: ---
Assigned To: location-bar
:
Mentors:
http://jimmy.qmuc.ac.uk/jimtools/date...
: 292679 745472 754710 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-21 00:48 PST by Hoss
Modified: 2016-08-05 04:22 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Local exploit for bug (229 bytes, text/html)
2002-12-21 00:54 PST, Hoss
no flags Details

Description Hoss 2002-12-21 00:48:21 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021205 Debian/1.2.1-1.01
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021205 Debian/1.2.1-1.01

There are many actions a user can perform to cause a page to reload, some of
these actions don't work if the URL includes a local anchor (ie:
http://www.foo.com/bar#local_anchor)

NOTE: The page does reload correctly if you explicitly click the "reload" button.

Reproducible: Always

Steps to Reproduce:
1. visit this url...
   <http://jimmy.qmuc.ac.uk/jimtools/datetime.shtml>
2. click in the Location bar, and hit enter/return a few times
3. click the "Go" button a few times
4. now add a "#foo" to the end of the URL...
   <http://jimmy.qmuc.ac.uk/jimtools/datetime.shtml#foo>
5. click in the Location bar, and hit enter/return a few times
6. click the "Go" button a few times



Actual Results:  
After steps 2 & 3, the page reloads each time (you can see the time stamp update)

After steps 5 & 6, the page does NOT reload.

Expected Results:  
The fact that the URL inclues a local anchor should not affect wether or not the
page reloads ... it should reload after steps 5 & 6 as well.


The URL listed in the steps to reproduce was choosen at random from Google
results, purely because if had javascript to update a timestamp with seconds
granularity, and no "Expires" info.

In the example above, the local anchor doesn't acctually exist on this page, but
that doesn't affect the behavior.

I'll attach a smaller example in a moment.
Comment 1 Hoss 2002-12-21 00:54:24 PST
Created attachment 109885 [details]
Local exploit for bug

This file can be used to demonstrate the bug, using the same steps as the
orriginal URL posted.

It has the benefits of being simpler, and of having the local anchor "foo"
defined.
Comment 2 R.K.Aa. 2002-12-21 09:34:45 PST
In the other bugs on this, the bug has been that the page DID reload when going
to a local anchor. The expected behaviour being that the page should simply
scroll to the anchor, and NOT perform a reload. This was first fixed in bug 644,
later complained about in bug 79953, 127251 and others.

According to those fixes, this bug is invalid.
Comment 3 Hoss 2002-12-21 10:32:08 PST
There is a distinction beteween this bug, and the bugs you cited.

in all of those bugs, the complaint was that clicking on a link to a named
anchor on a page which was allready loaded would forcibly reload the page.

My point is not about clicking the link to the named anchor, my point is about
pressing the "Go" button (or pressing enter while in the Location bar).  I agree
completely with the other bugs: when clicking on a link to a local named anchor
(ie: <a href="#foo">foo</a>) there is no need for the page to be reloaded, the
window should just scroll to the named anchor -- but after that has happened,
shouldn't pressing the "Go" button forcibly reload the page AND scroll to the
named anchor?


I guess what this all boils down to is my assumption/presumption that if the
user loads a url (ANY url), and then clicks the "Go" button (without modifying
the contents of the Location bar) the Go button should do at least as much as
clicking the reload button (and in my opinion: as much as a "shift-reload").



Comment 4 Aaron Lawrence 2004-07-16 07:05:36 PDT
I suppose so, if Go reloads the page then it should always do so...
However, what happens when that anchor DOES exist on the page? Is behaviour
different?
Comment 5 Gabriel Chadwick 2005-05-03 06:17:52 PDT
The behavior is the same even if the anchor exists.
Comment 6 Gabriel Chadwick 2005-05-03 06:19:15 PDT
*** Bug 292679 has been marked as a duplicate of this bug. ***
Comment 7 Gabriel Chadwick 2005-05-03 06:23:35 PDT
Confirming this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050502 Firefox/1.0+
Comment 8 Henrik Skupin (:whimboo) 2012-11-27 04:31:04 PST
*** Bug 754710 has been marked as a duplicate of this bug. ***
Comment 9 Henrik Skupin (:whimboo) 2012-11-27 04:33:56 PST
*** Bug 745472 has been marked as a duplicate of this bug. ***
Comment 10 Henrik Skupin (:whimboo) 2013-01-16 03:44:12 PST
This is not only happening for SeaMonkey but all Gecko applications. One more example would be a link to the following URL which should be handled by the internal PDF viewer.

http://www.gesetze-im-internet.de/bundesrecht/bgb/gesamt.pdf#page=1&zoom=auto,0,586

If you load the page once and scroll away, a reload will not scroll the page back to the location as initially loaded.

What would be the best component?
Comment 11 Andrew Overholt [:overholt] (back Aug 31) 2016-01-22 08:30:45 PST
(In reply to Henrik Skupin (:whimboo) from comment #10)
> This is not only happening for SeaMonkey but all Gecko applications. One
> more example would be a link to the following URL which should be handled by
> the internal PDF viewer.
> 
> http://www.gesetze-im-internet.de/bundesrecht/bgb/gesamt.
> pdf#page=1&zoom=auto,0,586
> 
> If you load the page once and scroll away, a reload will not scroll the page
> back to the location as initially loaded.

This seems to work for me now with nightly. Is it still broken for you?
Comment 12 Henrik Skupin (:whimboo) 2016-01-22 11:05:57 PST
Yes, its working for me too. Looks like some patch in the last 3 years fixed it.
Comment 13 Andrew Overholt [:overholt] (back Aug 31) 2016-01-22 11:22:04 PST
It looks like Edge and IE behave the same as Firefox here but Chrome does not.

dbaron, do you know if there is a standard or something around this (and I know you're away for a few more days)?
Comment 14 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2016-01-26 13:27:29 PST
I don't know of a standard (although that doesn't mean there isn't one) -- but it does seem like it could be nice to fix so that we do a reload if the anchor is the same but don't reload if it's different -- at least if that matches Chrome's behavior.
Comment 15 Tony Mechelynck [:tonymec] 2016-01-28 19:55:57 PST
Isn't this expected behaviour? When I click the Go button or hit Enter in the URL bar, I don't expect the current page to be reloaded if it's already at the desired URL. What I do expect is the anchor (#identifier), if there is one at the end of the URL, to be brought to the start of the content area (or the page to be scrolled to the very bottom if that anchor's distance from the page bottom is shorter than the content height).

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