Hmm, codesearch says there are 236 WCOs that aren't for testing. Assuming a 20 bytes class name, this project could have the potential to add almost 5kb to the binary.

Do you think this is worth it?

Maybe our goal shouldn't be to make this pure virtual in the end, but rather "here is a method you can override to automatically trace your WCO". So performance conscious observers can do it without adding their own traces.

My initial comment did say we should not make it pure virtual, not only for size reasons, but also for content/public/ API reasons. 

Also, thanks for digging into the details of this, that's a LOT of WCOs :). While I'd love the debuggability, it does seem too high of a price to pay for this. Maybe we can log a counter or the address? I think ordering is more or less reproducible within a build, so if we log that, we would have reasonable way of identifying the WCO we care about in a local build/repro. What do you think?

Also, let me add some other folks that have griped about WCOs doing things they should not be doing :).

Adding a counter / address sounds reasonable to me. An address is probably a tiny bit more actionable since I'm nervous a counter could hit weird off-by-one issues wrt observers adding / removing themselves dynamically.

The counter would be a local variable that is incremented on each iteration of the loop. It should not be used for control flow.

The problem with addresses is that with properly functioning ASLR, you will not be able to reproduce in another run of the browser. While even with off by 1 or 2, you have reasonably decreased the search space and the behavior will likely be identical between runs with the same repro steps.

Back to Available. Maybe if I have some time later though :)
In investigating this I found some slow Java WebContentsObservers (or TabObservers, what have you). Could probably win some ms on Android from optimizing them.