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.