653807 - Should pressing <enter> in the location bar *always* result in a refresh?

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Justin Lebar (not reading bugmail)]

Currently (well, after we fix the regression noted in bug 653741), pressing <enter> in the location bar does one of two things:

* If the URI doesn't contain a hash, the page is refreshed.
* If the URI does contain a hash, the page is not refreshed, and we scroll back to whatever anchor is specified in the URI's hash.

I think this behavior is pretty bizarre.  I'd rather be consistent and always refresh.

On the other hand, being consistent would mean getting rid of the ability to scroll back to whatever anchor is specified in the URI without refreshing.  At least one person uses this feature.  :)

IE9 and Opera do what we currently do, while Chrome and Safari always refresh.

Comment 1

[Justin Lebar (not reading bugmail)]

I'm curious what the UX folks think we should do here.

Comment 2

[Justin Lebar (not reading bugmail)]

Attachment: Testcase

Here's a simple testcase.  Load it, press enter in the location bar, and notice that the displayed time changes.  Now add #foo, press enter, and notice that the displayed time doesn't change when you re-focus the location bar and press enter.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Note that in Chrome and Safari "enter in url bar" does the same thing as the reload button in all cases.  So it's not at all the same as our "no hash" refresh from commen 0 (which does NOT do the same thing as the reload button).

Comment 4

[Justin Lebar (not reading bugmail)]

What else would we unwittingly break if we made "enter in the URL bar" the same thing as the reload button?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Well, it'd be a lot slower for one thing.

Comment 6

[Justin Lebar (not reading bugmail)]

I Am Not a UX person, but I think fewer load types is probably better from a user's perspective.  I mean, I work on docshell and I don't understand the differences between all these different loads.

Comment 7

[Boris Zbarsky [:bzbarsky]]

For what it's worth, the other common case where I rely on the current behavior is by hitting "enter" in the url bar during pageloads for URIs that have an anchor to trigger the anchor scroll quicker than we normally do...  Arguably that's a bug we should just fix, though.

Comment 8

[Frank Yan (:fryn)]

(In reply to comment #3)
> Note that in Chrome and Safari "enter in url bar" does the same thing as the
> reload button in all cases.  So it's not at all the same as our "no hash"
> refresh from commen 0 (which does NOT do the same thing as the reload
> button).

In Chrome, the reload button doesn't clear the referrer (document.referrer), whereas the go button does. This is most noticeable when sites return 403 Forbidden errors for non-same-origin, non=null referrers but display the resource normally after pressing enter in the URL bar.

I think this behavior is desired; therefore, my answer for the bug's question is yes.

Comment 9

[O. Atsushi (Torisugari)]

What's the merit of refresh? I'm sure low-bandwidth users all over the world wouldn't like UA to re-fetch dynamic contents. If inconsistency

> * If the URI doesn't contain a hash, the page is refreshed.
> * If the URI does contain a hash, the page is not refreshed,
>   and we scroll back to whatever anchor is specified in the URI's hash.

is the problem, we can chose "don't refresh if it doesn't contain a hash." How about just doing nothing, or scrolling back to top of the page? Users can hit F5 or "Ctrl + r" when they need reloading.

Comment 10

[Boris Zbarsky [:bzbarsky]]

A few more notes:

1)  Ctrl+r doesn't do the same thing as hitting enter in url bar.  It causes more
    network traffic.
2)  Scripted location sets and anchor links to the current location with no hash
    need to reload the page for web compat, last I checked (see the blame on the
    relevant code).  If we want a different behavior for url bar, we'll need to
    communicate more than just the url to load down to docshell.

Comment 11

[O. Atsushi (Torisugari)]

(In reply to comment #10)
> 1)  Ctrl+r doesn't do the same thing as hitting enter in url bar.  It causes
>     more network traffic.
It sounds a little weird to me, though now I see what you mean. Users can relaod, hard-reload, and soft-reload(doc only), in undocumented ways...

Comment 12

[Boris Zbarsky [:bzbarsky]]

Well, with an HTTP cache there are 4 possible "reload" behaviors:

1)  Read from the cache unconditionally (this is the "save as" behavior, say).
2)  Read from the cache for valid things, revalidate things that might be
    invalid (this is the normal load behavior).
3)  Revalidate everything but allow 304 responses and intermediate caches
    (normal reload).
4)  Force everything to be reread end-to-end from the server, bypassing all
    intermediate caches and our cache (forced reload).

We surface all but #1 in our user-facing UI at the moment, with different ways of getting at them.

Comment 13

[David Woldrich]

My muscle memory is to use Enter in the location bar to "revalidate the page".  

I'm always confused when this fails to trigger anything and I have to click refresh with the mouse.  With the current behavior, often the local anchor is already in view, and the page does not scroll.  In that case, the Enter key feels like it was silently ignored to the confused me.  

I finally got curious enough that I researched it and found this bug.  Now I understand it's the local anchor, and I agree with those who say the current behavior is inconsistent.  I love the 4 possible cache behaviors discussion, you learn something new every day.

I think it's valid to be able to navigate in-page to an anchor using just the location bar though.  I think the rule should be: if URL has a local anchor, and the user has hit enter on the location bar, then the page should revalidate.  But, if the location was changed at all, and the URL has a local anchor, then it should scroll to the anchor without refreshing.

It would be handy if there were visual cues as to what firefox thinks about the current URL in the location bar.  Clicking in the location bar now for me highlights the URL. It might be helpful if there was also grey text right aligned in the location bar (assuming there is enough horizontal space) that says "Press Enter to revalidate this page" or something to that effect.  If the user types anything in the location bar or edits it, then this hint would disappear and the current location bar semantics would apply.