1334953 - Figure out what to do with the ThreadsafeIsCallerChrome call in Event::InitEvent

Status: NEW

(Core :: DOM: Events, defect, P3)

Description

[Boris Zbarsky [:bzbarsky]]

The obvious thing to do is to add a CallerType arg to InitEvent and update all the consumers.  It's a huge pain, because there are a bunch of them, but is probably the only principled thing to do that doesn't have the current action-at-a-distance thing.  :(

The other option is to just have scripted initEvent call a different function from all the internal callers and only do the caller type check there.  But that would assume that all C++ initEvent callers really don't need to do this "drop trust if I'm already trusted" thing.  It's not clear to me whether this is a good assumption.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

There aren't actually that many InitEvent callers in C++, and I would expect pretty much all of them to be able to pass caller-is-chrome flag, given that SetIsTrusted(true) is usually called right after.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

I guess I could take this

Comment 3

[Boris Zbarsky [:bzbarsky]]

> There aren't actually that many InitEvent callers in C++

Well, there are 100-some, though some are generated.  But even for the generated ones, it's not enough to just update the generator, because they're called from things like the various generated event class Constructor impls (the ones taking an EventTarget), and those have a bunch more C++ callers.

Then again, I guess the generated constructors call SetTrusted after Init(), so they could get away with just passing whatever for now, as long as we only use this argument for trusted state...

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Assuming P3 due to lack of recent activity. Feel free to correct me.