[webkit-reviews] review denied: [Bug 47301] AX: Support UIRequestEvents from new W3C Proposal : [Attachment 71922] Patch

[bugzilla-daemon at webkit.org]

Ojan Vafai <ojan at chromium.org> has denied chris fleizach
<cfleizach at apple.com>'s request for review:
Bug 47301: AX: Support UIRequestEvents from new W3C Proposal
https://bugs.webkit.org/show_bug.cgi?id=47301

Attachment 71922: Patch
https://bugs.webkit.org/attachment.cgi?id=71922&action=review

------- Additional Comments from Ojan Vafai <ojan at chromium.org>
I had made a proposal a few months ago that we add a property to the "input"
event that specifies the user-action that caused the event (e.g.
action="undo"). I also proposed that we add a corresponding "beforeInput"
event. This seems to completely overlap with UIRequestEvent. Given that we
already fire the input event, what is the advantage of adding all these new
events over just adding a property to the existing one? Tony asked the same
question on webkit-dev, but never got a response:
https://lists.webkit.org/pipermail/webkit-dev/2010-September/014258.html.

Also on that thread, Adam asked if they need to be synchronous. The answer
seemed to be no, but these look synchronous to me. Another advantage of
building on top of the input event is that it already has to deal with all the
complexity of being a synchronous event.

Since these are high-level design discussions, it's probably best to continue
the discussion on webkit-dev rather than this bug.