We should support UIRequestEvents from http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html
Created attachment 69999 [details] Patch
Attachment 69999 [details] did not build on qt: Build output: http://queues.webkit.org/results/4251055
Created attachment 70011 [details] Patch
Created attachment 70115 [details] Patch
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.
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.
> 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?
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.
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
Created attachment 71922 [details] Patch
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 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.
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.
And I responded to Tony's email on webkit-dev. Thanks for the reminder. I overlooked it previously.
Attachment 71922 [details] did not build on gtk: Build output: http://queues.webkit.org/results/4759051
Subsequent discussion on webkit-dev did not yield any further comments from anyone. re-asking for review
(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.
Created attachment 72719 [details] Patch
Attachment 72719 [details] did not build on qt: Build output: http://queues.webkit.org/results/4962013
Attachment 72719 [details] did not build on mac: Build output: http://queues.webkit.org/results/4929028
Created attachment 72742 [details] Patch
Attachment 72719 [details] did not build on mac: Build output: http://queues.webkit.org/results/4904015
Created attachment 73133 [details] Patch
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
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.
<rdar://problem/8230094>