1352653 - API for onRefreshAttempted

Status: NEW

(WebExtensions :: General, enhancement, P5)

Description

[erosman]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170307064827

Steps to reproduce:

re: Bug 1343444

Initially, I requested an API support for addTabsProgressListener.
I have been told to file the API request under WebNavigation API bug.

It was asserted that the support is already provided in WebNavigation API. However, it turned out to be missing.

> My addon (Refresh Blocker) requires 'onRefreshAttempted' from 'addTabsProgressListener'.
It is the only working addon in this category and AFAIK none of the other browser have it due to the absence of an API.
I would like to be able to migrate the addon to WebExtension if an API could be implemented.

> From what I understand from the documentatons, webNavigation.onCommitted has transitionQualifiers property. onCommitted is fired when a navigation is committed. At least part of the new document has been received from the server and the browser has decided to switch to the new document.

> It is fired too late and does not cover the function of 'onRefreshAttempted' from 'addTabsProgressListener'.

> webNavigation.onBeforeNavigate may have been appropriate but it does not have a transitionQualifiers property.

> Additionally, necessary details such as aRefreshURI, aMillis, aSameURI are not provided by the transitionQualifiers property.

It is worth notion that 'onRefreshAttempted' from 'addTabsProgressListener' is fired when a page loads, and not when a page it about to re-navigate.

In other words, after a page is loaded with a meta refresh for 10 minutes later, 'onRefreshAttempted' is fired and can be dealt with, not when it is about to refresh (10 minutes after the page is loaded).

The WebNavigation API appears to deal with navigation differently than addTabsProgressListener.

Comment 1

[Caitlin Neiman [:caitmuenster]]

This has been added to the agenda for the April 4 WebExtensions triage. Erosman, will you be able to attend? Call-in information can be found here: https://wiki.mozilla.org/Add-ons/Contribute/Triage

Meeting agenda can be found here: https://docs.google.com/document/d/1V4NP4tWnjHigS2lAosCLfkU2FTcrQnoQzzXZmmB1uzk/edit#heading=h.du5ihvu5p6ro

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

This issue has been discussed in the WebExtensions API triage meeting and it has been approved.

The only concern showed by the participants during the meeting is related to where this feature would better placed (webNavigation or webRequest)

Comment 3

[erosman]

Is there an ETA or timetable for the implementation?

Comment 4

[Andy McKay]

You should assume that as a P5 this will not be ready for Firefox 57 unless a contributor can be found to work on it.

Comment 5

[erosman]

Can transitionQualifiers property be added to webNavigation.onBeforeNavigate?
Would that be easier?
I might be able to work with that.

Comment 6

[Shane Caraveo (:mixedpuppy)]

Adding transitionQualifiers per comment 5 seems like the preferable over a new api.  If there is a platform issue preventing that, can that be addressed?  Otherwise it seems like browser.tabs.onBeforeRefresh (or onRefresh) would be ok.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi erosman,
Here is some information related to the webNavigation internals that can be helpful to you planning.
 
the webNavigation internals are currently subscribing a onRefreshAttempted listener here:

- http://searchfox.org/mozilla-central/source/toolkit/modules/addons/WebNavigationContent.js#139-144

its role is to produce the client_redirect transitionQualifier:

- http://searchfox.org/mozilla-central/source/toolkit/modules/addons/WebNavigationContent.js#291-294

This data is sent from the content process to the main process, where it is translated into the actual webNavigation events:

- http://searchfox.org/mozilla-central/source/toolkit/modules/addons/WebNavigation.jsm

is the final goal to just provide a more specific transition qualifier or to allow an extension to block the refresh attempt?

If the goal is to provide a more specific transition qualifier, the change should be possible without too much changes and impact on the current implementation, on the contrary allowing an extension to block the refresh attempt through the webNavigation API will more likely require the introduction on new pieces in the implementation to coordinate the different processes involved (e.g. the content process where the refresh is happening, as well as the extension process, where the extension code runs, and the main process, where the webNavigation.jsm is running).

Comment 8

[Thomas Wisniewski]

Luca, after checking things out with erosman, I don't think that it will be enough to use transitionQualifiers for his purposes. His addon is meant to block refresh attempts (the addon is RefreshBlocker), and I'm not sure if adding transitionQualifiers will be enough to help with that.

It sounds like what would be needed is to conditionally return false from onRefreshAttempted, but I can't be sure what the best solution is there. Should we just add a possibly-blocking WebRequest.onRefreshAttempted API? Or would we prefer adding blocking calls/permissions to WebNavigate?

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

As briefly discussed over IRC, the main problem with providing a "blocking listener" for a new webNaviagtion.onRefreshAttach API event is that the "low level" onRefreshAttempted currently expect that the subscribed listener returns true or false synchronously, but in a webExtension the event listener would run in a different process (the main process or the extension child process) from the listener subscribed to the "low level onRefreshAttempted" listener (the content child process)   and I'm not sure if we can make it to pause without making some "platform level" changes to it (e.g. there have been platform changes to be able to pause a web request while we are waiting for the result of a webRequest blocking listener).

Once/If we have a way to make this work asynchrously (e.g. by making the needed "platform level" changes, or by using a different strategy if it already exist), we need to take into account that none of the webNavigation listener is currently "blocking", and so we will need to recreate part of the strategy we are using in the webRequest API to achieve that (or we can evaluate if defining as webRequest.onRefreshAttemp could be a reasonable alternative API event name).

Comment 10

[Gingerbread Man]

(In reply to Luca Greco [:rpl] from comment #2)
> This issue has been discussed in the WebExtensions API triage meeting and it
> has been approved.

Then this shouldn't stay unconfirmed.

Comment 11

[erosman]

Is there anything that can be done to get this API on track?

Comment 12

[Caitlin Neiman [:caitmuenster]]

At the moment, it looks like we don't have a way to implement this, and the webNavigation API doesn't currently support any other kind of blocking listeners.

Comment 13

[Firefox Bug Husbandry Bot]

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958