Note: There are a few cases of duplicates in user autocompletion which are being worked on.

API for onRefreshAttempted




WebExtensions: Untriaged
4 months ago
a month ago


(Reporter: erosman, Unassigned)


53 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [webNavigation]triaged)



4 months ago
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.


4 months ago
Component: General → WebExtensions: Untriaged
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:

Meeting agenda can be found here:

Comment 2

4 months ago
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)
Priority: -- → P5
Whiteboard: [design-decision-approved]


3 months ago
Whiteboard: [design-decision-approved] → triaged


3 months ago
Summary: WebNavigation API Lacking the needed data → API for onRefreshAttempted
Whiteboard: triaged → [webNavigation]triaged

Comment 3

3 months ago
Is there an ETA or timetable for the implementation?

Comment 4

3 months ago
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

a month ago
Can transitionQualifiers property be added to webNavigation.onBeforeNavigate?
Would that be easier?
I might be able to work with that.
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

a month ago
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:


its role is to produce the client_redirect transitionQualifier:


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


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

a month ago
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?
Flags: needinfo?(lgreco)

Comment 9

a month ago
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).
Flags: needinfo?(lgreco)
You need to log in before you can comment on or make changes to this bug.