Given comment 1, I'm going to say wontfix for 64.

To add, I have a (very) basic new tab extension, and one of the pieces of feedback I get is that users would prefer that the focus moves to the awesomebar - this is especially relevant for extensions like mine because I don't replicate a search box in the extension, so if a user opens a new tab, they must manually focus the awesomebar or search bar (if enabled).

eg: https://addons.mozilla.org/en-US/firefox/addon/black-new-tab/

See also feedback like: https://twitter.com/jayatflight/status/1083548401990459392

"And the new tab thing I use is ColorTab, but all the extensions that change the page don't auto-select the url/search bar."

That we want the address bar focused in certain use cases doesn't mean that tabs.update should do this automatically as a weird side effect of some session restore code. In fact don't we have a better API specifically for changing the new tab URL?

(In reply to Dão Gottwald [::dao] from comment #4)

That we want the address bar focused in certain use cases doesn't mean that tabs.update should do this automatically as a weird side effect of some session restore code.

I have no opinion how it should work by default but we need a solution because it's a regression of WebExtension behaviour and to break the behaviour of extensions of hundred thousand users is bad (New Tab Override has ~ 100,000 users and is not the only affected add-on). And the behaviour change is not documented anywhere and was not announced via the usual channels so it also broke the assumption that Firefox updates don't break WebExtensions, at least not without an announcement for developers to prepare an update. Now my add-on has a non-functional option and I receive bug reports. The only reason I reported this bug so late to Mozilla is that I didn't have time for a few months to investigate the cause of the bug reports.

Maybe needinfo?ing someone from the WebExtension team to get their opinion?

In fact don't we have a better API specifically for changing the new tab URL?

No, there is no better API* and all requests to provide a better API for new tab add-ons were denied. We developers of such add-ons asked more than one time for improvements in this area.

*) You can specify a new tab page like google.com via the manifest but this approach is unusable if you want that the user can override the new tab page.

(sorry, itchy triage finger)

(correct NI is to mconca)

(In reply to Sören Hentzschel from comment #5)

No, there is no better API* and all requests to provide a better API for new tab add-ons were denied. We developers of such add-ons asked more than one time for improvements in this area.

The request for this API is being tracked in Bug 1460412.

Thanks, I didn't know that one, previous requests to improve the APIs for new tab add-ons were WONTFIX'ed… ;-) But anyway, that ticket was created eight months ago and I can't see any activity since eight months. I think it's fair to say that if there will be a better new tab API it won't happen in the short term (Firefox 65), right?

So the question remains: What do we do with the regression from Firefox 61? There are two options:

a) the regression will be fixed
b) the regression won't be fixed

Whatever you decide, I have to release an update for my WebExtension. I either have to remove the broken option from my WebExtension or I have to add a sentence that the broken option will be fixed by a future Firefox update. It's already broken since a few major releases so I would really appreciate if you could clarify if a) or b) is expected to happen.

Thank you!

(Oh, and maybe a test should be added so that future changes don't break the tabs API again without it being noticed. I mean, to have the focus on the address bar or the content, that' a significant difference. ;-) )

(In reply to Sören Hentzschel from comment #8)

So the question remains: What do we do with the regression from Firefox 61? There are two options:

a) the regression will be fixed
b) the regression won't be fixed

Whatever you decide, I have to release an update for my WebExtension. I either have to remove the broken option from my WebExtension or I have to add a sentence that the broken option will be fixed by a future Firefox update. It's already broken since a few major releases so I would really appreciate if you could clarify if a) or b) is expected to happen.

Thank you!

My guess is that it won't be fixed as we don't want to regress bug 1410591. If you have suggestions how to fix this without regressing bug 1410591, I'm all ears.

(Oh, and maybe a test should be added so that future changes don't break the tabs API again without it being noticed. I mean, to have the focus on the address bar or the content, that' a significant difference. ;-) )

FWIW, it only worked the way it did by accident. I don't think anybody made it intentionally that way with your use case in mind, so that's why no test existed.

(In reply to Sören Hentzschel from comment #8)

So the question remains: What do we do with the regression from Firefox 61? There are two options:

a) the regression will be fixed
b) the regression won't be fixed

Whatever you decide, I have to release an update for my WebExtension. I either have to remove the broken option from my WebExtension or I have to add a sentence that the broken option will be fixed by a future Firefox update. It's already broken since a few major releases so I would really appreciate if you could clarify if a) or b) is expected to happen.

Per Dão's comment, we will not back out the changes made in bug 1410591. The behavior that tabs.update() exhibited was both unintentional and undocumented.

That said, we do not want to break the UX for 100K+ extension users. We are investigating ways to restore the old behavior of tabs.update() directly inside the API until such time as bug 1460412 can be implemented.

After some research and discussion, we will not be changing the tabs.update() API to revert to the old behavior.

• tabs.update() is used to direct a tab to a specific URL. There should be no expectation around the behavior of the address bar.
• Hardcoding the API to set focus to the address bar departs from default Firefox behavior with regards to navigations to a URL.
• The current behavior was introduced in June 2018 and has been the default for nearly seven months.
• Looking at the stats for New Tab Override, the number of users and downloads has remained steady for the past six months.

I can appreciate this is not ideal UX for a new tab page, but the data shows it hasn't impacted usage of the extension and implementing a side-effect behavior in an unrelated API isn't a good engineering solution.

Will the API in bug 1460412 have an option to chose the focus behaviour (address bar vs. content)? There are use cases for both behaviours. And when will this API be implemented?

ni? for these questions.

The current behavior was introduced in June 2018 and has been the default for nearly seven months.

If you want to say that it's not bad because there were no reports since June 2018: That's my fault because I didn't redirected the bug reports to Mozilla. I got all the bug reports because for the users of New Tab Override it's a bug of New Tab Override, not a bug of Firefox. I got reports via Github, e-mails, AMO reviews and my social media channels. And I got these reports since early in July 2018. It was not possible for me to investigate the issue earlier for unrelated reasons.

Looking at the stats for New Tab Override, the number of users and downloads has remained steady for the past six months.

The number of downloads doesn't matter, the number of users is important. The number of users dropped from ~ 125,000 to 102,000 between june and today. That's not "steady" at all. In May 2018 New Tab Override even had ~130,000 users but then Firefox 60 was released which broke another feature of New Tab Override (open about:blank in a new tab) and I had to implement a bad workaround. This workaround also stopped to work with Firefox 61 so it's another feature I had to drop because of a change of Firefox. Yes, it's possible now without an add-on at all but for users of New Tab Override which used this option Firefox was broken because of that! In the past months there was more than one change in Firefox which caused trouble for users of New Tab Override.

but the data shows it hasn't impacted usage of the extension

Sorry, but to lose 30,000 users in a few months is a significant (!) loss of users for an add-on with "only" ~ 130,000 users. To say it hasn't impacted usage of the extension is a depressing conclusion for an add-on developer…

(In reply to Sören Hentzschel from comment #12)

Sorry, but to lose 30,000 users in a few months is a significant (!) loss of users for an add-on with "only" ~ 130,000 users. To say it hasn't impacted usage of the extension is a depressing conclusion for an add-on developer…

Sorry, Sören, I do not see this dramatic drop in users when I look at your (non-public) stats. Nevertheless, I understand the loss of any users is painful and discouraging for a developer. Unfortunately, the feature New Tab Override depended on was an unintended side-effect of the API.