webRequest filter for tabId + windowId sometimes excludes requests that should have matched |
|||
Issue descriptionChrome version: stable (50) and latest HEAD (53.0.2748.0) Steps to reproduce: 1. Open chrome://net-internals#events 2. Visit chrome://extensions and load the attached extension. The extension opens a tab, waits until an image is loaded, calls navigator.sendBeacon and closes the tab. 3. Inspect the console of the extension's background page. Expected result: - The extension prints all webRequest events. chrome://net-internals shows that the image and beacon requests are both successful, so the console should contain both events. Actual result: - Only the image request is shown. The beacon request is never shown. This is probably because the beacon has tabId -1 when the tab is removed. In bug 613718 , the event detail's tabId was -1 because it was unavailable on the IO thread, but after hopping to the UI thread and back, the tabId became available. A similar logic could be applied to the event filtering, i.e. when the lookup fails, don't filter the event listener and test whether the filter matches before dispatching the event to the extension. A more preferable solution is to somehow ensure that the tabId (and frameId) is always available on the IO thread at the time of a request. Oh, and there are no tests for the windowId filter in the webRequest API, so there is zero guarantee that windowId works at the moment.
,
Jul 23 2016
With the filter removed the requests indeed show up. The issue that I'm reporting is not that the tabId is -1 (because as you say the tab ID may indeed become unknown), but that even when the tabId is not -1, that the webRequest filter still filters them out. Last time I checked, the logic was like this: - if filter is set, apply filter - if tabId/frameId is unknown, hop to UI thread to find the info and hop back to the IO thread - Dispatch the event to the extension. Note that after the second step, an event that initially had a tabId of -1 can have a valid tabId. But if an extension developer decides to apply a filter for that tabId, they will never see the event because our implementation filters the event at an early stage.
,
Jul 24 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 22 2017
I'd bet this still reproduces, and that Rob's assessment in #2 is spot-on. karandeepb@, if you have time, might be a good one to look into? |
|||
►
Sign in to add a comment |
|||
Comment 1 by asargent@chromium.org
, Jul 22 2016Status: Available (was: Untriaged)