757455 - With browser.newtab.url set to a non-default value, the URL bar should show the URL and select it for the user to replace it

Status: RESOLVED WONTFIX

(Firefox :: New Tab Page, defect)

Description

[Mike Kaply [:mkaply] (Out until 9/29)]

When you set the new tab page to something other than the default and then open a new tab page, focus is at the end of the URL bar with nothing selected.

So in order to navigate to a new URL, you have to select the text.

This is a major usability issue.

When a new tab page is opened, the content of the URL bar should be selected.

Comment 1

[Mike Kaply [:mkaply] (Out until 9/29)]

This issue would be this code here:

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/utilityOverlay.js#316

if (!loadInBackground && isBlankPageURL(url))
     w.focusAndSelectUrlBar();

It should also check to see if the reason that the tab was opened was because of new tab page.

It can't just check the URL because you can now set the URL to any arbitrary page.

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Michael Kaply (mkaply) from comment #1)
> It can't just check the URL because you can now set the URL to any arbitrary
> page.

That's what isBlankPageURL() is for. It returns true if the given URL is equal to 'about:blank' or to the URL defined in 'browser.newtab.url'.

Comment 3

[Mike Kaply [:mkaply] (Out until 9/29)]

> That's what isBlankPageURL() is for. It returns true if the given URL is equal to 'about:blank' or to the URL defined in 'browser.newtab.url'.

Sorry, read it wrong. You are correct.

But either way, it's not working.

On FF13 with a new tab, the cursor is at the end of the URL bar and nothing is selected.

Comment 4

[Mike Kaply [:mkaply] (Out until 9/29)]

It appears to be a timing issue in focusAndSelectUrlBar.

If you check the value of gURLBar after setting the focus, it is empty. So there is nothing to select.

Comment 5

[Ben Bucksch (:BenB)]

Please also hide the newtab URL, if it's 1) the URL in browser.newtab.url and 2) it's starting with chrome: or a similar URL (if the newtab url is "http://www.yahoo.com", it should be shown, but not when it's "chrome://myext/newtab/page.xul").

As Mike correctly noted, this is a major usability issue. Even if the URL was selected by default, the focus might be lost, and then the user has to manually select it. Also, chrome URLs are not supposed to be shown to end users.

Comment 6

[Ben Bucksch (:BenB)]

I've implemented this before, in fact. See attachment 448200 [details] [diff] [review] in bug 561749. It was marked dup of the newtab page, but not properly fixed there (sigh), so let's do it here.

Comment 7

[Raymond Lee [:raymondlee]]

Attachment: v1

Ben: it might be better to file another bug for hiding new tab page urls you suggested.

Comment 8

[Dão Gottwald [:dao]]

Comment on attachment 626405 [details] [diff] [review]
v1

This is too hackish...

The location bar should just be empty, then this isn't a problem. Extensions can add URIs to gInitialPages, fwiw.

Comment 9

[Mike Kaply [:mkaply] (Out until 9/29)]

> The location bar should just be empty, then this isn't a problem.

I'm not sure this is always the right solution either.

If a user sets their new tab page to a real page on the web, they would probably want to see the URL.

In those cases, when a new tab is opened, you would want focus on the URL bar (unless the page takes it) and you would want the text selected.


If the new tab page is a chrome URL (or about page), you probably want to hide the text in the URL bar.

Comment 10

[Ben Bucksch (:BenB)]

Mike, that's what the patch does which I referenced in comment 6, and what I said in comment 5.

Comment 11

[Ben Bucksch (:BenB)]

As a slight modification, I think the conditions
1) user has not entered the URL himself right now and
2) it's a chrome: or about: URL
would also be fine to hide the URL. There's a userVisited (or similar) flag in browser.js, so let's use that for 1).

Comment 12

[Raymond Lee [:raymondlee]]

I think we should get some input from the UX team

Comment 13

[Silvan]

If a url like google.com is set as newtab.url then the focus should go to the searchbox within google, not to the locationbar.

Comment 14

[Mike Kaply [:mkaply] (Out until 9/29)]

> If a url like google.com is set as newtab.url then the focus should go to the searchbox within google, not to the locationbar.

Only if the web page puts it there.

Comment 15

[Ben Bucksch (:BenB)]

Raymond Lee [:raymondlee] wrote 2 weeks ago:
> I think we should get some input from the UX team

Ping? Can we either have the input or accept patches, please? This is a serious usability bug.

Comment 16

[Ben Bucksch (:BenB)]

To rephrase:
For newtab URLs (e.g. URL set in "browser.newtab.url" or |userVisted| flag not set):
- if chrome: or about: URL, hide it, e.g. automatically put it in gInitialPages
- if webpage (http: etc.): select whole URL
In both cases, the URLbar must have the keyboard focus, so that the user can just type the target URL he wants.

Comment 17

[Mike Kaply [:mkaply] (Out until 9/29)]

Can we please get some feedback on this so we can do a patch?

Comment 18

[Mike Kaply [:mkaply] (Out until 9/29)]

I've done some more debugging on the best place to fix this, and I think the answer is in URLBarSetURI:

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#2342

The problem with doing it on a timeout or any mechanism like that is that it breaks the flow of "open new tab and immediately start typing"

By selecting in URLBarSetURI if it is a new tab URL, it works as expected.

Also, custom new tab pages can't steal the URL (for instance, if you set google or yahoo as the new tab URL, focus still stays in the URL bar)

Comment 19

[bintoro]

I apologize if this discussion has been had before, but why exactly is opening a new tab supposed to cause the focus to behave any differently from when a new window is opened?

I would argue that the URL bar should only get focus when it's blank (the way it works with new windows and browser.startup.homepage).

If I'm reading the previous comments correctly, it is by design that the URL bar in a new tab is now getting focus even if browser.newtab.url is set to a custom URL. I fail to understand why. If a user sets browser.newtab.url to google.com, presumably they would like the browser to respect the attempt by the page to automatically focus on the search box. As it stands this isn't happening.

Interestingly, the HTML5 autofocus attribute on an input field does succeed in stealing focus in the new tab case, so I wonder what the intended behavior really is. Some comments here seem to imply that a page is supposed to be able to control the focus, while others are suggesting the opposite.

Comment 20

[Mike Kaply [:mkaply] (Out until 9/29)]

The issue is not focus, the issue is selection.

When a user opens a new tab, they need to be able to type a URL immediately (assuming the page doesn't steal focus).

The way the behavior is today is that if a user sets a custom new tab page, when they open a new tab no text is selected and the cursor is at the end of the URL.

So if they type a URL and press enter, it's attached to the end of the new tab URL and doesn't work.

Comment 21

[bintoro]

I understand what the bug is about; I was proposing a simple design change as a solution. Let me explain why the focus business is related.

To reiterate, I was calling into question the decision to give focus to the URL bar even when it's not empty. Simply duplicating how a new window behaves w.r.t. focus would eliminate the bug at hand, as there would never be any text to select.

But I suppose it's a conscious design decision. I just don't see a persuasive case for it because all it does is free you from having to hit cmd+L every once in a while *if* you have edited the browser.newtab.url pref.

Comment 22

[[e-mail]]

As mkaply described, this is the newtab behavior I'm after.

Flow
1. Ctrl+T - Newtab
2. Newtab opens with the following concurrent events.
 2a. Homepage or newtab homepage loads.
 2b. Cursor focused address bar && value select all.

Purpose
To enable users to immediately type in search terms or addresses upon availability of address bar on the completion of a new tab creation. There should be no need to doubleclick, set clickSelectsAll (Which only saves 1 click, but not the majority of the action), or hit [Ctrl+A].

Example keystrokes
[Ctrl+T], "Do they like it? Do they want it? If they had a voice would they, would they rather not?"

People are extremely picky about their computing environments - options are necessary.

Comment 23

[:Gavin Sharp [email: [e-mail]]]

I can't reproduce this. What are the STR exactly? I tried:

1) Set browser.newtab.url to http://gavinsharp.com
2) Open a new tab

Expected: Location bar is blank, focused
Actual: Location bar is blank, focused

Comment 24

[Dão Gottwald [:dao]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #23)
> I can't reproduce this. What are the STR exactly? I tried:
> 
> 1) Set browser.newtab.url to http://gavinsharp.com
> 2) Open a new tab
> 
> Expected: Location bar is blank, focused
> Actual: Location bar is blank, focused

This seems to "work" by accident. It's also half-broken: switching tabs back and forth shows the URL.

I don't see why the location bar would be blank by reading the code. It would be good to know what caused this behavior.

Comment 25

[Mike Kaply [:mkaply] (Out until 9/29)]

Yeah, something else must have broke.

The URL bar with new tab is only supposed to be blank if it is an about URL.

If it's a web page, it's always supposed to show in the URL bar (at least that's my understanding).

Comment 26

[:Gavin Sharp [email: [e-mail]]]

(In reply to Michael Kaply (mkaply) from comment #25)
> The URL bar with new tab is only supposed to be blank if it is an about URL.
> 
> If it's a web page, it's always supposed to show in the URL bar (at least
> that's my understanding).

I don't think I agree, though I can't say I feel very strongly. We're dealing with an uncommon case.

Comment 27

[Ben Bucksch (:BenB)]

I think it's nice to show the webpage to the user. Both to notify him that it's not a local page (and that's why it's slow), and to show him where he is, to make it consistent with normal webpages.

Pages that we part of the app or extension (about:, chrome: URLs) should not show. Chrome URLs are internal technical details not relevant to the end user.

Either way, the user must be able to easily type a URL to visit after opening a new tap, without having to first select the newtab URL, no matter whether it's chrome or http.

Comment 28

[Mike Kaply [:mkaply] (Out until 9/29)]

> I don't think I agree, though I can't say I feel very strongly. We're dealing with an uncommon case.

You don't believe it will be common for users to set their new tab page to a page on the web?

I think that once people figure out they can do it, it will be quite common. The current page is rather useless.

But the reason you want to show the URL is because of spoofing. If we don't show the URL, a malicious extension could set the new tab page to look like a regular web page with a login (google or something) and the user would not be able to look at the URL and tell that it was not a real google site.

Comment 29

[Ben Bucksch (:BenB)]

Really malicious extensions can grab passwords anyway. I think more about, let's say, "commercial" extensions.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

(In reply to Michael Kaply (mkaply) from comment #28)
> You don't believe it will be common for users to set their new tab page to a
> page on the web?

Yes, exactly. The preference has no preferences UI, therefore it will be very rarely modified from its default value. We don't have any plans to expose this preference.

"Malicious extensions could cause spoofing issues" is a silly argument, because malicious extensions could do much worse things, as Ben notes. Not-malicious extensions running into this inadvertently seems relatively unlikely too.

Comment 31

[Ben Bucksch (:BenB)]

Well, we're a nice extension, and we want to provide the best UI for the end user. And I think what I outlined in comment 27 is the best and natural thing for the end user.

Comment 32

[:Gavin Sharp [email: [e-mail]]]

That's why this bug is still open! :) I agree, the behavior described in comment 27 would be best.

Comment 33

[Ben Bucksch (:BenB)]

Ah, great, thanks! This is the answer to comment 17 that we were looking for.
We'll make a patch.

Comment 34

[Mike Kaply [:mkaply] (Out until 9/29)]

There is a patch.

Dao said that the patch wasn't valid because the URL bar should always be empty on new tab (that's what this discussion is about).

Comment 35

[Dão Gottwald [:dao]]

(In reply to Michael Kaply (mkaply) from comment #34)
> There is a patch.
> 
> Dao said that the patch wasn't valid

It's too much of a hack (e.g. the DOMContentLoaded listener it uses). The problem isn't what it tries to solve but how it tries to solve it.

> because the URL bar should always be
> empty on new tab (that's what this discussion is about).

I was mostly thinking of chrome pages there. Add-ons can populate gInitialPages, so as opposed to what Ben suggested, we don't need to automatically add the new tab page's URI.

Comment 36

[Dão Gottwald [:dao]]

(In reply to Dão Gottwald [:dao] from comment #24)
> (In reply to :Gavin Sharp (use [e-mail] for email) from comment
> #23)
> > I can't reproduce this. What are the STR exactly? I tried:
> > 
> > 1) Set browser.newtab.url to http://gavinsharp.com
> > 2) Open a new tab
> > 
> > Expected: Location bar is blank, focused
> > Actual: Location bar is blank, focused
> 
> This seems to "work" by accident. It's also half-broken: switching tabs back
> and forth shows the URL.
> 
> I don't see why the location bar would be blank by reading the code. It
> would be good to know what caused this behavior.

This appears to be a regression from bug 724599: we only call URLBarSetURI if !isTabEmpty(this.mTab), and isTabEmpty depends on isBlankPageURL.

Comment 37

[Dão Gottwald [:dao]]

(In reply to Dão Gottwald [:dao] from comment #36)
> This appears to be a regression from bug 724599: we only call URLBarSetURI
> if !isTabEmpty(this.mTab), and isTabEmpty depends on isBlankPageURL.

Or maybe not, as that was about cancelled loads. Bug 725200 looks more likely.

Comment 38

[Dão Gottwald [:dao]]

Attachment: patch

This needs bug 764971 such that we keep hiding progress indicators for about:newtab but show them for remote URIs.

Comment 39

[Ben Bucksch (:BenB)]

-            if (uriIsNotAboutBlank) {
+            if (!uriIsAboutBlank) {

For me, it makes no sense to special-case about:blank.

Is there any reason to ever show chrome: or resource: URLs to the end user in the URLbar? I don't think there is. They are implementation details and the end user can't do anything useful for them.

OTOH, them showing up really does disturb for most use cases in extensions. Unlike dao, I do not think that adding URLs to gInitialPages is a particularly good API.

Comment 40

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 728259 [details] [diff] [review]
patch

Review of attachment 728259 [details] [diff] [review]:
-----------------------------------------------------------------

The patch looks good but I think we should probably go with "adding" the newtab URL to gInitialPages automatically.

I get that we don't necessarily need to do that but from an add-on author's POV it's quite beneficial to not have to register a window watcher (or observer) to add my page to gInitialPages for every browser window out there. Instead of actually adding it to gInitialPages we should rather have a |isInitialPage()| function that behaves like |isBlankPageURL()|. We additionally would also need to check that the newtab URL is not remote (like in bug 764971?).

Comment 41

[Mike Kaply [:mkaply] (Out until 9/29)]

(In reply to Tim Taubert [:ttaubert] from comment #40)
> The patch looks good but I think we should probably go with "adding" the
> newtab URL to gInitialPages automatically.

That won't work. If we add an http URL to ginitialPages, any time the user goes to that URL, the URL bar would be blank.

And the goal of this bug is that any page set as the new tab page would end up with focus in the URL bar with the text selected.

Or are you saying that for remote pages, don't have this behavior?

Comment 42

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Michael Kaply (mkaply) from comment #41)
> Or are you saying that for remote pages, don't have this behavior?

Yes, I didn't mean to actually add it. I clarified my thoughts in the second paragraph.

Comment 43

[Mike Kaply [:mkaply] (Out until 9/29)]

(In reply to Dão Gottwald [:dao] from comment #37)
> (In reply to Dão Gottwald [:dao] from comment #36)
> > This appears to be a regression from bug 724599: we only call URLBarSetURI
> > if !isTabEmpty(this.mTab), and isTabEmpty depends on isBlankPageURL.
> 
> Or maybe not, as that was about cancelled loads. Bug 725200 looks more
> likely.

Did you open a bug for this regression?

Comment 44

[Tim Taubert [:ttaubert] (inactive)]

Attachment: part 1 - turn gInitialPages into a Set

Comment 45

[Tim Taubert [:ttaubert] (inactive)]

Attachment: part 2 - hide the URL for local new tab pages

This patch works but there are (at least) two problems left:

1) If one has "http://www.mozilla.org/" as a new tab page it will be selected after opening a new tab. As soon as the page redirects though the redirect target will be displayed in the URL and will not be selected.

2) If you set a local file (or any other local resource URL) to be your new tab page it will work as expected but the URL will never be displayed in the location bar. No matter if you hand-typed it or clicked a link (I didn't try the latter but I don't see why this should work).

Comment 46

[Matthew N. [:MattN]]

Mass-move to Firefox::New Tab Page.

Filter on new-tab-page-component.

Comment 47

[sebboh (use needinfo)]

Hello!  I know that I'm a couple years late to this conversation.. but here goes!

I used about:config to set browser.newtab.url=file:///d:/projects/navi/navi.html

navi.html contains a few hundred li tags, each one with a link.  The links are special, each one runs a script--but that's not important.

There is a textbox at the top of the page and some javascript which filters the collection of li down to only those links which match the keywords I provide.  So, I type "PROD conf diff" and now there are only a few magic script links to choose from and I can easily determine if there are differences between some particular config files on particular machines.  Woot!

The only downside is that I have to press TAB a couple extra times to get my caret into the textbox.  I tried this:

    window.onload = function() {
      document.getElementById("searchbox").focus();
    };

...and this:

    <input id="searchbox" class="search" placeholder="Search" autofocus="autofocus" />

...and I also tried searching about:config for the keyword focus.

I hope this makes my usecase clear. :)

Also, for what it is worth, you could probably just never hide anything in the address bar.  I also disabled searching in mine...  Address bars are for displaying or entering addresses.  Even about: or chrome: addresses.  Just my opinion.  Keep up the good work!

Comment 48

[Mike Kaply [:mkaply] (Out until 9/29)]

browser.newtab.url doesn't exist anymore, so this bug doesn't apply.