Bug 47301 - AX: Support UIRequestEvents from new W3C Proposal
: AX: Support UIRequestEvents from new W3C Proposal
Status: NEW
: WebKit
Accessibility
: 528+ (Nightly build)
: PC Mac OS X 10.5
: P2 Normal
Assigned To:
:
: InRadar
:
:
  Show dependency treegraph
 
Reported: 2010-10-06 13:56 PST by
Modified: 2013-10-23 16:44 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


------- Comment #1 From 2010-10-06 15:20:34 PST -------
Created an attachment (id=69999) [details]
Patch
------- Comment #2 From 2010-10-06 15:50:13 PST -------
Attachment 69999 [details] did not build on qt:
Build output: http://queues.webkit.org/results/4251055
------- Comment #3 From 2010-10-06 16:45:43 PST -------
Created an attachment (id=70011) [details]
Patch
------- Comment #4 From 2010-10-07 10:46:10 PST -------
Created an attachment (id=70115) [details]
Patch
------- Comment #5 From 2010-10-09 12:30:11 PST -------
(From update of attachment 70115 [details])
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 From 2010-10-11 09:16:03 PST -------
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 From 2010-10-11 11:24:12 PST -------
> 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 From 2010-10-11 13:07:55 PST -------
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 From 2010-10-11 13:15:42 PST -------
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 From 2010-10-26 12:00:56 PST -------
Created an attachment (id=71922) [details]
Patch
------- Comment #11 From 2010-10-26 12:01:39 PST -------
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 From 2010-10-26 16:30:39 PST -------
(From update of attachment 71922 [details])
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 From 2010-10-26 18:47:31 PST -------
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 From 2010-10-27 15:02:36 PST -------
And I responded to Tony's email on webkit-dev. Thanks for the reminder. I overlooked it previously.
------- Comment #15 From 2010-10-27 15:09:34 PST -------
Attachment 71922 [details] did not build on gtk:
Build output: http://queues.webkit.org/results/4759051
------- Comment #16 From 2010-11-02 11:06:45 PST -------
Subsequent discussion on webkit-dev did not yield any further comments from anyone. re-asking for review
------- Comment #17 From 2010-11-02 12:48:37 PST -------
(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 From 2010-11-02 12:56:53 PST -------
Created an attachment (id=72719) [details]
Patch
------- Comment #19 From 2010-11-02 13:39:43 PST -------
Attachment 72719 [details] did not build on qt:
Build output: http://queues.webkit.org/results/4962013
------- Comment #20 From 2010-11-02 14:46:48 PST -------
Attachment 72719 [details] did not build on mac:
Build output: http://queues.webkit.org/results/4929028
------- Comment #21 From 2010-11-02 14:50:23 PST -------
Created an attachment (id=72742) [details]
Patch
------- Comment #22 From 2010-11-02 14:52:08 PST -------
Attachment 72719 [details] did not build on mac:
Build output: http://queues.webkit.org/results/4904015
------- Comment #23 From 2010-11-05 16:07:45 PST -------
Created an attachment (id=73133) [details]
Patch
------- Comment #24 From 2011-04-26 15:55:14 PST -------
(From update of attachment 73133 [details])
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 From 2011-04-27 07:45:42 PST -------
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 From 2013-10-23 16:44:32 PST -------
<rdar://problem/8230094>