1372996 - URLBar should be selected or clear while newtab opened with overriding

Status: VERIFIED FIXED

(WebExtensions :: Frontend, defect, P3)

Description

[YF (Yang)]

STR:
1. Install https://addons.mozilla.org/firefox/addon/groupspeeddial/ or https://addons.mozilla.org/firefox/addon/new-tab-tools/versions/beta - 82b9.
2. Open an newtab page with newtab button or Ctrl+T.


Actual results:
1. The URL is filled in the extension's raw address, and the cursor is at the end, no selected.
2. The above URL is selected if the user clicked on the newtab and then open another newtab page.


Expected results:
1. URLBar be selected to facilitate the user input to replace the original URL, this is happening if the focus in overwriting newtab page and open an newtab page.
2. Or, clear urlbar and with identity-icon-label says "This page is loaded from an extension.", it appears in my primary profile, but I cannot reproduce it with a clean profile + new-tab-tools 82b9.

Comment 1

[juraj.masiar]

In Firefox 55.0b1 (beta 64-bit) opening new tab places cursor at the end of the address - so it's actually even worse than it was in version 54 where it would select the address.

Comment 2

[Andy McKay]

I see the problem here and agree we should try and do something here. Normally when you open a new tab the URL bar is focused. When you override about:newtab and about:home the URL bar is populated with the moz-extension URL.

Also I'll note that the identity dialog isn't populated (I'll file a seperate bug for that).

My ideal world is that the identity dialog is populate and the URL bar is empty.

Would that be acceptable Markus?

Comment 3

[Andrew Moff]

I too think we should hide the ugly "moz-extension" address in the address bar in the same way chrome does, this allows the user to CMD/CTRL + T and then start typing immediately; most legacy [new tab] extensions depends on this ability.

Also the user should have to give permission for the extension to be able to hijack control of the new tab page and be able to switch between conflicting extensions and the default new tab page in general preferences?

Comment 4

[Blake Winton (:bwinton) (:☕️)]

As a temporary fix, would we accept a patch that selected the moz-extension url, so that "<ctrl-t> then just start typing" could work again…

Comment 5

[juraj.masiar]

That would be good enough. Is it possible to make it in release 55?

Comment 6

[Markus Jaritz [:designakt] (UX)]

Attachment: Chrome_NewTabOverride_03.PNG

(In reply to Andy McKay [:andym] from comment #2)
> I see the problem here and agree we should try and do something here.
> Normally when you open a new tab the URL bar is focused. When you override
> about:newtab and about:home the URL bar is populated with the moz-extension
> URL.
> 
> Also I'll note that the identity dialog isn't populated (I'll file a
> seperate bug for that).
> 
> My ideal world is that the identity dialog is populate and the URL bar is
> empty.
> 
> Would that be acceptable Markus?

This would be acceptable if we have the user confirm that they really want this override, like Chrome does.
Chrome applies the override, but asks the user to confirm it the first time they see it. To ask for confirmation, they open a doorhanger off of the extensions toolbar button. (See attachment.) If the user does not act on it, this doorhanger will be shown again on the next encounter of that page after a restart.
(In our case we could anchor this doorhanger off of the Firefox menu if the extension does not have a toolbar button.)

I will need to check the copy for that dialog, and I can mock it up in our design, if needed.

(In reply to Blake Winton (:bwinton) (:☕️) from comment #4)
> As a temporary fix, would we accept a patch that selected the moz-extension
> url, so that "<ctrl-t> then just start typing" could work again…

Sounds good.

Comment 7

[Blake Winton (:bwinton) (:☕️)]

Attachment: A terrible way to hide the url…

Based on some older ActivityStream code[0], this is sort of a terrible idea, _but_ it does work, kinda, so might point the way to something better for whomever eventually takes this bug.  (Maybe a easier way to hook into `window.gInitialPages`?  Or change `window.gInitialPages` into a object which asks the WebExtension code what other pages should be hidden or something?  I dunno…)

[0] https://github.com/mozilla/activity-stream/blob/d6c0aed3abcb83305564ccd0b5c73ba2fefb1815/addon/AppURLHider.js

Comment 8

[Caitlin Neiman [:caitmuenster]]

Hi YF, this has been added to the agenda for the July 18 WebExtension APIs triage meeting. Would you be able to join us? 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

Agenda: https://docs.google.com/document/d/1gWszBunGAyOJ_V8_HMECXJuZ4Gd_HTM_M7xjDSwSxeo/edit#

Comment 9

[YF (Yang)]

(In reply to Caitlin Neiman (http://pronoun.is/she) from comment #8)
> Hi YF, this has been added to the agenda for the July 18 WebExtension APIs
> triage meeting. Would you be able to join us? 
> 
> Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting
> 
> Agenda:
> https://docs.google.com/document/d/
> 1gWszBunGAyOJ_V8_HMECXJuZ4Gd_HTM_M7xjDSwSxeo/edit#

Sorry, I don't like meeting because talking ways.

Also, I am a little curious, this bug is not an API request, it fits this meeting?

Comment 10

[Caitlin Neiman [:caitmuenster]]

Hi YF -- no worries at all; we will be sharing live updates from the meeting in the IRC channel #addons if you would like to follow along. 

Since this bug involves a feature or change in Firefox, we would like to discuss it at the triage meeting. :)

Comment 11

[Andy McKay]

There was support for this in the meeting, as long as its still really clear that the page comes from an extension. We have exposed that the page comes from an extension by adding this into the identity part of the URL bar, we'll also be landing that the about:newtab has been changed in about:preferences so it feels like we've got that covered.

The first step of just highlighting the URL text so a user can start typing straightway would be a nice stop gap until we get a better fix in.

Comment 12

[Sören Hentzschel]

(In reply to Blake Winton (:bwinton) (:☕️) from comment #4)
> As a temporary fix, would we accept a patch that selected the moz-extension
> url, so that "<ctrl-t> then just start typing" could work again…

Could you please implement at least this workaround soon? It's really needed for all new tab extensions and if you add all user numbers these add-ons have a lot of users. So it would be great to support the "open a new tab and start typing" use case as soon as possible. I guess it's already too late for Firefox 55 but I still hope for a fix in Firefox 56. Of course, an empty url bar would be better but more important is that users can immediately start typing so it would be good enough for me to implement this workaround now and implement a better solution at at later point.

(In reply to YF (Yang) from comment #0)
> Actual results:
> 1. The URL is filled in the extension's raw address, and the cursor is at
> the end, no selected.

hm… for me the cursor is always at the *beginning* of the url, not at the end.

Comment 13

[Sören Hentzschel]

ni? :andym for comment 12.

Comment 14

[Andy McKay]

Unfortunately its unlikely to happen for Firefox 57.

Comment 16

[juraj.masiar]

(In reply to Andy McKay [:andym] from comment #14)
> Unfortunately its unlikely to happen for Firefox 57.

There are hundreds of thousands of people using some add-on overriding New tab page.
In 57 they will migrate to different add-on with similar functionality.
...seems like there will be A LOT of **** people here soon!


PS: please, for the sake of understanding what is happening here, try to use some add-on build with webextension API overriding New tab page for a ONE whole day

Comment 17

[[e-mail]]

Hi everybody,

My name is Marc, I m saying things that have been already said in this discussion. I also posted this message in that thread that is linked : https://bugzilla.mozilla.org/show_bug.cgi?id=1322304. As a creator of a newtab extension, I think it is a very urgent and important situation that will kill the work and efforts of hundreds of people that work for Firefox to create nice newtab extensions and might lead to millions of unhappy Firefox users.

Here are the two urgent issues.

1- There is a major bug in the version 55 of Firefox : when a user open a newtab, the user has first to select the content in the URL adress bar before to start a search. Nobody could use a newtab extension in this condition, and everybody will disable it or migrate to another browser. At this point we ask ourselves if we might not migrate our users to another browser (which represents around 100 000 users) if the bug is not quickly solved and it might be the same for the millions of users that uses newtab extension on firefox.

We have to find a solution quickly. Do you know if this bug will be corrected before the stop of legacy extensions ? If not how can we help Firefox to correct it in a quickest way ?
=> we can code a patch for example, or we can ask money from our users, to help Firefox finance this development, etc ...


2- There is a discussion about the dirty url that is displayed. To my mind, I agree that the name of the extension could be displayed, but not in a such dirty way that could also lead to massive uninstall of the newtabs extension. I think for the moment, that the behavior of Chrome could be adopted, to let time to find another solution if needed.

I would like also to point out that, Firefox has their own newtab page and it would be fair not do disavantage other newtab pages with degraded user experience. I think that overall, everyone of us (firefox and people working for firefox by coding newtab extensions) are all going to lose if we can't have a good user experience for newtab extension because users will migrate to another browser if they can't find the same quality of service.

So to put it in a nutshell, how can we help to move quickly on that subject ?
Is someone know the number of version that will correct these 2 bugs ?

Marc.

Comment 18

[Markus Jaritz [:designakt] (UX)]

Hi Marc, thank you for your comment. I am aware that this is an important issue as a url in the awesomebar on newTab pages heavily impacts the user experience of those people.

We are working on this. I have missed to update the UX in the bug, but have talked to engineers about it, and we are working on implementing the same behavior Chrome uses on newTab pages.

Here you can see the dialog users will see when they first encounter the new newTab page:
https://mozilla.invisionapp.com/share/6HCITJKP8#/screens/244736434
It show the url until the user confirms the change, after that, users will have an empty URL bar, but still see the identity box, to know that that page is provided by an extension.
(If users ignore the panel, they will see it again upon seeing the next newTab after a restart.)

(please refrain from posting the same content in multiple places, but stay on focus in each but, and refer to the other if needed.)

Comment 20

[vincent]

Hi Markus,
Thanks for your link. I really appreciate this proposal.  
Did you know if it will be included into Firefox 56? Or should we wait Firefox 57 or higher?
With the end of Legacy Extension with Firefox 57, I hope we can have it for Firefox 56 has it seems to be our last chance to assure a smooth transition for newtab users.

Comment 21

[Markus Jaritz [:designakt] (UX)]

(In reply to vincent from comment #20) 
> Did you know if it will be included into Firefox 56? Or should we wait
> Firefox 57 or higher?

Sorry, I don't know the exact timeline for this, but the assignee might.

Comment 22

[Mark Striemer [:mstriemer]]

Attachment: Bug 1372996 - Clear the URL bar when on ext newtab

Review commit: https://reviewboard.mozilla.org/r/176906/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/176906/

Comment 23

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8905094 [details]
Bug 1372996 - Clear the URL bar when on ext newtab

https://reviewboard.mozilla.org/r/176906/#review181908

::: browser/base/content/browser.js:306
(Diff revision 1)
>    "about:sessionrestore"
>  ];
>  
> +function isInitialPage(url) {
> +  return isBlankPageURL(url) || gInitialPages.includes(url);
> +}

This causes a couple about pages to be checked twice.  How about:

gInitialPages.includes(url) || url == BROWSER_NEW_TAB_URL

::: browser/base/content/test/urlbar/browser_urlbarAboutHomeLoading.js:112
(Diff revision 1)
> +/**
> + * Ensure we don't show the extension URL in the URL bar temporarily in new tabs
> + * while we're switching remoteness (when the URL we're loading and the
> + * default content principal are different).
> + */
> +add_task(async function dontTemporarilyShowAboutExtensionPath() {

While it makes sense for the test to be here, currently all webextension tests live under a webextensions path.  Lets keep it that way, move this to  browser/components/extensions/test/browser/browser_ext_url_overrides_newtab.js

::: browser/base/content/test/urlbar/browser_urlbarAboutHomeLoading.js:121
(Diff revision 1)
> +  let extension = ExtensionTestUtils.loadExtension({
> +    manifest: {
> +      name: "Test Extension",
> +      applications: {
> +        gecko: {
> +          id: "@newtab",

I have a preference for [e-mail], but not a big deal

::: browser/base/content/test/urlbar/browser_urlbarAboutHomeLoading.js:138
(Diff revision 1)
> +
> +  await extension.startup();
> +  await windowOpenedPromise;
> +
> +  let promiseTabSwitch = BrowserTestUtils.switchTab(win.gBrowser, () => {});
> +  await windowOpenedPromise;

Opening the new window and this switchTab call dont seem to add anything to the test, lets remove those.  You can then just use gBrowser for the current window.

::: browser/base/content/test/urlbar/browser_urlbarAboutHomeLoading.js:148
(Diff revision 1)
> +    },
> +  };
> +  win.gBrowser.addProgressListener(wpl);
> +
> +  win.BrowserOpenTab();
> +  await promiseTabSwitch;

You should be able to just use 

tab = await BrowserTestUtils.openNewForegroundTab(gBrowser) 

and await BTU.removeTab(tab) at the end.  Also tab.linkedBrowser in the spawn call.

Comment 24

[Mark Striemer [:mstriemer]]

Comment on attachment 8905094 [details]
Bug 1372996 - Clear the URL bar when on ext newtab

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/176906/diff/1-2/

Comment 25

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8905094 [details]
Bug 1372996 - Clear the URL bar when on ext newtab

https://reviewboard.mozilla.org/r/176906/#review183382

Comment 26

[Mark Striemer [:mstriemer]]

Comment on attachment 8905094 [details]
Bug 1372996 - Clear the URL bar when on ext newtab

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/176906/diff/2-3/

Comment 27

[Mark Striemer [:mstriemer]]

Comment on attachment 8905094 [details]
Bug 1372996 - Clear the URL bar when on ext newtab

https://reviewboard.mozilla.org/r/176906/#review183596

::: browser/base/content/browser.js:2770
(Diff revision 3)
>        }
>      }
>  
>      valid = !isBlankPageURL(uri.spec) || uri.schemeIs("moz-extension");
> +  } else if (isInitialPage(value) &&
> +             checkEmptyPageOrigin(gBrowser.selectedBrowser)) {

There were some test failures on try that I didn't get locally because of an exception. `value` was being passed to `checkEmptyPageOrigin` here as a string. Omitting the argument will pull it from `browser.currentURI` instead and I no longer see the exception locally.

Comment 28

[Mark Striemer [:mstriemer]]

Comment on attachment 8905094 [details]
Bug 1372996 - Clear the URL bar when on ext newtab

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/176906/diff/3-4/

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f2d3bce7e6dc
Clear the URL bar when on ext newtab r=mixedpuppy

Comment 30

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f2d3bce7e6dc

Comment 31

[Sören Hentzschel]

Hi Mark,

so this only works with a static override of the new tab page via manifest and not if an add-on overrides the new tab page dynamically (via browser.tabs.update()), is that correct? I am asking because with the current Nightly and New Tab Override nothing changed. Where can I follow the implementation of a solution which is working for add-ons like New Tab Override?

Comment 32

[Mark Striemer [:mstriemer]]

I don't think we have any plans to update that. If this is something you would like then you can file a bug and we can discuss it but I would guess we don't want to allow clearing arbitrary URLs from the address bar.

You may be able to come up with a different solution that works with this, for example loading the page in an iframe if that option is set instead of redirecting.

Comment 33

[Sören Hentzschel]

That's surprising because it makes most new tab add-ons useless… it affects a few hundred thousand users of such add-ons… Without a solution for this problem users have to manually clear the address bar on every (!) new tab. My understanding of this ticket was that there will be a solution. At least something like

> The first step of just highlighting the URL text so a user can start typing straightway would be a nice stop gap until we get a better fix in.

(comment 11)

Comment 34

[Mark Striemer [:mstriemer]]

But before that sentence is this:

> There was support for this in the meeting, as long as its still really clear that the page comes from an extension. We have exposed that the page comes from an extension by adding this into the identity part of the URL bar

Once you update the page using `browser.tabs.update()` it is no longer clear that this page is coming from an extension, and I think it no longer meets our criteria for clearing the address bar.

I think what you want should be possible using an iframe which would still show that this is a page generated by an extension and clear the address bar.

Comment 35

[Mark Striemer [:mstriemer]]

I admit that it would be nice to have the address bar selected instead of having the cursor at the beginning of the line. If that's something you want then you can file a bug for that.

Here's the extension [1] that I've been using to test this, though. Something like that should give you a decent solution, but I'm not sure it would work in every case and from a security standpoint redirecting the page is likely better.

[1] https://github.com/mstriemer/chrome_settings_overrides

Comment 37

[CosminB]

Attachment: Momentum.gif

I installed Momentum extension v0.98.1  on Firefox 57.0b12 (20171026211016) and Firefox 58.0a1 (20171026221945) under Wind 7 64-bit and I can observe that the behavior mentioned in comment 6 and comment 18 is not present after the install. 

Is this expected?

Please see the attached video.

Comment 38

[Mark Striemer [:mstriemer]]

This looks right, I think the new tab page is stealing focus from the address bar so it isn't selected.

Comment 39

[juraj.masiar]

This could be related also to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1411209
where focus is also on the page when first instance of Firefox is opened.

Comment 40

[CosminB]

Attachment: Bug1372996.zip

Thanks Mark Striemer!

I can reproduce this issue on Firefox 56.0.2 (20171024165158) under Wind 7 64-bit.

This issue is verified as fixed on Firefox 57.0b12 (20171026211016) and Firefox 58.0a1 (20171026221945) under Wind 7 64-bit and Mac OS X 10.13.

The name of the extension is displayed in the URL bar and the empty address bar is focused when opening a new tab.

Please see the attached video.

Comment 41

[Mark Striemer [:mstriemer]]

I went through the register flow with this add-on and it focuses the URL bar after that, as expected.

Comment 42

[Jonathan]

Hello,

I would like to use a webpage (my homepage, actually) as my new tab page. While not a problem for some websites, the iframe solution will not work for websites that block iframes. Please highlight the address bar.

Also, it would be super nice if there were an about:config option to hide the url entirely, to allow power users to clean up their firefox and avoid distractions when opening a new tab.

Comment 43

[Daniel]

ISSUE DETAILS:
Upon loading a newtab whereas my custom page is set as https://www.google.com/ncr the cursor doesn't select the urlbar/address bar and text therein thus making the setup the most optimal way to type a new URL or search query from the URLBAR upon start/run of a new tab.

CURRENT STATUS: Issue still prevalent in Firefox 58.0.2 x64.


It's been quite a while since these reports have been posted, Is there going to be a fix to this?

I too have made a bug report located at 1442899
BUg report was made before this report (1372996) was found, apologies for the secondary bug report, maybe mine (1442899) can be amalgamated into this (1372996) one? 
Much appreciated if it can be, If not I will continue to reply and post to my report as users ask questions or require more information.

Thanks.


P.S. It's definitely not fixed if someone knows how to, if that's how this is done, change the status to NOT FIXED instead of VERIFIED FIXED.

Comment 44

[Mark Striemer [:mstriemer]]

Using a remote URL for your New Tab page is not officially supported right now. If you are using an extension to set a custom remote URL then it is handled like loading any page and the URL is present and not selected.

There are discussions going on to add a Home section to preferences and expand what is currently under General. Setting your New Tab to be your Homepage is one of the things being discussed but I cannot say for sure when or if it will be added. This specific portion is being tracked in bug 1417155.