[Bug 27333] Most user agents (Chrome, Firefox) seem to distinguish between space and enter. Enter submits the form, even for radio buttons, space selects the checkbox.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27333 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #6 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25844] Clarify or change the use of default action to avoid confusion
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25844 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #3 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28119] Reference to createEvent(FocusEvent)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28119 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #2 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25485] D3E and corelation with DOM4(W3C)/DOM(WHATWAG) and DOM3 Core
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25485 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #6 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25927] Specify the Event Loop integration for various non-deprecated events, incl. hit testing
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25927 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #3 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25967] Testing DOM L3 Events
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25967 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #1 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27825] DOM Level 3 KeyboardEvent key Values specification does not include core key values
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27825 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #1 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26227] Define that click doesn't fire on disabled elements
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26227 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #2 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25928] Converge with CSSOM-View
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25928 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #2 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26218] When .getModifierState(OS) should be true?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26218 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #8 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27129] [D3E-key]: Separator
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27129 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #2 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27996] [D3E-code] KeyboardEvent code spec should have featurephone section
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27996 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #1 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27827] Need to remove input/beforeinput event info from D3E and point to input event spec
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27827 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #2 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26611] [Proposal] Add Zoom event
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26611 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #7 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28029] Mouse coordinates represented in CSS pixels do not account for retina displays with window.devicePixelRatio 1.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28029 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #10 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27337] For synthetic activation, should the original event still be dispatched?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27337 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #3 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 26141] [D3E-Key] Needs more explicit explanation of MediaSelect, LaunchMediaPlayer and MediaApps
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26141 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #3 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
Re: CfC: publish Proposed Recommendation of Web Messaging; deadline March 28
On Sat, Mar 21, 2015 at 5:52 AM, Arthur Barstow art.bars...@gmail.com wrote: 2. http://www.w3c-test.org/webmessaging/without-ports/025.html; this test failure (which passes on IE) is considered an implementation bug (MessageChannel and MessagePort are supposed to be exposed to Worker) that is expected to be fixed. I'm not sure that we can really consider lack of support in Workers a bug. Worker support is generally non-trivial since it requires making an API work off the main thread. That said, mozilla has patches for worker support in progress right now, so hopefully Firefox can serve as second implementation here soon. / Jonas
[Bug 25968] Needs clearer definition of virtual keyboard's KeyboardEvent.code value if it doesn't emulate physical key event completely
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25968 Arthur Barstow art.bars...@gmail.com changed: What|Removed |Added CC||public-webapps@w3.org Component|DOM3 Events |UI Events --- Comment #3 from Arthur Barstow art.bars...@gmail.com --- Bulk move of all D3E bugs to the UI Events component. -- You are receiving this mail because: You are on the CC list for the bug.
CfC: publish Proposed Recommendation of Web Messaging; deadline March 28
As previously mentioned on [p-w], the test results for Web Messaging [All] indicate significant interoperability with only two tests that have less than two passes [2]. The two tests, including a short analysis of the failure, are: 1. http://www.w3c-test.org/webmessaging/with-ports/026.html; this test failure (which passes on Firefox) can be considered more of a Web IDL implementation issue and thus not a significant interop issue. 2. http://www.w3c-test.org/webmessaging/without-ports/025.html; this test failure (which passes on IE) is considered an implementation bug (MessageChannel and MessagePort are supposed to be exposed to Worker) that is expected to be fixed. Cindy created a Draft PR [PR] that includes Hixie's updates since the [CR] was published (but not the PortCollection interface [PC] which is not broadly implemented). Overall, we consider the changes since the CR as non-substantive bug fixes and clarifications that align the spec with current implementations, and that the test suite tests the updated spec. See [Diff] for all of changes between the CR and the draft PR and note the draft PR's status section includes a short summary of the changes. As such, this is a Call for Consensus to publish a Proposed Recommendation of Web Messaging using the [PR] as the basis. Agreement with this CfC means you consider the test results shows interoperability and the changes since CR are not substantive. If you have any comments or concerns about this CfC, please reply to this e-mail by March 28 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. If there are no non-resolvable objections to this proposal, the motion will carry and we will request the PR be published. -Thanks, ArtB [p-w] https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0627.html [All] http://w3c.github.io/test-results/webmessaging/all.html [2] http://w3c.github.io/test-results/webmessaging/less-than-2.html [PR] http://www.w3.org/TR/2015/PR-webmessaging-20150407/ [CR] http://www.w3.org/TR/2012/CR-webmessaging-20120501/ [PC] http://dev.w3.org/html5/postmsg/#broadcasting-to-many-ports [Diff] https://www.diffchecker.com/qswiibb5
Re: Proposal for a Permissions API
Time to revise this topic. Two data points:
1) Particularly with pointerlock (but also with other permission prompts
that sneak up on the user) I often get the complaint from users along the
lines of I tried your stuff, but it didn't work. or I tried your stuff,
but it asked me to do X, I don't think it works.
2) MRI scans show that user attention dramatically drops when presented
with a security prompt:
http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/
Permission/Security prompts are bad UX. Particularly the kind you need to
prompt the user with along the way. And within that, even worse are the
ones that pop up again and again (like the fullscreen popup).
On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin jyass...@google.com wrote:
On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri mou...@lamouri.fr wrote:
On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
I'm generally supportive of this direction.
I'm not sure that that the PermissionStatus thing is needed. For
example in order to support bluetooth is might be better to make the
call look like:
permissions.has(bluetooth, fitbit).then(...);
That's more Permission than PermissionStatus, right?
What you proposed here would probably be something like that in WebIDL:
Promise has(PermissionName name, any options);
But really, we could make that option bag be a dictionary because it
gives good context about what you are passing like what does fitbit
means here? Is that a black listed device or a white listed one? The one
you want to target?
I agree that it might be unusual to have a required name than might
often be used alone but it makes the API way more javascript-y and self
explanatory. IMO, this call is nicer to read than the one you wrote
above:
permissions.has({ name: 'bluetooth', devices: 'fitbit' });
because I understand what the call is trying to do. In addition, as you
pointed, it gives a lot of flexibility.
Belatedly, I'd like to suggest a slightly different model. Instead of
trying to stuff arbitrary queries into the permissions.has() call,
maybe expose the current permissions as data, and let the application
inspect them using custom code. This is likely to work better for
Bluetooth, since we're planning to have pages request devices by the
Services they expose, not their deviceIds, and a page may want to
check for either an available device exposing some services, or that a
device they've already opened hasn't been revoked.
Getting permission revocation to update a UI correctly is also an
interesting problem. You could expose an event on permission change,
but given that templating frameworks are moving toward
Object.observe() to update themselves in response to model object
changes, that would require developers to write extra code to
propagate the permission changes into their models.
So what if navigator.permissions just _was_ a suitable model object?
Make it, say, a Map from permission-name to an object defined by the
permission's standard, and extend Map to expose enough synthetic
change records that Object.observe(a_map) is useful.
Jeffrey
