Intervals are stored in the DOM and not individual isolates. They can be manipulated by an extension and/or page.

Plarform>Extensions for triage.

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #67.0.3396.99 and latest canary #69.0.3482.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

This is definitely interesting.  As dtapuska@ mentioned, technically I think intervals are on the DOM, and the DOM is shared between extensions and the page (by design - we wouldn't want extensions to have a different view of the DOM than the page, or vice versa).  That said, it's definitely a bit odd, and not what I'd initially expect for a content script.

jbroman@, any thoughts here from a v8/isolated world/blink perspective?

That is interesting. I could see either angle here. It could be changed if we needed to (by double-keying internally), but I'm not sure whether that's what's best (as is pointed out above, it's *technically* part of the DOM and not the script context).

Most web APIs use objects rather than integers, so this wouldn't be a problem (you can't get a hold of the object from the wrong context).

As Devlin and Jeremy pointed out, the current behavior aligns with the spec and thus expected.

It's similar to: A dom element injected by a content script can be removed by a page.

All that said, I'm not sure it's desired behavior.  There's not really a great alternative to setTimeout/setInterval, and they can be pretty important/useful, so having a way to interfere with them isn't great.  We also don't love having "easy" ways for websites to detect or interact with extensions.  I'd lean towards saying that the intersection with the DOM in this case is fairly esoteric, and somewhat orthogonal to the JS code's actual purpose (as opposed to adding a DOM element, where it is clearly and essentially a part of the DOM).

I wonder if it is worth investigating options here to prevent this intersection.  A few quick questions:
- haraken@, would you be opposed to keying timeouts separately based on current world?
- Do we think any (extension) is intentionally relying on this behavior?  My suspicion is "no", but I don't know how common it might be on the web to depend on the DOM's relation to timeouts/intervals.

Do you know what Firefox is doing with their extensions?

FWIW we have a similar hack for ErrorEvent (https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/events/error_event.h?q=errorevent+blink&sq=package:chromium&dr=CSs&l=111). It's keyed by worlds because it's weird if errors produced by an extension are propagated to the main page.

So I don't very strongly object to special-case setTimeout/setInterval if the use case is very important in practice.

> Do you know what Firefox is doing with their extensions?

Seems the behaviour is the same in Firefox too, I also filed a bug with them: https://bugzilla.mozilla.org/show_bug.cgi?id=1473363

> So I don't very strongly object to special-case setTimeout/setInterval if the use case is very important in practice.

Well, speaking as a developer on the Adblock Plus team I can say this is important to us. We were all pretty surprised when we realised a document could clear our content script's intervals and timeouts. I think for now we'd have to set up an interval from a background script, and then use that to send a message to our content script!

In fact, taking a quick look at our code now I can see a few places where we are already using setTimeout from a content script:

- https://github.com/adblockplus/adblockpluschrome/blob/5b9a518/include.preload.js#L372
- https://github.com/adblockplus/adblockpluscore/blob/bf1e095/lib/content/elemHideEmulation.js#L904
- https://github.com/adblockplus/adblockpluscore/blob/bf1e095/lib/content/elemHideEmulation.js#L824