Re: [webvr] [gamepad] Missing VRPose for tracked controllers

On Tue, May 24, 2016 at 8:50 PM, Brandon Jones wrote: > > but Yaw probably just initializes to whatever position the user started > with. > Applications for these kinds of controllers usually have some "reset forward" thing. Sometimes the settings of the device do (as is the

Re: [webvr] Re: [gamepad] Missing VRPose for tracked controllers

; well (think about the Nintendo Wii controllers!), however. So my > suggestion to add it to the Gamepad API still stands. > > Regards, > -Sven Neuhaus > > Am 23.05.2016 um 15:52 schrieb Florian Bösch: > > The WebVR API models HMD pose and will model the gesture controllers. &g

Re: [gamepad] Missing VRPose for tracked controllers

The WebVR API models HMD pose and will model the gesture controllers. https://mozvr.com/webvr-spec/ On Tue, May 17, 2016 at 9:41 AM, Sven Neuhaus wrote: > Hello, > > I read the gamepad API description at > https://developer.mozilla.org/en-US/docs/Web/API/Gamepad > > I think the

Re: [gamepad] New feature proposals: pose, touchpad, vibration

On Mon, Apr 25, 2016 at 4:31 AM, Chris Van Wiemeersch wrote: > > If you take a look at all the content libraries out there for the Gamepad > API, there's a ridiculous amount of logic and special casing web developers > are having to do just between the Firefox and Chrome

Re: File API - where are the missing parts?

On Tue, Feb 23, 2016 at 7:06 PM, Joshua Bell <jsb...@google.com> wrote: > On Tue, Feb 23, 2016 at 7:12 AM, Florian Bösch <pya...@gmail.com> wrote: > >> On Tue, Feb 23, 2016 at 2:48 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> >>> Is the last bullet h

Re: File API - where are the missing parts?

On Tue, Feb 23, 2016 at 2:48 AM, Jonas Sicking wrote: > Is the last bullet here really accurate? How can you use existing APIs to > listen to file modifications? > I have not tested this on all UAs, but in Google Chrome what you can do is to set an interval to check a

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

, 2015 at 2:05 PM, Aymeric Vitte <vitteayme...@gmail.com> wrote: > > > Le 02/12/2015 13:18, Florian Bösch a écrit : > > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte <vitteayme...@gmail.com > > <mailto:vitteayme...@gmail.com>> wrote: > > > &

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

(which guarantees ordering)... On Wed, Dec 2, 2015 at 3:54 PM, Richard Barnes <rbar...@mozilla.com> wrote: > > > On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch <pya...@gmail.com> wrote: > >> 1) Encryption between Alice and Bob by means of an asymmetric >> pub

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte wrote: > > Then you should follow your rules and apply this policy to WebRTC, ie > allow WebRTC to work only with http. > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP. Also WebRTC does P2P, and there's

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes wrote: > 1. Authentication: You know that you're talking to who you think you're > talking to. > And then Dell installs a their own root authority on machines they ship, or your CA of choice gets pwn'ed or the NSA uses some

Re: [pointerlock] Oct 2015 Pointer Lock Status

On Sun, Nov 1, 2015 at 9:08 PM, Vincent Scheib wrote: > > Thanks for clarifying. Basic usage is demonstrated in the wild but some > edge cases should have clear demonstration in the test suite. I will > generate those as other project priorities allow (and would of course >

Re: Clipboard API: remove dangerous formats from mandatory data types

On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should at least give guidance on how to present the capability in a safe way. Which is exactly the core of my question. If you intend

Re: Clipboard API: remove dangerous formats from mandatory data types

Or should we just place that into application/octet-stream and hope whoever listens for the clipboard scans the magic bytes of an OpenEXR? On Thu, Jun 25, 2015 at 2:56 PM, Florian Bösch pya...@gmail.com wrote: Well let's say some webapp generates an OpenEXR and wants to put

Re: Clipboard API: remove dangerous formats from mandatory data types

No idea. Also doesn't matter jack. There could be some now or in the future. There's a variety of programs that support HDRi (photoshop, lightroom, hdri-studio, etc.). It's fairly logical that at some point some or another variant of HDR format will make its way into clipboards. The same applies

Re: Clipboard API: remove dangerous formats from mandatory data types

On Thu, Jun 25, 2015 at 2:58 PM, Florian Bösch pya...@gmail.com wrote: the magic bytes of an OpenEXR? Which is 0x762f3101 btw.

Re: Clipboard API: remove dangerous formats from mandatory data types

it directly on the local system clipboard. What is it that you're actually proposing? On Thu, 25 Jun 2015 at 13:31 Florian Bösch pya...@gmail.com wrote: No idea. Also doesn't matter jack. There could be some now or in the future. There's a variety of programs that support HDRi (photoshop, lightroom

Re: Clipboard API: remove dangerous formats from mandatory data types

to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific formats, but IMO the spec should

Re: Clipboard API: remove dangerous formats from mandatory data types

rise to widely confusing and homebrewn workarounds till out of that broil another mime-type standard emerged that browsers sought to repress. On Thu, Jun 25, 2015 at 4:30 PM, Florian Bösch pya...@gmail.com wrote: I'm pretty sure it can't be in the interest of this specification to force

Re: Clipboard API: remove dangerous formats from mandatory data types

-typed file? Again, I'm unclear as to what the alternative is that you're proposing? On Thu, 25 Jun 2015 at 15:27 Florian Bösch pya...@gmail.com wrote: Surely you realize that if the specification where to state to only safely expose data to the clipboard, this can only be interpreted to deny

Re: Clipboard API: remove dangerous formats from mandatory data types

native clipboards each have their own content-type annotations). So it sounds like you're saying we should also remove application/octet-stream as a mandatory format? On Thu, 25 Jun 2015 at 15:55 Florian Bösch pya...@gmail.com wrote: It's very simple. Applications need to know what's

Re: Clipboard API: remove dangerous formats from mandatory data types

currently up to individual user agents to decide whether they can support that format safely. On Thu, 25 Jun 2015 at 14:16 Florian Bösch pya...@gmail.com wrote: On Thu, Jun 25, 2015 at 3:13 PM, Wez w...@google.com wrote: I think there's obvious value in support for arbitrary content-specific

Re: Clipboard API: remove dangerous formats from mandatory data types

turning into thousands of lines of gibberish because they tried to stuff binary data in text/plain. Daniel On Thu, Jun 25, 2015 at 8:23 AM Florian Bösch pya...@gmail.com wrote: No, what I'm saying is that if you restrict mime types (or don't explicitly prohibit such restriction), but require

Re: Clipboard API: remove dangerous formats from mandatory data types

it anytime soon. Daniel On Thu, Jun 25, 2015 at 10:38 AM Florian Bösch pya...@gmail.com wrote: Yet you restrict mime-types AND you support application/octet-stream? On Thu, Jun 25, 2015 at 7:34 PM, Daniel Cheng dch...@google.com wrote: For reasons I've already mentioned, this isn't going

Re: Clipboard API: remove dangerous formats from mandatory data types

My point is that if you leave no other way out, that is what will happen. On Thu, Jun 25, 2015 at 7:57 PM, Daniel Cheng dch...@google.com wrote: That's the case today already, and I haven't seen this happening. Daniel On Thu, Jun 25, 2015 at 10:48 AM Florian Bösch pya...@gmail.com wrote

Re: Clipboard API: remove dangerous formats from mandatory data types

I think you underestimate the integrative need that web-apps will acquire and the lengths they will go to faced with a business need to make it work once clipboard API becomes common developer knowledge.

Re: Clipboard API: remove dangerous formats from mandatory data types

And how exactly do you intend to support for instance OpenEXR? On Wed, Jun 24, 2015 at 5:44 PM, Wez w...@google.com wrote: Hallvord, Yes, content would be limited to providing text, image etc data to the user agent to place on the clipboard, and letting the user agent synthesize whatever

Re: Clipboard API: remove dangerous formats from mandatory data types

spec, is it..? On Wed, Jun 24, 2015, 18:49 Florian Bösch pya...@gmail.com wrote: And how exactly do you intend to support for instance OpenEXR? On Wed, Jun 24, 2015 at 5:44 PM, Wez w...@google.com wrote: Hallvord, Yes, content would be limited to providing text, image etc data to the user

Re: Clipboard API: remove dangerous formats from mandatory data types

What about JPEG 2000, Exif, TIFF, RIF, BMP, PM, PGM, PBM, PNM, HDR, EXR, BPG, psd, xcf, etc.?

Re: Clipboard API: remove dangerous formats from mandatory data types

On Thu, Jun 11, 2015 at 8:32 PM, Daniel Cheng dch...@google.com wrote: On Thu, Jun 11, 2015 at 11:13 AM Florian Bösch pya...@gmail.com wrote: What about JPEG 2000, Exif, TIFF, RIF, BMP, PM, PGM, PBM, PNM, HDR, EXR, BPG, psd, xcf, etc.? I'm not sure what you're trying to say here. What

Re: Clipboard API: remove dangerous formats from mandatory data types

Besides, if html clipboards will be crippled beyond usability by security paranoia, you'll just use good'ol flash to copy your random bytes to the clipboard again.

Re: Clipboard API: remove dangerous formats from mandatory data types

If you can't put an image/png into a clipboard from JS, you just put it into an application/octet-stream, which many image editors will load just happily. If that doesn't work, you just stick your PNG into a plain/text, which many image editors will still load just fine.

Re: Clipboard API: remove dangerous formats from mandatory data types

Wait, why are you talking about removing an ostensibly useful feature (declaring a mimetype in a paste for certain mime types) because the end result could land up in the users paste, where it could be pasted into applications that're not equipped to handle random assemblages of bytes, even though

Re: Clipboard API: remove dangerous formats from mandatory data types

On a further note. If UAs (which are among the more prevalent applications out there being used) intentionally disable declaring mime-types for some classes of content, so that it can't be pasted into applications that might not be equipped to handle those mimetypes, application programmers (such

Re: Clipboard API: remove dangerous formats from mandatory data types

Oh, also while you're on crippling things, please also exclude copying any text that contains http://:; cause that borks skype.

Re: PSA: publishing new WD of Gamepad on April 14

for the pressable buttons then? That would alleviate most of my concerns with the polling model, and I think you're right it's harder to apply it to axes given that there are effectively two inputs working simultaneously. Ashley On 9 April 2015 at 22:29, Florian Bösch pya...@gmail.com wrote

Re: PSA: publishing new WD of Gamepad on April 14

The polling model for axes has a significant advantage as I'll illustrate. Suppose you're steering a cursor of some kind in 2 dimensions. That cursor would also draw a trail/line whatever. Here's what happens if you apply this logic on events per axis: You get a staircase. Why? Because the X-axis

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

On Thu, Apr 2, 2015 at 2:40 PM, Anders Rundgren anders.rundgren@gmail.com wrote: Obviously we need a model where the code is vetted for DoingTheRightThing(tm). This is essentially about two things: trust and the capability to vet. Both of these things cannot be solved conclusively, or

Re: Pointer lock spec

On Wed, Apr 1, 2015 at 1:49 AM, Vincent Scheib sch...@google.com wrote: You raised this point in 2011, resulting in my adding this spec section you reference. The relevant bit being: ... a concern of specifying what units mouse movement data are provided in. This specification defines

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

On Wed, Apr 1, 2015 at 11:22 AM, Nilsson, Claes1 claes1.nils...@sonymobile.com wrote: Hi all, Related to the recent mail thread about the SysApps WG and its deliverables I would like to make a report of the status of the TCP and UDP Socket API,

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

... On Wed, Apr 1, 2015 at 6:44 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Apr 1, 2015 at 6:37 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote: Not saying that we can use CORS to solve this, or that we should extend CORS to solve

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

On Wed, Apr 1, 2015 at 6:02 PM, Jonas Sicking jo...@sicking.cc wrote: Not saying that we can use CORS to solve this, or that we should extend CORS to solve this. My point is that CORS works because it was specified and implemented across browsers. If we'd do something like what Domenic

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

On Wed, Apr 1, 2015 at 9:00 PM, Anders Rundgren anders.rundgren@gmail.com wrote: Who would like to get something like that in their face when buying stuff on the web? 14% of users recognize changes in content of a security prompt. An MRI scan shows that at the second security prompt in a

Re: Proposal for a Permissions API

On Sat, Mar 21, 2015 at 10:47 PM, Florian Bösch pya...@gmail.com wrote: 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/ It's also likely

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

Re: Pointer lock spec

I'd like to comment on the pointer lock functionality some. 12.4 notes that capturing a (a native) pointer inside of a rectangle is difficult. I've done some research into this topic and I can attest that it's not straightforward. Some platforms have support for this semantics, others (I think it

Re: The futile war between Native and Web

On Mon, Feb 16, 2015 at 9:08 AM, Jeffrey Walton noloa...@gmail.com wrote: I'd hardly consider an account holder's data as high value. Medium at best and likely low value. But that's just me. Of course if the data is compromised it means that an attacker can also remote-control your e-banking

Re: do not deprecate synchronous XMLHttpRequest

On Fri, Feb 6, 2015 at 7:38 PM, Michaela Merz michaela.m...@hermetos.com wrote: it would be the job of the browser development community to find a way to make such calls less harmful. If there was a way to make synchronous calls less harmful, it'd have been implemented a long time ago. There

Re: do not deprecate synchronous XMLHttpRequest

I had an Android device, but now I have an iPhone. In addition to the popup problem, and the fake X on ads, the iPhone browsers (Safari, Chrome, Opera) will start to show a site, then they will lock up for 10-30 seconds before finally becoming responsive. Via. Ask Slashdot:

Re: Allow custom headers (Websocket API)

On Thu, Feb 5, 2015 at 2:39 PM, Takeshi Yoshino tyosh...@google.com wrote: To prevent WebSocket from being abused to attack existing HTTP servers from malicious non-simple cross-origin requests, we need to have WebSocket clients to do some preflight to verify that the server is not an HTTP

Re: Allow custom headers (Websocket API)

On Thu, Feb 5, 2015 at 2:35 PM, Anne van Kesteren ann...@annevk.nl wrote: Wouldn't that require the endpoint to support two protocols? That sounds suboptimal. CORS and Websockets are two separate protocols which each work off and by themselves, there is no change required to either to make

Re: Allow custom headers (Websocket API)

. On Thu, Feb 5, 2015 at 2:41 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Feb 5, 2015 at 2:39 PM, Florian Bösch pya...@gmail.com wrote: On Thu, Feb 5, 2015 at 2:35 PM, Anne van Kesteren ann...@annevk.nl wrote: Wouldn't that require the endpoint to support two protocols? That sounds

Re: Allow custom headers (Websocket API)

On Thu, Feb 5, 2015 at 2:44 PM, Takeshi Yoshino tyosh...@google.com wrote: IIUC, CORS prevents clients from issuing non-simple cross-origin request (even idempotent methods) without verifying that the server understands CORS. That's realized by preflight. Incorrect, the browser will perform

Re: Allow custom headers (Websocket API)

deployments. Either way, this will result in no change made, so you can burry it right here. On Thu, Feb 5, 2015 at 2:12 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Feb 5, 2015 at 1:27 PM, Florian Bösch pya...@gmail.com wrote: CORS is an adequate protocol to allow for additional

Re: Allow custom headers (Websocket API)

On Thu, Feb 5, 2015 at 12:59 PM, Anne van Kesteren ann...@annevk.nl wrote: That is not sufficient to allow custom headers. Cross-origin (and WebSocket is nearly always cross-origin I think) custom headers require a preflight and opt-in on a per-header basis. Access-Control-Allow-Headers is

Re: Allow custom headers (Websocket API)

On Thu, Feb 5, 2015 at 1:22 PM, Anne van Kesteren ann...@annevk.nl wrote: I'm not sure how this is relevant. We are discussing adding the ability to the WebSocket API to set custom headers and whether the current protocol is adequate for that. CORS is an adequate protocol to allow for

Re: What I am missing

On Wed, Nov 19, 2014 at 4:26 AM, Michaela Merz michaela.m...@hermetos.com wrote: First: We need signed script code. We are doing a lot of stuff with script - we could safely do even more, if we would be able to safely deliver script that has some kind of a trust model. TLS exists. I am

Re: What I am missing

On Wed, Nov 19, 2014 at 5:00 AM, Michaela Merz michaela.m...@hermetos.com wrote: If signed code would allow special features - like true fullscreen https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Using_full_screen_mode or direct file access

Re: What I am missing

On Wed, Nov 19, 2014 at 6:35 AM, Michaela Merz michaela.m...@hermetos.com wrote: Well .. it would be a all scripts signed or no script signed kind of a deal. You can download malicious code everywhere - not only as scripts. Signed code doesn't protect against malicious or bad code. It only

Re: What I am missing

There are some models that are a bit better than trust by royalty (app-stores) and trust by hirarchy (TLS). One of them is trust flowing along flow limited edges in a graph (as in Advogato). This model however isn't free from fault, as when a highly trusted entity gets compromised, there's no

Re: What I am missing

On Wed, Nov 19, 2014 at 7:54 AM, Marc Fawzi marc.fa...@gmail.com wrote: So there is no way for an unsigned script to exploit security holes in a signed script? Of course there's a way. But by the same token, there's a way a signed script can exploit security holes in another signed script.

Re: [gamepad] Add an event-based input mechanism

Note that events for axis input can (when wrongly handled) lead to undesirable behavior. For instance, suppose you have a 2-axis input you use to plot a line on screen. If you poll the positions and then draw a line from the last position to the current position, you will get a smooth line.

Re: Proposal for a Permissions API

On Fri, Sep 5, 2014 at 11:14 AM, Mounir Lamouri mou...@lamouri.fr wrote: Note that the Permissions API model isn't requiring all APIs to abide by its model. Having no permissions at all for an API is a decent model if possible. For example, having a permission concept for input type='file'

Re: Proposal for a Permissions API

This is an issue to use, for a user. - http://codeflow.org/issues/permissions.html - http://codeflow.org/issues/permissions.jpg - In firefox it's a succession of popup It's also an issue to use for a developer, because the semantics and methods for requesting, getting, being denied and

Re: Proposal for a Permissions API

On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres mar...@marcosc.com wrote: This sets up an unrealistic straw-man. Are there any real sites that would need to show all of the above all at the same time? Let's say you're writing a video editor, you'd like: - To get access to the locations API

Re: Proposal for a Permissions API

I welcome this proposal because the permission dialog creep is certainly worrying. Opponents of some kind of permission management have pointed out that collated dialogs tend to just get ignored by users and blindly approved (as an example they list Android permission handling). While that may

Re: [Gamepad] Liveness of Gamepad objects

There's two aspects that should not be overlooked. 1. Some events only make sense in unison. For instance the input of a 2-axis knob. On many OS implementations, change events for each axis arrive separately in short succession. However to an application programmer, getting first the

Re: [Gamepad] Liveness of Gamepad objects

I think both semantics are workable. I'd likely prefer the gamepad state to be immutable from JS, because assigning state there is smelly. I'd also prefer the option that incurs less GC overhead if possible. Beyond that, I just think the implementations should be semantically and symbolically

Re: [gamepad] Haptic Feedback/Controller Vibration

(note that when I list an inconceivable amount of ridiculous device APIs to add, it's meant as satire of the idea that you should make a specialized API for every assemblage of sensors, motors and displays) On Fri, Apr 4, 2014 at 4:45 PM, Florian Bösch pya...@gmail.com wrote: On Fri, Apr 4

Re: [gamepad] Haptic Feedback/Controller Vibration

On Thu, Apr 3, 2014 at 5:19 PM, Ted Mielczarek t...@mozilla.com wrote: Spec'ing standard rumble motors that are found on all modern controllers seems sensible. Spec'ing a way to access a microphone/speaker that's present on a controller seems sensible. I think anything more complicated than

Re: [gamepad] Haptic Feedback/Controller Vibration

is a monolythic monster API that tries to be everything and the kitchensink in the end. On Thu, Apr 3, 2014 at 5:55 PM, Patrick H. Lauke re...@splintered.co.ukwrote: On 03/04/2014 16:43, Florian Bösch wrote: But even so, what do you want to end up with? What do YOU want to end up with? A single

Re: [gamepad] Haptic Feedback/Controller Vibration

On Thu, Apr 3, 2014 at 8:07 PM, Ted Mielczarek t...@mozilla.com wrote: Note: DirectInput has been deprecated in favor of XInput, a much simpler API that maps directly to the Xbox 360 controller: http://msdn.microsoft.com/en-us/library/windows/desktop/ee417001%28v=vs.85%29.aspx XInput is

Re: Proposal Virtual Reality View Lock Spec

Replied to Brandon Jones but not public, reposted below. On Wed, Mar 26, 2014 at 7:18 PM, Brandon Jones bajo...@google.com wrote: As for things like eye position and such, you'd want to query that separately (no sense in sending it with every device), along with other information about the

Re: [fullscreen] Problems with mouse-edge scrolling and games

On Mon, Feb 24, 2014 at 1:16 AM, Thibaut Despoulain thib...@artillery.comwrote: I've written a test for this here: http://codeflow.org/issues/software-cursor.html My observation from testing on linux is that I can't distinguish latency for the software cursor from the OS cursor (or not by

Re: [fullscreen] Problems with mouse-edge scrolling and games

On Mon, Feb 24, 2014 at 5:18 PM, Glenn Maynard gl...@zewt.org wrote: It's not the application's job to keep the mouse cursor responsive, it's the system's. Hiding the system mouse cursor and drawing one manually is always a bad idea. That's a wonderful argument. And now we look at an FPS

Re: [fullscreen] Problems with mouse-edge scrolling and games

On Mon, Feb 24, 2014 at 5:40 PM, Glenn Maynard gl...@zewt.org wrote: (More reasons: it's very likely that you'll end up implementing a cursor with different motion and acceleration, a different feel, than the real mouse cursor. It also breaks accessibility features, like mouse trails.) Oh I

Re: [fullscreen] Problems with mouse-edge scrolling and games

On Mon, Feb 24, 2014 at 6:47 PM, Brendan Eich bren...@secure.meer.netwrote: Glenn Maynard wrote: It's not the application's job to keep the mouse cursor responsive, it's the system's. Hiding the system mouse cursor and drawing one manually is always a bad idea. Agreed! Like I say, some

Re: [fullscreen] Problems with mouse-edge scrolling and games

On Mon, Feb 24, 2014 at 7:07 PM, Vincent Scheib sch...@google.com wrote: Windows has ClipCursor() and Linux has XGrabPointer(). Once we know we can implement the functionality, we can discuss how to express this in an API. Would using Quarz CGWarpMouseCursorPosition work where you'd clamp the

Re: [fullscreen] Problems with mouse-edge scrolling and games

be perceptively different from an OS cursor. On Mon, Feb 24, 2014 at 7:41 PM, Vincent Scheib sch...@google.com wrote: On Mon, Feb 24, 2014 at 10:37 AM, Florian Bösch pya...@gmail.com wrote: On Mon, Feb 24, 2014 at 7:07 PM, Vincent Scheib sch...@google.comwrote: Windows has ClipCursor

Re: [fullscreen] Problems with mouse-edge scrolling and games

On Mon, Feb 24, 2014 at 8:21 PM, Glenn Maynard gl...@zewt.org wrote: I think that going fullscreen is the right approach, since locking the mouse into the window while not fullscreen is really weird and rare, at least in Windows. It's quite common for games to have a cursor, grab the pointer

Re: [fullscreen] Problems with mouse-edge scrolling and games

On Sun, Feb 23, 2014 at 1:57 AM, Thibaut Despoulain thib...@artillery.com wrote: The issue with pointerlock is that it requires the app to draw its own cursor instead of the OS cursor I fully agree with motivation, it is usually preferrable to give the user an OS-themed cursor (not always,

Re: [fullscreen] Problems with mouse-edge scrolling and games

On Sun, Feb 23, 2014 at 9:55 AM, Florian Bösch pya...@gmail.com wrote: - Inability to use DOM elements with mouse events for a game overlay/HUD. The test I've written here http://codeflow.org/issues/software-cursor.html also tests mouse event synthesis (as hinted at by an example

Re: [fullscreen] Problems with mouse-edge scrolling and games

On Sun, Feb 23, 2014 at 4:18 PM, Brandon Jones bajo...@google.com wrote: - it's possible to theme the OS cursor using custom images with CSS. https://developer.mozilla.org/en-US/docs/Web/CSS/cursor/url Although that doesn't absolve vendors from fixing the latency issue even if native pointers

Re: [fullscreen] Problems with mouse-edge scrolling and games

On Sat, Feb 22, 2014 at 11:22 PM, Florian Bösch pya...@gmail.com wrote: Caveat, I think Firefoxes implementaiton of the Pointerlock API might not follow the specification yet to make it possible to have pointerlock without fullscreen. Just checked this against a test I wrote a while ago http

Re: [fullscreen] Problems with mouse-edge scrolling and games

Pointerlock should solve these problems in the following fashion: - When the user clicks into the app, request pointerlock - Use it to give him a cursor drawn by you - That way you can keep the interaction inside your game and accurately detect borders etc. I run

Re: [Gamepad] spec status

I think the user unfriendlyness derives from that you can't open that page which you've played before and have it just work. Maybe the UA could remember the devices you enabled?

Re: ZIP archive API?

On Tue, May 7, 2013 at 8:09 AM, Jonas Sicking jo...@sicking.cc wrote: You're arguing for allowing accessing files inside ZIPs by URL, which means you're going to have to do the work anyway, since you'd be able to create a blob URL, reference a file inside it using XHR, and get a Blob as a

Re: ZIP archive API?

The main reason to use an archive (other than the space-savings) for me is to be able to transfer tens of thousands of small items that go into producing WebGL applications of non trivial scope. On Mon, May 6, 2013 at 1:27 PM, Robin Berjon ro...@w3.org wrote: On 03/05/2013 21:05 , Florian

Re: ZIP archive API?

I'm interested a JS API that does the following: Unpacking: - Receive an archive from a Dataurl, Blob, URL object, File (as in filesystem API) or Arraybuffer - List its content and metadata - Unpack members to Dataurl, Blob, URL object, File or Arraybuffer Packing: - Create an archive - Put in

Re: ZIP archive API?

below. I would definitely like to have the API available on both workers and normal context. Thanks, Paul From: Florian Bösch pya...@gmail.com Date: Fri, 3 May 2013 14:52:36 +0200 To: Anne van Kesteren ann...@annevk.nl Cc: Paul Bakaus pbak...@zynga.com, Charles McCathie Nevile cha

Re: [Gamepad] spec status

I'd like to note that the current semantic (in google chrome) of press button to connect device is not very user friendly. Not all buttons register as buttons (some register as axes) and won't do anything. Some devices are also devoid of buttons (like the oculus rift) to press. On Thu, May 2,

Re: ZIP archive API?

I am very interested in working with archives. I'm currently using it as a delivery from server (like quake packs), import and export format for WebGL apps. On Tue, Apr 30, 2013 at 3:18 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Apr 30, 2013 at 1:07 PM, Charles McCathie Nevile

Re: The need to re-subscribe to requestAnimationFrame

transfering a canvas to a popup window or iframe. With a requestInterval kind of function you're pretty much screwed in that case. On Fri, Mar 8, 2013 at 7:43 PM, Jonas Sicking jo...@sicking.cc wrote: On Mar 2, 2013 6:32 AM, Florian Bösch pya...@gmail.com wrote: You can also wrap your own

Re: The need to re-subscribe to requestAnimationFrame

You can also wrap your own requestAnimationFrameInterval like so: var requestAnimationFrameInterval = function(callback){ var runner = function(){ callback(); requestAnimationFrame(runner); }; runner(); } This will still stop if there's an exception thrown by callback, but it lets

Re: Re: Keyboard events for accessible RIAs and Games

to the list after that happens. On Sat, Feb 16, 2013 at 7:40 AM, Florian Bösch pya...@gmail.com wrote: Any progress on the speccing of queryKeyCap? On Fri, Feb 1, 2013 at 9:14 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: On Fri, Feb 1, 2013 at 11:42 AM, Travis Leithead

Re: Re: Keyboard events for accessible RIAs and Games

Any progress on the speccing of queryKeyCap? On Fri, Feb 1, 2013 at 9:14 PM, Gary Kacmarcik (Кошмарчик) gary...@chromium.org wrote: On Fri, Feb 1, 2013 at 11:42 AM, Travis Leithead travis.leith...@microsoft.com wrote: I think we should give it another try by including it in our UI Events

Re: Allow ... centralized dialog up front

On Wed, Feb 6, 2013 at 2:09 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: ** This may be true. But pointer-lock is an example of something that needs the entire UX to be thought through. simply switching from one to the other without the user knowing is also poor UX, since it

Re: Allow ... centralized dialog up front

which requests pointerlock on mousedown and releases it on mouseup) where your click it when you need it idea will always fail the first usage. Not exactly confidence inspiring either, as a UX. On Mon, Feb 4, 2013 at 1:28 AM, Tobie Langel to...@fb.com wrote: On 2/2/13 12:16 PM, Florian Bösch pya

Re: Allow ... centralized dialog up front

on both user and developer. On Sat, Feb 2, 2013 at 3:37 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: ** On Fri, 01 Feb 2013 15:29:16 +0100, Florian Bösch pya...@gmail.com wrote: Repetitive permission dialog popups at random UI-flows will not solve the permission fatique any more

Re: Allow ... centralized dialog up front

that search engines etc can include permission requirements in searches. (I want a diary app that does not use my camera...) Cheers, Keean. Cheers, Keean. On 2 Feb 2013 09:09, Florian Bösch pya...@gmail.com wrote: I do not particularly care what research you will find to support the UI-flow

Re: Allow ... centralized dialog up front

On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke ke...@fry-it.com wrote: I think a static declaration is better for security, so if a permission is not there I don't think it should be allowed to request it later. Of course how this is presented to the user is entirely separate, an the UI could

  1   2   3   >