Open Bug 1252129 Opened 8 years ago Updated 2 years ago

Filter out webNavigation events related to new window initialization phase

Categories

(WebExtensions :: Request Handling, defect, P5)

defect

Tracking

(Not tracked)

REOPENED

People

(Reporter: rpl, Unassigned)

References

Details

(Whiteboard: [webNavigation][berlin]triaged)

STR:

- install an webextension addon with the webNavigation permission, which subscribe listeners on all the available webNavigation events

- open a link in a new window (e.g. shift + click on a link, or using the context menu):

  - EXPECTED sequence of webNavigation events:
    - onCreatedNavigationTarget
    - onBeforeNavigate
    - onCommitted
    - onDOMContentLoaded
    - onCompleted

  - ACTUAL sequence of webNavigation events:
    - onBeforeNavigate (url is "about:blank")
      (tabId is the "new tab tabId", frameId is "!=0", parentFrameId is -1)
    - onCommitted (url is "about:blank")
      (same tabId, frameId, parentFrameIf of the previous event)
    - onCreatedNavigationTarget (url is "the expected url")
      (tabId is the "new tab tabId")
    - onDOMContentLoaded (url is "about:blank")
    - onCompleted  (url is "about:blank")
    - onBeforeNavigate (url is "about:blank")
    - onErrorOccurred  (url is "about:blank")
    - onBeforeNavigate (url is "the expected url")
    - onCommitted (url is "the expected url")
    - onDOMContentLoaded (url is "the expected url")
    - onCompleted (url is "the expected url")
Whiteboard: [webNavigation]
Whiteboard: [webNavigation] → [webNavigation][berlin]
Luca: what priority would you place on this?
Flags: needinfo?(lgreco)
Whiteboard: [webNavigation][berlin] → [webNavigation][berlin]triaged
It is something annoying but it doesn't seem something which is going to stop an addon from working correctly,
and so I would set it as P4, at least until we didn't verify that it introduces issues that we're not spotting right now (e.g. during testing or development of other features) or if an addon developer reports it as a problem (e.g. because it introduces issues during the usage of this API).
Flags: needinfo?(lgreco)
This is causing errors when an extension attempts to set a page action in a webNavigation event.
The error is bug 1263152, I encountered that error while opening a new window using the test case from bug 1287649.

Excluding about:blank from the webNavigation API would fix the issue, based on my debugging session and the event sequence from this bug report. In Chrome, about:blank is not reported either. What do you think of adding a check for (at least) about:blank at http://searchfox.org/mozilla-central/rev/65bed54efcce67cf04a890f7fe253ccdfa6befdc/toolkit/modules/addons/WebNavigation.jsm#324 ?
I agree that this issue is annoying, but unfortunately filtering any event related to the "about:blank" url does not seem to be an option:

I've tried on Chrome and there are scenarios where webNavigation events related to "about:blank" pages are actually reported when it is the explicitly intended behavior (e.g. if you open a new tab and type "about:blank" in the location bar, or if a webpage use something like `window.open("about:blank")`, or if an iframe which points to "about:blank" is created and added to the DOM).

It would be nice if we could check some flags to identify this initialization phase where the progress listener are registered (http://searchfox.org/mozilla-central/source/toolkit/modules/addons/WebNavigationContent.js), and filter out the initialization phase events before they are actually generated from the content process.
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
Priority: -- → P5
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
Product: Toolkit → WebExtensions
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.