1392063 - dynamically overriding new tab page spams the browser history

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[Sören Hentzschel]

In New Tab Override I allow the user to override the new tab page to any custom URL, for example https://www.google.com. Unfortunately this adds two entries to the history for every new tab: first something like moz-extension://d4f650f4-3887-fa4f-bf88-832c84d0e1ca/html/newtab.html and then https://www.google.com.

I need a way to prevent this history spam because that'a a very annoying behaviour. With the legacy version of New Tab Override this issue was not present.

I use browser.tabs.update({ url : urlFromOptions });

as way to override the new tab page.

If there is already a way to prevent this please let me know.

Comment 1

[Andy McKay]

We specifically didn't do this in bug 1314123, because we had no idea why the page was opened. If we know that its from a new tab request, perhaps we have a valid use case where it shouldn't be added to the history.

Comment 2

[Sören Hentzschel]

Is there something needed to get something like this on the agenda for one of the next API triage meetings?

Bug 1314123 contains a workaround but this only works in conjunction with browser.tabs.create(), not with browser.tabs.update() (I don't know why) so it doesn't meet the requirements of New Tab Override, see bug 1314123 comment 6 (the comment includes a code example).

Also it's bad that a permission is needed for this workaround because I don't want to remove anything from the history but the own add-on page entry. :(

Comment 3

[Sören Hentzschel]

I have to correct my statement in comment 2. I have solved this in the following way.

await browser.tabs.getCurrent((tab) => {
  browser.tabs.update(tab.id, { url : url || 'about:blank', loadReplace : true }, () => {
    // there is nothing to do, but it's needed, otherwise browser.history.deleteUrl() does not work
  });
});

// delete spammy new tab page entry from history
browser.history.deleteUrl({ url : browser.extension.getURL(NEW_TAB_PAGE) });

Note that the empty function body in browser.tabs.update() is necessary, otherwise browser.history.deleteUrl() does not work.

But ni? :andym for the question from August: 

> Is there something needed to get something like this on the agenda for one of the next API triage meetings?

I would like to avoid that I have to request a history permission if all I want is to prevent the moz-extension:// URI of my own add-on appearing in the history.

Comment 4

[Andy McKay]

Marked as [design-decision-needed] so it gets into the (rather long) queue.

Comment 5

[Caitlin Neiman [:caitmuenster]]

Hi Soren, this has been added to the agenda for the January 16, 2018 WebExtensions APIs triage. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/13AiUqFgtLsuJ17QjzUOQ7nBN1U_ZEO0yzMaHLLl0JKk/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 6

[Andy McKay]

The result from the API meeting was that if the URL is not shown in the URL bar, we shouldn't add it to the history either. As per comment 1, we agree we shouldn't write this into the browsers history.