Bisect info: 165308 (good) - 165320 (bad)
https://chromium.googlesource.com/chromium/src/+log/af77b180..39663e81?pretty=fuller
Suspecting 46dd3610caa75097ba521f7f74e5f5c0d7c23b79 "Webkit roll 133029:133116"
Landed in 25.0.1315.0

Webkit changelog: https://trac.webkit.org/log/webkit/?rev=133116&stop_rev=133029&verbose=on
Suspecting https://trac.webkit.org/changeset/133095/webkit/
This is the initial implementation of CSP header support.

FWIW, the error wasn't printed initially, it was added later by mkwst@chromium.org
in https://trac.webkit.org/changeset/137180/webkit/
landed as 9a211caf42e9319033b9f073e93b34e1cb8c3d90 

Related: now that the new Feature Policy enabled in  issue 623682 , sites can prevent extensions content scripts from using features even in normal context (that is without setTimeout/setInterval). Looks like CSP and Feature Policy were devised without caring about extensions - is it intended?

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #67.0.3396.99 but the same is not reproducible in the latest canary #69.0.3486.0 and latest beta #68.0.3440.42.

Reverse Bisect Information:
=====================
Good build: 68.0.3413.0
Bad Build : 68.0.3410.0  

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/b6973d3bda4ec16ba14294c9b6b22db0c824ae3e..3ca3f90e4f51a96d0a5aec9915406898a2ff4058

From the above change log suspecting below change
Change-Id: I7f6497784845a7d05d60048c84b24db9b903eae9
Reviewed-on: https://chromium-review.googlesource.com/1030952

reporter@ - Could you please check the issue in latest beta #68.0.3440.42 and please let us know if the issue is fixed or not.

Thanks...!!

Confirmed that the issue is partially fixed in the beta. Calling `setTimeout` in an extension now works. It looks like https://chromium.googlesource.com/chromium/src/+/5a5267ab58dd0310fc2b427db30de60c0eea4457 is the commit that addressed it.

However, it's not entirely fixed. Calling setTimeout in the developer console on a CSP-sandboxed page still fails with the same error.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Assigning to Devlin, based on https://chromium.googlesource.com/chromium/src/+/5a5267ab58dd0310fc2b427db30de60c0eea4457.

https://chromium.googlesource.com/chromium/src/+/5a5267ab58dd0310fc2b427db30de60c0eea4457 fixed this for extensions, so for that this could also be duped into  issue 811528  (russel.davis@, please correct me if that's wrong!).  The only remaining bit from #7 is for dev tools.  I'll repurpose this bug to cover that.  Over to dgozman@ for that.  dgozman, I'm not sure if this is WAI or not?

woxxom@, re #3, can you file a new bug for that (and cc me on it)?  Extensions should almost always have priority over web pages, so they very likely shouldn't be subject to a page's feature policy (at least, as long as they inject in the isolated world).

re #10: when the devtools console context is set to the extension, setTimeout/setInterval should also be exempt from the page CSP but currently devtools shows an error which cannot be WAI, right?

re #11: that was a question because AFAICT extensions were not considered at all. At least for the really easy to reproduce case with iframe + sandbox attribute that forbids sync XHR. I'm asking because this seems to happen quite regularly: some hip/urgent feature is added, then several months later someone reports that extensions are broken and turns out no one thought about special-casing the extensions -- sometimes authors may simply implement a workaround without reporting here...

Thanks for the thoughts, woxxom@.

> when the devtools console context is set to the extension, setTimeout/setInterval should also be exempt from the page CSP but currently devtools shows an error which cannot be WAI, right?

Ah, I didn't realize the context was set to the extension in this case.  Then, I'd agree that this probably isn't WAI.  dgozman@ is probably still the right triager for this (since it's still very devtools-y).

> that was a question because AFAICT extensions were not considered at all. At least for the really easy to reproduce case with iframe + sandbox attribute that forbids sync XHR. I'm asking because this seems to happen quite regularly: some hip/urgent feature is added, then several months later someone reports that extensions are broken and turns out no one thought about special-casing the extensions -- sometimes authors may simply implement a workaround without reporting here...

I agree that "feature A in Chrome breaks feature B" can definitely happen (and has in the past).  It's obviously not ideal, and we continue to work and learn how we can balance platform stability and maintaining good velocity and moving the web forward.  Leaning extremely in either direction can either lead to eternal stagnation or an eternally broken state - obviously neither of which are what we want.  Clearly, we don't get that balance right all the time, and so it's something we should continue to work on. :)  That's a process discussion for another forum, though.  However, that doesn't mean we shouldn't fix the problem at hand.  Towards that end, we should file another bug about Feature Policy + extensions where we can discuss more fully (since this bug isn't the right place for it).

@kozy: I think we can follow the patch of https://chromium-review.googlesource.com/c/chromium/src/+/1030952 for our console evals. Mind taking a look?

As per the bisect info at comment #6, adding appropriate target labels and removing Needs-Bisect label.
Note: As per comment #7, adding RBS label for M-68. Please feel free to remove the same if not appropriate.
Thanks...!!

The bisect in #6 is identifying a partial fix for this issue, not a regression.  This shouldn't be a release blocker since this behavior has been pretty much the same since CSP was introduced.