Closed Bug 1353023 Opened 7 years ago Closed 7 years ago

Enter in location bar reloads the page only if there's no fragment (unlike Chrome)

Categories

(Core :: DOM: Navigation, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ayg, Unassigned)

Details

Load a URL without a fragment:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1314388

If you put the cursor inside the the URL bar and hit Enter, the page reloads.  But with a fragment:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1314388#c0

It doesn't reload, it jumps to the fragment (even if you're already jumped to the fragment).  In Chrome, it reloads in either case.  If you edit the fragment before hitting Enter, even Chrome doesn't reload.

Our behavior is nice because it allows an easy way to jump to the fragment without reloading the page.  However, it's less consistent, and might be jarring for Chrome users.  (I apparently am used to reloading the page this way sometimes instead of F5, and when I switched from Chrome to Firefox as my main browser a few days ago I started noticing this issue regularly.)

I suggest that when the URL bar has a fragment, hitting Enter once should jump to the fragment but leave the URL bar focused.  Hitting Enter a second time should reload the page.  Why do we blur the URL bar to begin with when hitting Enter here?
Component: Location Bar → Document Navigation
Product: Firefox → Core
I feel like we have other bugs on this but I can't find them. Gijs, am I recalling correctly that you know the situation here?
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Andrew Overholt [:overholt] from comment #1)
> I feel like we have other bugs on this but I can't find them. Gijs, am I
> recalling correctly that you know the situation here?

I know that in general, for a same-document navigation, we can't tell whether it was caused by user action or not, and that causes 'issues' if you combine editing the URL bar and navigating via in-page #hash links (and it does so in all browsers - though they might make different choices about whether they prefer losing URL bar user input or not having the URL bar reflect the last same-document link clicked), but that doesn't seem to be the issue here.

This feels much more like, if you navigate to the same thing you navigated to before (and, perhaps, if the page hasn't scrolled) then enter should reload.

I don't think I know anything more about that than Marco. I'm forwarding because he moved this out of the location bar component, and I'm not entirely sure why.

(In reply to Aryeh Gregor (:ayg) (next working August 2-22) from comment #0)
> Why do we blur the URL bar to begin with when
> hitting Enter here?

Because generally after you navigate, you want focus to be in the page, you don't want to navigate again (otherwise, why not put the right URL in immediately?). I don't think we should change this. If we don't change this, I'm not sure if making the 'second' enter do a reload would be understandable to the user.

I would also suggest that in the grand scheme of things it doesn't matter much: most users don't reload pages, and even fewer actively edit #ref links in the location bar. Plus, if focus is not in the URL bar, f5 or accel-r are much quicker than switching focus and then hitting enter/return. So I'm actually leaning towards wontfix...
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mak77)
(In reply to :Gijs from comment #2)
> I don't think I know anything more about that than Marco. I'm forwarding
> because he moved this out of the location bar component, and I'm not
> entirely sure why.

Because imo the Firefox / Location Bar component is a UI component. The location bar controls what we show to the user, what we suggest to the user, and handles user selection. What happens once we pass control to the docshell is not a Location Bar matter, it's a document navigation issue.
The Location Bar component is collecting any sort of unrelated issues, now also bugs related to the page action button, that have nothing to do with the Location Bar functionality, if not just the fact they appear into it for a design choice. If we start putting everything there it will become unmanageable (also because I don't have all that knowledge of Document Navigation handling, so it's hard for me to triage issues related to it).
I'm happy to take this back if the problem is related to the Location Bar UI handling.
Flags: needinfo?(mak77)
Docshell captures mostly web phasing behavior of page loading.
Say, location.href = location.href; is supposed to load the page.
That ends up calling nsDocShell::LoadURI
Given comment 2 I'm going to close this WONTFIX but if things have been misinterpreted or you disagree, please re-open, Aryeh. Thanks for the comments, Gijs, Marco, and Olli!
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.