Bug 47301 - AX: Support UIRequestEvents from new W3C Proposal
: AX: Support UIRequestEvents from new W3C Proposal
Status: NEW
Product: WebKit
Classification: Unclassified
Component: Accessibility
: 528+ (Nightly build)
: PC Mac OS X 10.5
: P2 Normal
Assigned To: chris fleizach
: InRadar
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-06 13:56 PDT by chris fleizach
Modified: 2013-10-23 16:44 PDT (History)
12 users (show)

See Also:


Attachments
Patch (47.79 KB, patch)
2010-10-06 15:20 PDT, chris fleizach
no flags Details | Formatted Diff | Diff
Patch (47.80 KB, patch)
2010-10-06 16:45 PDT, chris fleizach
no flags Details | Formatted Diff | Diff
Patch (47.51 KB, patch)
2010-10-07 10:46 PDT, chris fleizach
no flags Details | Formatted Diff | Diff
Patch (61.61 KB, patch)
2010-10-26 12:00 PDT, chris fleizach
no flags Details | Formatted Diff | Diff
Patch (54.47 KB, patch)
2010-11-02 12:56 PDT, chris fleizach
no flags Details | Formatted Diff | Diff
Patch (61.44 KB, patch)
2010-11-02 14:50 PDT, chris fleizach
no flags Details | Formatted Diff | Diff
Patch (62.51 KB, patch)
2010-11-05 16:07 PDT, chris fleizach
abarth: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description chris fleizach 2010-10-06 13:56:00 PDT
We should support UIRequestEvents from 
http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html
Comment 1 chris fleizach 2010-10-06 15:20:34 PDT
Created attachment 69999 [details]
Patch
Comment 2 Early Warning System Bot 2010-10-06 15:50:13 PDT
Attachment 69999 [details] did not build on qt:
Build output: http://queues.webkit.org/results/4251055
Comment 3 chris fleizach 2010-10-06 16:45:43 PDT
Created attachment 70011 [details]
Patch
Comment 4 chris fleizach 2010-10-07 10:46:10 PDT
Created attachment 70115 [details]
Patch
Comment 5 Sam Weinig 2010-10-09 12:30:11 PDT
Comment on attachment 70115 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=70115&action=review

My major issues with this patch are (and maybe I am still missing the point):
- The events never seem to be fired.
- The undo/redo events seem to offer the same functionality as http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#undomanagerevent from HTML5.
- These events seem general enough that they should be defined in HTML5 (or 6), and not an accessibly spec.
- There should also be more tests that show the event getting fired in other ways (other than manual dispatchEvent).

> WebCore/accessibility/UIRequestEvent.h:40
> +    enum {
> +        
> +    };

Empty enum should be removed.

> WebCore/accessibility/UIRequestEvent.idl:38
> +    interface UIRequestEvent : UIEvent {
> +        
> +        void initUIRequestEvent(in DOMString type, 
> +                                    in boolean canBubble, 
> +                                    in boolean cancelable, 
> +                                    in DOMWindow view, 
> +                                    in long detail);
> +
> +    };

Perhaps this should be prefixed with webkit, until there is more support for this standard.

> WebCore/dom/EventNames.h:176
> +    macro(undorequest) \
> +    macro(redorequest) \
> +    macro(escaperequest) \
> +    macro(deleterequest)

Again, these should probably be prefixed.
Comment 6 Olli Pettay (:smaug) 2010-10-11 09:16:03 PDT
If you had support for non-standard events, they should be prefixed.
(In this case with 'webkit').

http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html
is not in any kind of standard yet, just a proposal which will change.
Comment 7 chris fleizach 2010-10-11 11:24:12 PDT
> My major issues with this patch are (and maybe I am still missing the point):
> - The events never seem to be fired.

These are meant to be dispatched from the accessibility interface through

 522     // UIRequestEvent support
 523     enum UIRequestEventType { UNDO = 1, REDO = 2, ESCAPE = 3, DELETE = 4 };
 524     void dispatchUIRequestEvent(UIRequestEventType);

However, the first client that can do this is iOS accessibility client. We are still battling mac-platform API discussions..

 
> > WebCore/accessibility/UIRequestEvent.idl:38
> > +    interface UIRequestEvent : UIEvent {
> > +        
> > +        void initUIRequestEvent(in DOMString type, 
> > +                                    in boolean canBubble, 
> > +                                    in boolean cancelable, 
> > +                                    in DOMWindow view, 
> > +                                    in long detail);
> > +
> > +    };
> 
> Perhaps this should be prefixed with webkit, until there is more support for this standard.

do you mean -webkit-UIRequestEvent
or just -webkit-initUIRequestEvent for the constructor?
Comment 8 James Craig 2010-10-11 13:07:55 PDT
The main difference seems to be that our Undo and Redo *request* allows the web application to determine what (if anything) should be undone, or redone, where the HTML5 event manager requires that the user agent make the change directly to the DOM or editable content. The UIRequestEvent interface allows the app to determine the outcome of the events based on the business logic of the app, which the browser does not know about.

The reason these are all called 'request' events is because they don't change anything. They only send a 'request' to the web application (not to the user agent) to make a change on the user's behalf. The web application can then intercept or ignore the event as needed. If ignored (if the web app hasn't registered that event listener, or if the event is not canceled with preventDefault) then the user agent or assistive technology can fall back to whatever behavior is deemed appropriate, including then using the HTML5 undo manager.
Comment 9 James Craig 2010-10-11 13:15:42 PDT
I believe Ben is talking about adding the webkit prefix everywhere.

> WebkitUIRequestEvent
> initWebkitUIRequestEvent

as well as the client-side JS event listeners:

> webkitundorequest
> webkitredorequest
> webkitescaperequest
> webkitdeleterequest
Comment 10 chris fleizach 2010-10-26 12:00:56 PDT
Created attachment 71922 [details]
Patch
Comment 11 chris fleizach 2010-10-26 12:01:39 PDT
new patch added where everything is prefixed with webkit
added a new unit test that tests dispatching the events in the same manner than an AX client will dispatch them
Comment 12 Ojan Vafai 2010-10-26 16:30:39 PDT
Comment on attachment 71922 [details]
Patch

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.
Comment 13 James Craig 2010-10-26 18:47:31 PDT
Continued discussion is happening on the respective W3C lists, www-dom, wai-xtech, and pfwg. Current agreement between the DOM and PF groups is that this will become a standalone spec developed as a joint effort between the two working groups.
Comment 14 James Craig 2010-10-27 15:02:36 PDT
And I responded to Tony's email on webkit-dev. Thanks for the reminder. I overlooked it previously.
Comment 15 WebKit Review Bot 2010-10-27 15:09:34 PDT
Attachment 71922 [details] did not build on gtk:
Build output: http://queues.webkit.org/results/4759051
Comment 16 chris fleizach 2010-11-02 11:06:45 PDT
Subsequent discussion on webkit-dev did not yield any further comments from anyone. re-asking for review
Comment 17 Ojan Vafai 2010-11-02 12:48:37 PDT
(In reply to comment #16)
> Subsequent discussion on webkit-dev did not yield any further comments from anyone. re-asking for review

Sorry for the delay. I've chimed in again on the webkit-dev thread.
Comment 18 chris fleizach 2010-11-02 12:56:53 PDT
Created attachment 72719 [details]
Patch
Comment 19 Early Warning System Bot 2010-11-02 13:39:43 PDT
Attachment 72719 [details] did not build on qt:
Build output: http://queues.webkit.org/results/4962013
Comment 20 Eric Seidel 2010-11-02 14:46:48 PDT
Attachment 72719 [details] did not build on mac:
Build output: http://queues.webkit.org/results/4929028
Comment 21 chris fleizach 2010-11-02 14:50:23 PDT
Created attachment 72742 [details]
Patch
Comment 22 Eric Seidel 2010-11-02 14:52:08 PDT
Attachment 72719 [details] did not build on mac:
Build output: http://queues.webkit.org/results/4904015
Comment 23 chris fleizach 2010-11-05 16:07:45 PDT
Created attachment 73133 [details]
Patch
Comment 24 Adam Barth 2011-04-26 15:55:14 PDT
Comment on attachment 73133 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=73133&action=review

This proposal doesn't seem to have gotten a lot of traction.  Please feel free to renominate this patch if you're still interested in experimenting with this feature.  At a minimum, we'd want and an ENABLE macro to be able to disable this feature in some configurations.

> WebCore/ChangeLog:9
> +       "User Interface Independence for Accessible Rich Internet Applications"

Bad indent
Comment 25 James Craig 2011-04-27 07:45:42 PDT
Actually, the proposal has had a significant amount of traction. It's to be released as a joint spec from the DOM and PF working groups. I'm currently editing the internal working draft.
Comment 26 James Craig 2013-10-23 16:44:32 PDT
<rdar://problem/8230094>