1270138 - WebExtensions: chrome.webRequest listener fires for incorrect tab on load requests

Status: RESOLVED WORKSFORME

(WebExtensions :: Untriaged, defect, P3)

Description

[dw-dev]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160407164938

Steps to reproduce:

I am migrating my "Print Edit" add-on to the WebExtensions API.

I have the following code that adds a chrome.webRequest listener to the currently selected tab (A):

    chrome.tabs.query({ currentWindow: true, active: true },
    function(tabs)
    {
        chrome.webRequest.onBeforeRequest.addListener(
        function(details)
        {
            .....
        }
        ,{ tabId: tabs[0].id, urls: ["<all_urls>"] },["blocking"]);
    });
                
After this code has executed, if I then middle-click on a bookmark (or link) to open the bookmark (or link) in a new tab (B), the chrome.webRequest listener fires for tab A - BUT the listener should not be fired at all.

The listener seems to think that the load request is associated with the currently selected tab (A), but in actual fact the load requst is associated with the newly created tab (B).

The same problem happens with onBeforeSendHeaders and onSendHeaders listeners.

All of these listeners work correctly in Chrome with identical code and the same sequence of events.

This is a serious bug that could confuse users or compromise security, depending on the actions performed by the listener.


Actual results:

The chrome.webRequest listener fires for tab A.


Expected results:

The chrome.webRequest listener should not be fired at all.

Comment 1

[Giorgio Maone [:ma1]]

This seems https://dxr.mozilla.org/mozilla-central/source/toolkit/modules/addons/WebRequest.jsm#71, and  it is also correctly documented in https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest#Chrome_incompatibilities

I think there are higher priorities at this moment, since this can be easily worked around, but nonetheless it deserves to be morphed in a proper compat browser, since it seems we don't have one properly filed.

Comment 2

[dw-dev]

I have done a lot more testing with Print Edit and I can confirm that the webRequest listeners (onBeforeRequest, onBeforeSendHeaders and onSendHeaders) perform as documented in the webRequest documerntation, subject to the noted Chrome incompatibilities. In fact, I skimmed through the webRequest documentation some time ago, but for some reason didn't notice these incompatibilities.

I have now implemented a workaround to do my own tabId filtering for all the relevant tabs - and this seems to work fine.

So from my perspective this bug can be closed, unless you want to keep it open as a reminder for the implementation of tabId and windowId filtering.

Comment 3

[Andy McKay]

tabId is covered in bug 1311576 and windowId in bug 1313523.