We shouldn't ever recreate the event from the underlying MSG. When the ui::Event is created it should store all the good state.

I'm aware of two builders here:
https://cs.chromium.org/chromium/src/ui/events/blink/web_input_event_builders_win.h?sq=package:chromium

that should really be removed. Which ones were problems for you?

I've already removed the KeyboardEvent equivalent of the builders you link
to in comment #1.

Besides the remaining builders we have
PenEventProcess::GenerateMouseEvent() using GetModifiersFromKeyState().  We
then have calls to ui::EventFromNative(), which internally calls on to
that, in various places.  Each of these call-sites is removed to some
degree from the HWND message handler, making it harder to reason about
whether the modifiers grabbed from the thread keyboard state are actually
correct.

We also expose the SystemEventStateLookup helpers so that anyone can query
the thread keyboard state; I'd suggest hiding those, to avoid misuse.

PenEventProcessor is called from the HWND handler so it is ok.

Personally my approach would be to never have the native os_event hung off of the ui::Event.

What is the primary reason it is still needed?

Under Windows it gets used to populate fields in WebInputEvents that
ui::Event populates differently, or loses entirely.

For keyboard events, for example, ui::Event has a different notion of
whether the event is a "system key", and we lose the "native_key_code",
which it seems some Blink code may still rely on.

Auditing for uses of those and migrating them is likely tedious, but
certainly do-able, and I agree that we should convert to ui::Events and
work with that, not keep dipping back in to the "original" event.