This is used as an internal implementation detail of Chrome to generate C++ files and is not web-exposed in any way. Thus it's not appropriate to either remove or standardize it.

Is there an action we can take so that it is not tracked by whatever tool is filing these bugs?

If there is some way we could mark the IDL file as not web exposed then this would be actionable. Otherwise there is nothing to do here and I am inclined to WontFix.

markdittmer@, can you exclude this file specifically from your tool? If we get too many exceptions that don't map cleanly to directories then perhaps we should consider an extended attribute, but not yet I think.

foolip@, Google-internal web-apis service code updated (expect propagation in ~2h). I'll also patch the emerging "official" tool repo.

I'm not convinced that skipping files like this is valuable. Each platform implementation will model some non-standard things using IDL, but the collection of such things will be relatively small, and still constitutes a part of the platform implementation.

domenic@, ricea@, is any object created and returned to scripts where toString() is '[object UnderlyingSourceBase]', or where UnderlyingSourceBase is otherwise on the prototype chain? If so, does the spec say anything about the shape of that object?

> domenic@, ricea@, is any object created and returned to scripts where toString() is '[object UnderlyingSourceBase]', or where UnderlyingSourceBase is otherwise on the prototype chain?

No.

Huh, WontFix it is. This'll probably come up again but hopefully I'll remember to not file another bug.