1426058 - With a custom new-tab URL, opening a new tab focuses the address bar but does not select the text

Status: NEW

(WebExtensions :: Frontend, defect, P3)

Description

[Tony]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171206182557

Steps to reproduce:

1. Start Firefox
2. Press Ctrl+T or manually click the + button to open a new tab


Actual results:

After a new tab is opened, cursor focus is put on the address bar at the beginning but the text in the address bar does not highlight. So, if my new tab homepage is https://mozilla.org and I then open a new tab and immediately type a search for example "apples", the address bar ends up reading "appleshttps://mozilla.org".


Expected results:

One of two behaviors would be acceptable:
1. When opening a new tab, don't place focus in the address bar. So then in that case a user would have to click on the address bar manually which would highlight the current address and they could start typing which will automatically replace the highlighted text with their search. (e.g. the text https://mozilla.org would be highlighted and replaced with "apples" when the user starts to type, much like it currently does if a user clicks on the address bar in an existing tab)
-OR-
2. When opening a new tab, continue to place the cursor focus on the address bar but if a user starts to type then automatically delete the existing address the moment the user starts typing "apples".

Comment 1

[Drew Willcoxon :adw]

• Two ways to reproduce:
  • An extension like New Tab Override
  • Use the API directly e.g. in the browser console: AboutNewTab.newTabURL = “https://nytimes.com”
• Open a new tab, the caret is at the end, and the URL is not selected at all.
• Dependency: We need UX input before we start working on this bug.
  • We need to get in touch with Henry Moseti on how we should move forward?

I agree with comment 0 about the two possible approaches. Since custom new tab URLs are only exposed to users via webextensions, it's possible to fix this completely on the webextensions side by giving extension authors the ability to select or unfocus the urlbar. However, bug 1409675 is about allowing extensions to select the URL and it was wontfixed. We may want to revisit that decision with the webextensions team in light of this bug.

If this isn't fixed on the webextensions side, then we can fix it on our side (urlbar in Firefox). In that case we need to determine which approach in comment 0 we want to take: (1) not focusing the input when opening a new tab with a custom URL, or (2) focusing and selecting the URL when opening a new tab with a custom URL. A couple of relevant notes:

• When opening a new window with a custom new-window URL, the urlbar is not focused.
• However, when opening a new tab without a custom new-tab URL, the urlbar is focused.

Which behavior do we want to be consistent with here?

Comment 3

[Stephanie Cunnane [:scunnane]]

I just had a product-focused discussion with Henry Moseti re: whether we'd like to:

1. not focus the URL bar upon opening a custom new tab URL (focusing the web content instead)
   OR
2. focus the URL bar upon opening a custom new tab URL and select the URL text

Henry said we'd definitely want to go with option 2. This is much more aligned with the goal of always directing users to the address bar.
Knowing this, Drew, can you confirm that it makes sense for us to fix this on the address bar side, rather than the web extensions side?

Comment 4

[Drew Willcoxon :adw]

Yes, in that case it makes sense for us to fix this on the address bar side. The urlbar is at least being focused, so we can start from there. There's a UrlbarInput.select() method that selects all the text inside the input, and that's the first thing that comes to my mind. Something should be calling that method at some point, either the urlbar itself or whatever caller is focusing the urlbar after a new tab is opened. The former makes more sense to me at a glance since the urlbar is already correctly receiving focus, but maybe not.

You can start by breaking on _on_focus() or by adding a console.trace() call to it to see who's focusing the urlbar when a new tab is opened. You can also try the same with select() to see if it's already being called but not working properly.

There may be a timing issue (or multiple issues) where select() is being called too early, or where the URL isn't being put into the input until the page loads, or something similar, I don't know. I noticed while debugging this just now that the URL sometimes doesn't appear at all after opening a new tab. When I set AboutNewTab.newTabURL = "https://www.mozilla.org/en-US/", the URL doesn't appear, but it does appear with AboutNewTab.newTabURL = "https://nytimes.com/". I don't know if that's an intermittent problem or what, but it's something to investigate.

Comment 5

[Stephanie Cunnane [:scunnane]]

Today I'm noticing different cursor placement compared to yesterday.

Yesterday's behavior: when I opened a custom new tab URL, the address bar was focused, URL text not selected and cursor at the END of the URL
Today's behavior: when I open a custom new tab URL, the address bar is focused, URL text not selected and cursor at the BEGINNING of the URL

Update: after some investigation, I see that this change in behavior is due to Daisuke's patch that just landed a few hours ago (1767053).

Comment 6

[Stephanie Cunnane [:scunnane]]

Per Drew's observation in the last paragraph of comment 4, when I explicitly assign AboutNewTab.newTabURL, sometimes the URL text appears in the address bar and other times the URL text is NOT plugged into the address bar (and the address bar just shows its usual placeholder text).

Here is a sampling of new tab URLs where the URL text IS plugged into the address bar (though the text is not selected):
AboutNewTab.newTabURL = "https://nytimes.com" - cursor at end of URL text
AboutNewTab.newTabURL = "https://yale.edu" - cursor at end
AboutNewTab.newTabURL = "https://harvard.edu" - cursor at end
AboutNewTab.newTabURL = "https://youtube.com" - cursor at beginning OR end
AboutNewTab.newTabURL = "https://amazon.com" - cursor at end OR beginning

And here is a sampling of new tab URLs where the URL text is NOT plugged into the address bar at all:
AboutNewTab.newTabURL = "https://web.mit.edu/"
AboutNewTab.newTabURL = "https://www.ucla.edu/"
AboutNewTab.newTabURL = "https://www.lego.com/en-us"
AboutNewTab.newTabURL = "https://www.mozilla.org/en-US/"
AboutNewTab.newTabURL = "https://connect.mozilla.org/"
AboutNewTab.newTabURL = "https://theuselessweb.com/"
AboutNewTab.newTabURL = "https://binarypiano.com/"
AboutNewTab.newTabURL = "http://corndog.io/"
Note that for this second group, even when the page is refreshed, the URL text is still not plugged into the address bar, and the address bar still displays its usual placeholder text.

Though I'm not yet sure what distinguishes one group from the other, I've tested these a few times over several days, and whichever group a website falls into, it has consistently fallen into that group, no switching between groups.

Comment 7

[Drew Willcoxon :adw]

I'm guessing it has to do with how long it takes the page to load. There's probably a race condition (or multiple!) somewhere. Regardless, it seems like a separate issue that should probably have its own bug, and we should focus in this bug on doing option 2 when the URL actually manages to be plugged in correctly. Would you like to file a new bug for the other problem?

Comment 8

[Stephanie Cunnane [:scunnane]]

Sure, I've just filed a separate bug (1771207) for the potential race condition.

I'll keep the focus of this current bug to correctly selecting the URL text in the address bar when the user opens up a custom new tab.

Comment 9

[Stephanie Cunnane [:scunnane]]

Attachment: Bug 1426058 - WIP - Ensure opening a custom new tab URL selects URL text. r?adw

Comment 10

[Stephanie Cunnane [:scunnane]]

I've done extensive investigation into this bug and worked with Drew to figure out what's going on. We've concluded that this is something that should be handled on the WebExtensions side, rather than the URL bar side.

From Drew:

I was thinking there is some way to get the final intended new-tab URL so we could compare it to the urlbar’s value to know when we should re-select the urlbar, but there’s not. How is the urlbar supposed to know that an extension loaded a page that is intended to be the user’s new-tab page? The urlbar can know that the moz-extension page is AboutNewTab.newTabURL — it can tell the page is technically the “new tab” page — but after that, the extension is free to load any page it wants at any time, and there’s no way for the urlbar to know if/when a page is the intended new-tab page.

I don’t think this is a urlbar bug after all. It’s an extensions bug. The extensions API needs to either provide the extension a way to select the urlbar, or it needs to let the extension specify the final intended new-tab page so that the urlbar can know what it is.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The following patch is waiting for review from an inactive reviewer:

ID	Title	Author	Reviewer Status
D150041	Bug 1426058 - WIP - Ensure opening a custom new tab URL selects URL text. r?adw	scunnane	adw: Back Aug 6, 2022

:scunnane, could you please find another reviewer?

For more information, please visit auto_nag documentation.

Comment 12

[arbitrarytrajectory]

Glad to hear this is being addressed! I recently switched back to Firefox after years away and one of the biggest sources of friction has been trying to use my custom HTML homepage.

(In reply to Stephanie Cunnane [:scunnane] from comment #10)

I've done extensive investigation into this bug and worked with Drew to figure out what's going on. We've concluded that this is something that should be handled on the WebExtensions side, rather than the URL bar side.

Having tried several methods, I believe this issue requires fixes on the WebExtensions and URL bar sides. Extensions do need a better approach to focusing the URL bar for the reasons outlined above. However, as it's possible to change AboutNewTab.newTabURL without an extension*, the URL bar should also select the initial URL without an extension's prompting.

*I'm currently using this clunky autoconfig method.

Comment 13

[Ryan]

Great work so far Stephanie. Just wanted to say a big thanks for all your pushing so far and to let you know I and many others will be very happy when this bug is fixed.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 8 See Also bugs.
:robwu, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 15

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 16

[lenny]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

yes it's still relevant (text is still not selected)

Comment 17

[Dão Gottwald [:dao]]

Stephanie, could you please abandon your patch in phabricator so that the bot won't think that you're still working on this?

Comment 18

[Stephanie Cunnane [:scunnane]]

Sure, I just abandoned the patch.

Comment 19

[ssgosh]

Facing the same issue with the New Tab Override extension.

Requesting info as to when/whether this bug is planned for fixing.

Comment 20

[konrad]

I am quite unhappy that this bug is still not fixed and the patch got abandoned.
It is still relevant, there are more than 5 corresponding bugs (not only those listed above, quite a large net of bugs can be found, most of them more than 5 years unfixed)

I could find issues about either setting a custom new tab url directly in firefox again, as it is possible with the home url (lots of old discussion about how to savely store the pref - 1452144/105182), improving the new tab url extensions UX, or similar bugs like this (inconsistent address bar behaviour, lost letters when typing, or, in this case, not selecting the url leading to searches like "appleshttps://mozilla.org"
For me (and, I believe, most other users of custom new tab extensions), this bug is the most annoying one. Is there any chance a new patch on this bug could be worked on?

I am personally willing to contribute, but am concerned that it will again be ignored or denied (design-decision-denied, ux input needed or so)
Remember, this is not about clearing the urlbar (which, I agree, can be a security issue), but just fixing the bar getting focus but the text not getting selected

Can anyone from mozilla work on this again, or at least state whether my concern is valid or whether it is worth for us community members to supply a patch? Thanks

Comment 21

[Faaris]

No extension should be needed to set the new tab URL. Setting a custom site for "homepage and new windows" is already possible, so why isn't the same option available for new tab pages?

Even if it can't be added to the browser, at least allow the extensions to clear the url bar, and allow them to also use local files. The only good way right now to change your new tab page to a local file is by editing system files and creating an override with AboutNewTab.newTabURL = "file:///urlhere";

Comment 22

[Sören Hentzschel]

No extension should be needed to set the new tab URL. Setting a custom site for "homepage and new windows" is already possible, so why isn't the same option available for new tab pages?

Removing the ability to set a custom new tab URL was a countermeasure against search hijacking, which was a real problem at the time. See bug 1118285 for context.

Even if it can't be added to the browser, at least allow the extensions to clear the url bar

Hiding the URL of a loaded website sounds like a security risk. This Bugzilla ticket is about selecting the text in the address bar. I think, this is the much better solution and yes, that's needed as it's a really bad user experience that you have to manually remove the URL to enter a new URL. Selecting the URL would allow to start typing directly as if the address bar were empty (without it actually having to be empty).

and allow them to also use local files

You already can use local files very easily. Simply set up a local server, which can be done in a maximum of five minutes. Then you can access your local files via http(s):// and use it like every other website.

Comment 23

[Faaris]

I understand, thanks for the info. Yeah I would probably be fine hosting a local server, and using an extension which actually allows the URL bar to be highlighted.

However it is just a little disappointing that I wouldn't have to do any of this if the url bar was just clear and I could use a local html file as normal. I understand the security risk in allowing an extension to clear the address bar, but why not the browser itself? It's a user option. At that point you could say any option in the browser is a security risk. I can already do all of this with this override AboutNewTab.newTabURL = "file:///home/faaris/.local/packages/startpage/fazzi/index.html"; which has made it easier for me.

And the thing here is that you can already do it for "homepage and new windows", the fact that the new tab page specifically is being held to a higher regard in terms of being a "security risk" is pretty strange to say the least.

Anyway, if that can't happen I completely understand, but we should at least allow the URL bar to be highlighted by extensions. It's super annoying having to clear it every time before i type.

Comment 24

[Rob Wu [:robwu]]

In comment 10 (https://bugzilla.mozilla.org/show_bug.cgi?id=1426058#c10), the conclusion is that this would have to be resolved at the WebExtensions side and not the urlbar side. After looking at the interactions here (STR below), I think that this could be solved at the urlbar side (without changes to extension APIs or extensions) by using the following logic:

• If the address bar is focused and it is empty (because of newtab), and the address bar becomes non-empty as a result of navigation, select the full URL.
  • (the problem becomes harder if the user started typing before the navigation completes; bug 1645648 tracks that general problem)

Stephanie, what do you think of the above?

STR:

1. Install https://addons.mozilla.org/en-US/firefox/addon/new-tab-override/
2. Open a new tab. The extension will redirect from /html/newtab.html to /html/options.html.
   • When /html/newtab.html is loaded, the urlbar is empy as desired.
   • After the navigation, the urlbar displays the new URL. This is reasonable.
3. Start typing. The URL bar is focused, but the URL is not selected, and consequently the result of typing query is something like querymoz-extension://6d9e5ac2-8b4e-4f93-8ff2-ff0a5a0ab798/html/options.html

The user's expectation is that if they type a query (or paste a link) and press enter, that they would be searching for what they typed, WITHOUT the moz-extension://6d9e5ac2-8b4e-4f93-8ff2-ff0a5a0ab798/html/options.html suffix.

Comment 25

[Stephanie Cunnane [:scunnane]]

Hi Rob, I'm actually not sure if that logic could be used to fix this bug on the urlbar side. Drew, do you know if Rob's idea in comment 24 is workable?

Comment 26

[Drew Willcoxon :adw]

It's hard to say without trying.

If the address bar is focused and it is empty (because of newtab), and the address bar becomes non-empty as a result of navigation

The problem is how does urlbar know that the navigation is due to an extension loading a newtab page vs. some other reason? All it knows is someone called setURI() with a certain set of arguments. There's nothing that says "hey, we're loading newtab now."

In general, it's not just a matter of fixing this bug, we also need to make sure we don't regress or unintentionally change how we handle other page loads that aren't related to newtab.

But none of that's to say we can't fix this, it's not exactly rocket science. We just need to devote some time to it -- plus buy-in from the webextensions team, if I'm right that's required, and I don't have reason to doubt what I wrote the last time I looked at this.

Comment 27

[Rob Wu [:robwu]]

(In reply to Drew Willcoxon :adw from comment #26)

It's hard to say without trying.

If the address bar is focused and it is empty (because of newtab), and the address bar becomes non-empty as a result of navigation

The problem is how does urlbar know that the navigation is due to an extension loading a newtab page vs. some other reason? All it knows is someone called setURI() with a certain set of arguments. There's nothing that says "hey, we're loading newtab now."

It does not have to know the load reason. The urlbar knows when a new tab page is displayed, because it clears the urlbar in that case.
I was thinking that something like this could work:

• When the urlbar is focused and empty (empty could be due to the page being newtab), set a flag (maybe in UrlbarInput?).
  • This flag will be cleared when any of the following happens: urlbar loses focus, urlbar value is changed by user input
• Whenever the URL changes, if the flag is set (which also implies that the urlbar is still focused), select the full urlbar content (which contains the new URL).
  • This behavior is equivalent to what happens when the urlbar is focused for the first time.
  • When a redirect occurs, the new URL continues to be selected.

With this implemented, the issue will be fixed for the STR in comment 24.

As mentioned, it does not solve the case if the user has already started typing (bug 1645648 would be the general fix for that).
If we are willing to fix this issue for when the user has started typing from the new tab page, then I can imagine a tweak to the logic above:

• The flag is not cleared when the value is changed by user input, only when the urlbar loses focus.
  • This replaces the part in the above list: "flag will be cleared (...) urlbar value is changed by user input"
• Whenever the URL changes, if the flag is set and the address bar is focused and has user input, don't change the urlbar content.

This second part seems riskier and I would split that part to a separate bug (or make it a part of bug 1645648).

:adw What do you think of the above? Would a patch with the above implementation be acceptable?

In general, it's not just a matter of fixing this bug, we also need to make sure we don't regress or unintentionally change how we handle other page loads that aren't related to newtab.

plus buy-in from the webextensions team, if I'm right that's required, and I don't have reason to doubt what I wrote the last time I looked at this.

I am from the WebExtensions team and interested in getting this fixed; I however think that this can be fixed without API changes. The benefit of fixing this without API changes is that users can benefit from the fix without requiring extension authors to update their extension.

Comment 28

[mkatich]

I also use the New Tab Override extension in Firefox, and before that, I used the standard setting for a new tab URL (which is no longer available). I use the same page (a website, not local file) for my chosen home page and new tab page. It has its own search area with a Javascript focus() text input field. So in the past I often hit the new tab button (or Ctrl-T) and immediately began typing a search query - great usability. But Firefox's functionality changed so that the cursor focuses into the browser's URL bar, and I can no longer do this. The behavior is as described above in other comments where you end up counterproductively typing in search query characters at the beginning of a URL. The focus() has no effect for new tab I guess.

I have the same URL set as my home page, and the home button enabled. When I middle-click the home button to open home in a new tab, the cursor does correctly start out in the input field. It feels odd that this behavior is different. Both methods open a new tab, but one uses a standard setting (home page) and the other uses the extension.

In Google Chrome, for example, I use the New Tab Redirect extension with the same URL for similar effect. But when I click the new tab button, the cursor correctly focuses to the input box within the chosen page.

I'm not a fan of giving up the user's ability to set a new tab URL. It's disappointing to have less functionality in this specific area than we did 20(?) years ago. But anyway, now that an extension is required to do it, I'd still prefer the cursor not start in the URL bar when my web page calls for focus. If that can't be fixed, then the less bad option would be to have the URL selected so that when I started typing it would actually erase what existed there before rather than adding to the beginning so at least I could use the default search of the browser as a backstop.

Comment 29

[Lantizia]

If Firefox focused on these much delayed and needed quality of life improvements... instead of AI nonsense... you might find a discerning public actually wanting to install Firefox again!

I agree that we should be able to have 'New Tab Override' select the existing contents in the URL bar at a minimum...
... or better yet simply allow an extension to empty the URL bar...
... or better better yet... just implement choosing your own page in Firefox itself! No need for an extension!

It's not like it'd be a convoluted or confusing thing to add, it'd just be another drop down option. All this talk of search hijacking is from the long distant past... and malware today (if they put their minds to it) can alter a Firefox profile in countless ways to do many different awful things... so what are we really protecting against here?

Because it feels like we're treating the users like idiots that can't possibly want things differently than the devs.

So I guess if you want an easy life where only sysadmins & devs use Firefox... hurrah we've arrived! But I feel the spirit that toppled IE with the comparatively better flexibility and agility of Phoenix/Firebird/Firefox... now doesn't seem to exist in an age where the problem is the bloat of Chrome and it's single minded agenda of sucking up all your data.

Give people a tangible feeling of making Firefox their own! Things like this fixing this bug will help massively!