onBeforeRequest doesn't intercept HTTP requests from a tab, which is opened from a browserAction popup iframe
Reported by
alex.tro...@gmail.com,
Jan 25 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: 1. Install both demo extensions. The first extension prints all onBeforeRequest events to console. The second extension sets browserAction popup to action.html. On action.html page contains an iframe with src='http://www.cashbackwatch.com/e/index.php?domain=google.com'. 2. Open browser action for the second extension and click on the site link. New tab will be opened. The first extension should print onBeforeRequest events from this newly opened tab, but it doesn't do it. onBeforeRequest events will appear in the log only if you reload the tab. What is the expected behavior? The first extension should print onBeforeRequest events from opened tab. What went wrong? No onBeforeRequest events are fired. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.10.5 Flash Version: Shockwave Flash 24.0 r0
,
Jan 25 2017
It was broken because of these two CL: 1. r335314 (45.0.2437.0) assigns ownership of tabs opened by extensions to the extension 2. r341939 (45.0.2454.38) prevents extensions from intercepting other extensions' request, and since the webpage tab has the wrong owner (due to r335314) the reported bug occurs I couldn't reproduce in latest Canary 58 so it was either fixed or temporarily obscured by a FieldTrial.
,
Jan 25 2017
,
Jan 25 2017
,
Feb 3 2017
Tested this on Mac OS 10.12.2 on the latest stable(56.0.2924.87) but was unable to observe the exact behavior as mentioned above. alex.tropnikov@: Could you please review the attached screen-cast and confirm if anything being missed here. Also, please let us know if the issue still persists on the latest stable or not. Thanks in advance!
,
Feb 3 2017
#5, your screencast confirms the issue: there are no entries for the opened web site (www.cashbackwatch.com) in the console.log.
,
Feb 3 2017
Here's an arguably more convenient test case: 1. install both extensions as unpacked on chrome://extensions 2. click the second extension's toolbar icon 3. wait for the popup to appear 4. click the Full Site link EXPECTED: a notification from the first extension with intercepted request types appears at the bottom similar to the attached example picture OBSERVED: no notification appears meaning the requests to the opened site were not intercepted
,
Feb 3 2017
#7 wox...@gmail.com very clearly described the test case. The problem still exists on the stable 56.0.2924.87 But on the latest Canary 58.0.3001.0 the problem isn't reproduced and requests are intercepted as expected. (Tested on Mac OS 10.10.5)
,
Feb 13 2017
Thank you for providing more feedback. Adding requester "ajha@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 15 2017
Unable to reproduce the issue on Mac 10.12.2, Windows 7,Linux Ubuntu 14.04 using chrome stable version -56.0.2924.87 and latest Canary-58.0.3012.0 as per the below steps : 1. installed both extensions as unpacked on chrome://extensions 2. clicked the second extension's toolbar icon 3. wait for the popup to appear 4. clicked on Full Site link 5. Refresh the page on Mac once & observed expected notification displayed successfully Note: On Windows and Linux expected notification displayed on load of 'Full site ' link page Please find the attached screencast for reference & update the thread accordingly. Thanks!!
,
Feb 15 2017
,
Feb 15 2017
#10, you didn't follow the repro steps: refreshing the page wasn't mentioned. The point of this bug report is that in good builds the first extension intercepts on the first load.
,
Mar 20 2017
Able to reproduce this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.3 with chrome stable #57.0.2987.110 , but not able to reproduce in Beta #58.0.3029.19, dev #59.0.3043.0 and Canary #59.0.3044.0 Issue got fixed in M58. Bisect Info: =========== Good build : 58.0.3026.0 , Revision Range - 453454 Bad build : 58.0.3025.0 , Revision Range - 453134 After executing the per-revision bisect script in "reverse", i got the following CL's between good and bad build versions =========================================== https://chromium.googlesource.com/chromium/src/+log/09ac3a21d0b908ca26d0898f58ea77be7e9462d2..9e1897b5c7dab9c190fc3c919a1c4662af63b3e6 The suspecting Change Log is : ----------- https://chromium.googlesource.com/chromium/src/+/9e1897b5c7dab9c190fc3c919a1c4662af63b3e6 Review-Url: https://codereview.chromium.org/2715363002 nasko@- Could you please look into this issue, if this CL fixed the issue, please merge this if there is any M57 stable push.
,
Mar 20 2017
rdevlin.cronin@, would you be able to help investigating why "Isolate Extensions" would have impact on how webRequest API events are dispatched?
,
Mar 20 2017
Actually, alexmos@ pointed out that c#14 says that that CL fixed it. If that is the case, can the original reporters help verify? The feature was enabled on all branches recently, so it should be fixed in M56 and onward.
,
Mar 20 2017
I'm not the reporter but confirm that "isolate extensions" is what fixed the bug: I've bisected the snapsots (waterfall bots?) [1] and got r450821 "Enable SiteIsolationExtensions trial for developers" - in other words the same feature found in #14 r453318, only enabled earlier for non-release builds. [1]: https://chromium.googlesource.com/chromium/src/+log/8201abf3..2f271eac?pretty=fuller
,
Mar 21 2017
I'm going to assign this to rdevlin.cronin@ to make sure the expected behavior is observed. From our point, Isolate Extensions is launched.
,
Mar 21 2017
This seems like the desired behavior now - extensions should be able to monitor tabs opened by other extensions if those tabs are to external sites. I think the action item here is to add a test for this so we don't regress. Maybe this is something karandeepb@ can tackle? If not, I'll try to get to it soon. |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 Deleted