Re: Scrolling when document.documentElement requests fullscreen
On Fri, 07 Sep 2012 01:32:07 +0200, Chris Pearce cpea...@mozilla.com
wrote:
We've had a couple of bugs filed against Gecko recently about scrolling
fullscreen content.
Currently behaviour differs between Chrome and Gecko when fullscreen is
requested on document.documentElement. When this happens Chrome still
shows the viewport/browser scrollbars, but Gecko does not show viewport
scrollbars.
For example, compare the behaviour of
http://robnyman.github.com/fullscreen/index-high-content.html in Chrome
and Firefox.
Our developer evangelists tells us that authors intuitively expect
scrollbars when requesting fullscreen on document.documentElement.
Authors expect that since the document is scrollable (via the viewport
scrollbars) before entering fullscreen it should remain scrollable after
entering fullscreen.
Gecko does not show viewport scrollbars when requesting fullscreen on
document.documentElement since the :fullscreen psuedoclass's
position:fixed positioning styles cause it to be unscrollable. I don't
know why Chrome shows scrollbars in this case.
We're proposing in the relevant Mozilla bug [1] to change our
implementation so that the :fullscreen pseudoclass rule is :not(:root).
This would mean that document.documentElement would still be scrollable
after entering fullscreen, which would then match authors' expectations.
i.e.:
*|*:not(:root):fullscreen {
position: fixed;
top:0; right:0; bottom:0; left:0;
/* etc... */
}
Before I make this change in Gecko I'd like to get consensus from other
implementers that we want this behaviour, and get the spec changed to
reflect that.
Sounds good to me.
Regards,
Chris Pearce.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=779286#c18
--
Simon Pieters
Opera Software
Re: Sync API for workers
On Thu, Sep 6, 2012 at 7:18 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Sep 6, 2012 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote: That is certainly an interesting use case. I think another interesting use case is being able to write synchronous APIs in workers whose implementation uses APIs that are only available on the main thread. I understand the concept, but I'm having trouble coming up with useful examples. Can you give one? I have one: virtualizing the API of the main thread in a worker. In Treehouse [1], we sandbox untrusted JS in a worker, where we provide a virtual browser interface - including the DOM (using a hacked up fork of jsdom). This allows us to (1) restrict the guest code to a subset of the DOM, and (2) interpose on privileged operations. At present, we present a synchronous interface to the virtual DOM and then replicate changes back to the actual DOM in the main thread asynchronously. This works surprisingly well, but has some limitations. First, concurrent access to a given DOM node from more than one worker is a difficult problem, so we punt and require that a node may appear in at most one virtual DOM. Second, we do not know how to virtualize some synchronous methods and properties, such as window.prompt. I believe that a synchronous messaging API would allow us to overcome both of these issues. [1] Treehouse PDF: https://www.usenix.org/system/files/conference/atc12/atc12-final159.pdf -- Lon Ingram @lawnsea
Call for Review of Content Security Policy 1.0
The Web Application Security Working Group at the W3C is planning to advance Content Security Policy 1.0 to Candidate Recommendation - a final set of features and syntax - and is seeking wide review of the document at this time. We would especially value the input of members of the WebApps WG. http://www.w3.org/TR/2012/WD-CSP-20120710/ Content Security Policy is a mechanism web applications can use to mitigate a broad class of content injection vulnerabilities, such as cross-site scripting (XSS). Content Security Policy is a declarative policy that lets the authors (or server administrators) of a web application restrict from where the application can load resources. To mitigate XSS, for example, a web application can restrict itself to loading scripts only from known, trusted URIs, making it difficult for an attacker who can inject content into the web application to inject malicious script. Content Security Policy (CSP) is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth, to reduce the harm caused by content injection attacks. There is often a non-trivial amount of work required to apply CSP to an existing web application. To reap the greatest benefit, authors will need to move all inline script and style out-of-line, for example into external scripts, because the user agent cannot determine whether an inline script was injected by an attacker. To take advantage of CSP, a web application opts into using CSP by supplying a Content-Security-Policy HTTP header Such policies apply the current resource representation only. To supply a policy for an entire site, the server needs to supply a policy with each resource representation. Please submit comments to public-webapp...@w3.orgmailto:public-webapp...@w3.org Thank you, Brad Hill Co-Chair W3C Web Application Security WG
Re: Proposal to add USB keycodes to the current DOM3 key events
(Including the contents of entire document inline so that the info is
easier to skim/comment on.)
-Gary Kacmarcik (gary...@chromium.org
Proposal for enhancing the current DOM Level 3 key events with USB scancodes
Status: DRAFT
Authors: Gary Kacmarcik, James Weatherall
The current DOM Level 3 key event spec improves considerably upon the
legacy HTML4 key events that are currently used by most browsers.
The HTML4 events have always been problematic because the lack of a
detailed specification for the events led to implementation
inconsistencies on the various platform/browser combinations. The DOM
Level 3 proposal seeks to address this problem by specifying exactly
how these key events should be encoded.
However, there are still cases where the current proposal does not
provide enough information about the key event to perform desirable
tasks. In some cases, the legacy event values actually provide more
(internally) consistent information about the events.
Problems with the current DOM Level 3 key events
Problem 1: Matching keydown and keyup events
The main problem with the current proposal is that it doesn't provide
enough information so that keyup events can be matched with their
corresponding keydown event. In this regard, it is unlike the legacy
events, where the keyCode value was usually sufficient to match the
keydown/keyup events.
For examples of why this is a problem, consider the following scenarios:
* Games and other applications which treat the keyboard as a large
collection of buttons need to be able to keep track of which keys are
currently being held down. Since there is no API to query the current
keyboard state, it is crucial that apps be able to match every keyup
event with the originating keydown event.
* Applications that provide remote access functionality often need to
keep track of the sequence of events that generated a particular
character. This is so that they can handle the case where the local
and remote systems have different keyboard layouts (since they may
require a different sequence of keys or modifiers to be injected on
the remote machine).
Appendix A (at the end of this document) contains some sample key
event sequences that demonstrate this problem. The simple case of
typing a shifted character (the '@' sign) works fine in the normal
case, but if the Shift key is released too early then the keyup will
have a different value than the original keydown. This inconsistency
makes it difficult to match the keyup with the originating keydown.
Note that since these event values are dependent on the current
keyboard layout, there is no simple mapping table between the shifted
and unshifted version of each key. The international keyboard layout
examples in Appendix A demonstrate this complication.
Problem 2: Identifying keys by their position
-
While not as critical as the first problem, another common task for
some applications (typically games) is to handle key events based on
the key's position on the keyboard. For example, a game may want to
detect when the key next to the CapsLock key is pressed so it can be
associated with some player action. With a US keyboard, this would be
the key with the 'A' keycap, but on an AZERTY keyboard, this key would
have a 'Q' keycap.
A layout-independent way of identifying keys would be useful to games,
music/beatbox players, and other apps that prefer to consider the
keyboard as a set of buttons. A touch-typing app could also use
information to this target lessons for the home row or for the
left/right hand.
(Note that some implementations of HTML4 key events suffer from this
problem as well. For example, the keycodes in WebKit-based browsers
are based on Windows VKEY values, which are layout-dependent.)
Proposal
Our proposal to address these problems is to add a new field that
contains the USB Usage Page and Usage ID codes for keydown and keyup
events.
In this proposal, the KeyboardEvent would be extended to include:
interface KeyboardEvent : UIEvent
{
...
readonly attribute unsigned long usbUsage;
...
};
The usbUsage field is a combination of the USB Usage Page (upper
16-bits) and the USB Usage ID (lower 16-bits). Some example usbUsage
codes are given in Appendix B, but a complete list can be found in the
USB HID Usage Tables documentation (see References).
The vast majority of these codes would come from Usage Page 0x07,
which contains Keyboard/Keypad values. However, many modern keyboards
contain specialized media keys which would have values defined in
other Usage Pages.
Providing this information in addition to the currently specified
fields would be address the problems described earlier:
Solving Problem 1 : Easy to match keydown with keyup
Since the USB key values are associated with the individual keys, the
value would not depend on
RE: Proposal to add USB keycodes to the current DOM3 key events
From: gary...@google.com [mailto:gary...@google.com] On Behalf Of Gary Hi all, I've written up a brief proposal to enhance the current DOM Level 3 key events by adding USB keycodes. Here is a link to the proposal document: https://docs.google.com/document/d/1eJvlUaTBsWa71hIc0X4s6SrCopX9LCPs1YOAuV luxBs/edit Nice. Yes, getting the keyboard layout-independent position of a key was specifically out-of-scope for DOM Level 3 Events. I don't know much about the USB key codes, but it looks promising as a standard way of getting key location interop across OS/languages. I did want to call out a sentence from you problem statement: Games and other applications which treat the keyboard as a large collection of buttons need to be able to keep track of which keys are currently being held down. ***Since there is no API to query the current keyboard state***, it is crucial that apps be able to match every keyup event with the originating keydown event. An old strawman was proposed in 2009 for this: http://www.w3.org/2008/webapps/wiki/Query_Key_Status, but is still worth pursuing/revising.
Re: Proposal to add USB keycodes to the current DOM3 key events
On Fri, Sep 7, 2012 at 11:44 AM, Travis Leithead travis.leith...@microsoft.com wrote: From: gary...@google.com [mailto:gary...@google.com] On Behalf Of Gary I've written up a brief proposal to enhance the current DOM Level 3 key events by adding USB keycodes. Nice. Yes, getting the keyboard layout-independent position of a key was specifically out-of-scope for DOM Level 3 Events. I don't know much about the USB key codes, but it looks promising as a standard way of getting key location interop across OS/languages. I did want to call out a sentence from you problem statement: Games and other applications which treat the keyboard as a large collection of buttons need to be able to keep track of which keys are currently being held down. ***Since there is no API to query the current keyboard state***, it is crucial that apps be able to match every keyup event with the originating keydown event. An old strawman was proposed in 2009 for this: http://www.w3.org/2008/webapps/wiki/Query_Key_Status, but is still worth pursuing/revising. Thanks for the comments! I agree that an API to query the keyboard state is definitely worthwhile, but I feel this proposal is independent from whatever decision we eventually make with regard to a QueryKeyStatus API. The most serious problem with the current key event spec is that there is no reliable way to link keyup events with the corresponding keydown event. Even if we added a QueryKeyStatus API, this would still be broken. -Gary
