Bug 1516777 Comment 5 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(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 broke the behaviour of extensions of hundred thounsands of 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 update don't break WebExtensions, at least not without announcement.

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 override via the manifest but this approach is unusable if you want that *the user* can override the new tab page.
(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 thounsands of 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 update don't break WebExtensions, at least not without announcement.

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 override via the manifest but this approach is unusable if you want that *the user* can override the new tab page.
(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 update don't break WebExtensions, at least not without announcement.

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 override via the manifest but this approach is unusable if you want that *the user* can override the new tab page.
(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 a update. My add-on now has a broken option and I get 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 override via the manifest but this approach is unusable if you want that *the user* can override the new tab page.
(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 a update. My add-on now has a broken option and I get 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.
(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.

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.
(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.

Back to Bug 1516777 Comment 5