Bug 47301 – AX: Support UIRequestEvents from new W3C Proposal

• Component: Accessibility
• Status: RESOLVED WONTFIX

[chris fleizach]

We should support UIRequestEvents from 
http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html

[chris fleizach]

Created attachment 69999 [details]
Patch

[Early Warning System Bot]

Attachment 69999 [details] did not build on qt:
Build output: http://queues.webkit.org/results/4251055

[chris fleizach]

Created attachment 70011 [details]
Patch

[chris fleizach]

Created attachment 70115 [details]
Patch

[Sam Weinig]

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.

[Olli Pettay (:smaug)]

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.

[chris fleizach]

> 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?

[James Craig]

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.

[James Craig]

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

[chris fleizach]

Created attachment 71922 [details]
Patch

[chris fleizach]

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

[Ojan Vafai]

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.

[James Craig]

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.

[James Craig]

And I responded to Tony's email on webkit-dev. Thanks for the reminder. I overlooked it previously.

[WebKit Review Bot]

Attachment 71922 [details] did not build on gtk:
Build output: http://queues.webkit.org/results/4759051

[chris fleizach]

Subsequent discussion on webkit-dev did not yield any further comments from anyone. re-asking for review

[Ojan Vafai]

(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.

[chris fleizach]

Created attachment 72719 [details]
Patch

[Early Warning System Bot]

Attachment 72719 [details] did not build on qt:
Build output: http://queues.webkit.org/results/4962013

[Eric Seidel (no email)]

Attachment 72719 [details] did not build on mac:
Build output: http://queues.webkit.org/results/4929028

[chris fleizach]

Created attachment 72742 [details]
Patch

[Eric Seidel (no email)]

Attachment 72719 [details] did not build on mac:
Build output: http://queues.webkit.org/results/4904015

[chris fleizach]

Created attachment 73133 [details]
Patch

[Adam Barth]

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

[James Craig]

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.

[James Craig]

<rdar://problem/8230094>