Ian Hickson | 1 Feb 07:55 2010
Picon

Re: Web-sockets + Web-workers to produce a P2P website or application

On Tue, 19 Jan 2010, Andrew de Andrade wrote:
> 
> [...] One of the big problems with these games is the shear amount of 
> static content that must be delivered via HTTP once the application 
> becomes popular. In fact, if a game becomes popular overnight, the 
> scaling problems with this static content quickly becomes a technical 
> and financial problem.
> 
> [...] My idea is to use web-sockets to allow the browser function more a 
> less like a bit-torrent client. Along with this, web-workers would 
> provide threads for handling the code that would function as a server, 
> serving the static content to peers also using the program.
> 
> Let me know your thoughts and if you think this would be possible using 
> Web-sockets and web-workers, and if not, what changes would be necessary 
> to allow this to evolve.

This seems like a reasonable idea, but I think the way to do it is to 
invent a new URI scheme that corresponds to a distributed network 
operation, so you could just do:

   <img src="p2p://example.com/images/header.png" alt="...">

...or something.

I would recommend following up on this as an independent project.

On Fri, 22 Jan 2010, Andrew de Andrade wrote:
> 
> I'm wondering if anyone from either webkit, mozilla, opera, the W3C or 
(Continue reading)

Ian Hickson | 1 Feb 09:42 2010
Picon

Re: HttpOnly cookie for WebSocket?

On Thu, 28 Jan 2010, Fumitoshi Ukai (~\飼~V~G~U~O) wrote:
>
> May/Should WebSocket use HttpOnly cookie while Handshaking? I think it 
> would be useful to use HttpOnly cookie on WebSocket so that we could 
> authenticate the WebSocket connection by the auth token cookie which 
> might be HttpOnly for security reason.
> 
> http://www.ietf.org/id/draft-ietf-httpstate-cookie-02.txt

I've updated the spec to explicitly include HttpOnly cookies.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Henri Sivonen | 1 Feb 10:14 2010
Picon
Picon

Re: api for fullscreen() - security issues

On Jan 31, 2010, at 05:08, Simon Fraser wrote:

> * disallow enterFullscreen() from a frame or iframe

This might be a problem if video sites transition their embedding boilerplate to an iframe in order to be
able to be able to serve HTML5, Flash, ActiveX, etc. depending on UA without requiring the embedders to
copy and paste anything fancy.

> * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit
fullscreen, and prevent the page from capturing this keypress.

IIRC, it has been shown that at least as implemented in Flash Player, it is possible to draw enough
distractions to make the users unable to read this message. Also, when the site is legitimate, it's quite
annoying to have the overlay there.

Personally, I'd rather have to click through a once per-Origin authorization bar (like geolocation in
Firefox) than watch the "press esc" overlay every time.

> * make the location field available to the user so that they can see the URL even when in fullscreen

This defeats the point of full screen. If I want a 16:9 video to go full screen on a 16:9 display, I want all
screen pixels to be used for the video.

> * drop out of fullscreen if navigating to another page

This would constrain slide shows do be unnecessarily Ajaxy and less linkable with per-slide
JavaScriptless URLs.

--

-- 
Henri Sivonen
(Continue reading)

Simon Fraser | 1 Feb 17:00 2010

Re: api for fullscreen() - security issues

On Feb 1, 2010, at 1:14 AM, Henri Sivonen wrote:

> On Jan 31, 2010, at 05:08, Simon Fraser wrote:
> 
>> * disallow enterFullscreen() from a frame or iframe
> 
> This might be a problem if video sites transition their embedding boilerplate to an iframe in order to be
able to be able to serve HTML5, Flash, ActiveX, etc. depending on UA without requiring the embedders to
copy and paste anything fancy.

Perhaps we'd enforce a same-origin rule where the iframe contents have to be from the same domain as the main
page, then?
> 
>> * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit
fullscreen, and prevent the page from capturing this keypress.
> 
> IIRC, it has been shown that at least as implemented in Flash Player, it is possible to draw enough
distractions to make the users unable to read this message.

That's why I said "hard to spoof". The Flash overlay makes the mistake of not being contrasty enough. An
improvement would be to dim out the rest of the content while showing this overlay.

> Also, when the site is legitimate, it's quite annoying to have the overlay there.
> 
> Personally, I'd rather have to click through a once per-Origin authorization bar (like geolocation in
Firefox) than watch the "press esc" overlay every time.

That's a possibility, yes.

> 
(Continue reading)

Chris McCormick | 1 Feb 18:05 2010

Re: Codecs for <audio> and <video>

On Sun, Aug 09, 2009 at 08:29:28PM +1000, Silvia Pfeiffer wrote:
> On Sun, Aug 9, 2009 at 7:20 PM, Chris McCormick<chris@...> wrote:
> > Hi Sylvia,
> >
> > On Sun, Aug 09, 2009 at 11:16:01AM +1000, Silvia Pfeiffer wrote:
> >> On Sun, Aug 9, 2009 at 3:15 AM, Chris McCormick<chris@...> wrote:
> >> > On Wed, Jul 08, 2009 at 09:24:42AM -0700, Charles Pritchard wrote:
> >> >> There are two use cases that I think are important: a codec
> >> >> implementation (let's use Vorbis),
> >> >> and an accessibility implementation, working with a <canvas> element.
> >> >
> >> > Here are a few more use-cases that many people would consider just as
> >> > important:
> >> >
> >> > * Browser based music software and synthesis toys.
> >> > * New types of 'algorithmic' music like that pioneered by Brian Eno.
> >> > * Browser based games which want to use procedural audio instead of
> >> > pre-rendered sound effects.
> >>
> >> Why don't you just implement an example in javascript to show off what
> >> you're talking about and make a use case for having it implemented
> >> inside the browsers?
> >
> > Yes, you are right I should definately do that. What is the normal process for
> > that: write some code, post it up on my website, and then post here with a
> > link? Is that sufficient to get the attention of the browser implementors?
> 
> I would think so. Not automatically, of course, but it would go a long way.
> 
> 
(Continue reading)

Henry Bridge | 1 Feb 18:42 2010
Picon

Re: api for fullscreen()


The enableKeys parameter to enterFullscreen is a hint to the UA that the application would like to be able to receive arbitrary keyboard input. Otherwise the UA is likely to disable alphanumeric keyboard input. If enableKeys is specified, the UA might require more severe confirmation UI.

This seems overly complicated. I think it would suffice to simply show a dialog the first time a user wants to go fullscreen within a domain with an option to "remember this choice for this domain." Then the user won't have to jump through the hoops again when they return, but will still protect them from random websites going fullscreen and trying to phish things. This way blocking or restricting keyboard events isn't needed.

Those kinds of dialogs are dangerous because users tend to just dismiss them without reading. Passive (ignorable and asynchronous) confirmation works better.

The enableKeys option would let authors who don't need alphanumeric input (video playback) go fullscreen with a low confirmation bar (perhaps none at all, if the fullscreen request is in a click event handler).

I know it's not the biggest concern right now, but I thought it's worth pointing out: on mobile touchscreen devices this hint does nothing as the site can spoof the keyboard as well.  I don't see any harm in this hint, but I'd say the focus should be on ensuring it's clear to the user what's going on in either case.
Kenneth Russell | 1 Feb 19:39 2010
Picon

Re: api for fullscreen()

On Thu, Jan 28, 2010 at 8:55 PM, Robert O'Callahan <robert@...> wrote:
> On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns <tensafefrogs@...>
> wrote:
>>>
>>> enterFullscreen always returns immediately. If fullscreen mode is
>>> currently supported and permitted, enterFullscreen dispatches a task that a)
>>> imposes the fullscreen style, b) fires the beginfullscreen event on the
>>> element and c) actually initiates fullscreen display of the element. The UA
>>> may asynchronously display confirmation UI and dispatch the task when the
>>> user has confirmed (or never).
>>
>> Don't you think it would make more sense to dispatch the enterFullscreen
>> event only when the element actually goes fullscreen? If the user clicks the
>> fullscreen button, but then doesn't accept whatever options (likely a
>> security dialog or something) then it doesn't make sense to broadcast an
>> enterFullscreen event, as you'd just have to broadcast an exitFullscreen
>> event right away to show that the user isn't actually in fullscreen.
>
> That was my intent in the last sentence of the paragraph you quoted.
>
>>
>>>
>>> The enableKeys parameter to enterFullscreen is a hint to the UA that the
>>> application would like to be able to receive arbitrary keyboard input.
>>> Otherwise the UA is likely to disable alphanumeric keyboard input. If
>>> enableKeys is specified, the UA might require more severe confirmation UI.
>>
>> This seems overly complicated. I think it would suffice to simply show a
>> dialog the first time a user wants to go fullscreen within a domain with an
>> option to "remember this choice for this domain." Then the user won't have
>> to jump through the hoops again when they return, but will still protect
>> them from random websites going fullscreen and trying to phish things. This
>> way blocking or restricting keyboard events isn't needed.
>
> Those kinds of dialogs are dangerous because users tend to just dismiss them
> without reading. Passive (ignorable and asynchronous) confirmation works
> better.
>
> The enableKeys option would let authors who don't need alphanumeric input
> (video playback) go fullscreen with a low confirmation bar (perhaps none at
> all, if the fullscreen request is in a click event handler).
>
>> Also consider what happens if the user focuses something on another
>> display. Do you then drop out of fullscreen, or just blur() the fullscreen
>> window? (I'd vote to leave it and just blur() it, so you can do things like
>> watch fullscreen video on one display and continue working in the other).
>
> That sounds like a good idea, but I don't think it needs to be in the spec.
> It's up to the UA.
>
>> Another thing to add in here I haven't seen discussed yet is what to show
>> as the background to the fullscreen element. Consider the example of a 16:9
>> video going fullscreen on a 4:3 display. How do you tell the browser to fill
>> in the extra space around the video with black (or whatever other color you
>> want). Is this a custom css element?
>
>
> The <video> element already letterboxes. So you'd do something like this:
> <div class="fullscreen" style="background:black; position:relative;
> width:640px; height:480px;">
>   <video style="position:absolute; width:100%; height:100%;"
> src=...></video>
>   ... controls ...
> </div>
>
> Making the <div> fullscreen would override the author geometry and produce
> the effect you want.

When you say that the DOM viewport of the element is aligned with the
screen when it goes fullscreen, does that mean that the .width and
.height properties are changed? Or does it mean that the element's
size is changed by a CSS style?

The case I'm thinking about is when a Canvas element is taken
fullscreen; on that element changing the .width and .height properties
changes the size of the backing store, but applying a CSS style to
change its width and height causes the backing store to be scaled to
fit. The desired behavior is for the backing store to be resized.

-Ken

> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>

Robert O'Callahan | 1 Feb 20:05 2010

Re: api for fullscreen()

On Tue, Feb 2, 2010 at 7:39 AM, Kenneth Russell <kbr-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:

When you say that the DOM viewport of the element is aligned with the
screen when it goes fullscreen, does that mean that the .width and
.height properties are changed? Or does it mean that the element's
size is changed by a CSS style?

The latter. The window's viewport is aligned with the screen bounds, and by default the element is styled with position:fixed; left:0; right:0; top:0; bottom:0, which resizes it in CSS to fill the viewport.

The case I'm thinking about is when a Canvas element is taken
fullscreen; on that element changing the .width and .height properties
changes the size of the backing store, but applying a CSS style to
change its width and height causes the backing store to be scaled to
fit. The desired behavior is for the backing store to be resized.
 
The author would have to handle the beginfullscreen event and manually set the canvas width/height attributes, e.g. to getBoundingClientRect().width/height. I don't think we should change width/height attributes automatically, since that has the side effect of clearing the canvas.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Kenneth Russell | 1 Feb 20:45 2010
Picon

Re: api for fullscreen()

On Mon, Feb 1, 2010 at 11:05 AM, Robert O'Callahan <robert@...> wrote:
> On Tue, Feb 2, 2010 at 7:39 AM, Kenneth Russell <kbr@...> wrote:
>>
>> When you say that the DOM viewport of the element is aligned with the
>> screen when it goes fullscreen, does that mean that the .width and
>> .height properties are changed? Or does it mean that the element's
>> size is changed by a CSS style?
>
> The latter. The window's viewport is aligned with the screen bounds, and by
> default the element is styled with position:fixed; left:0; right:0; top:0;
> bottom:0, which resizes it in CSS to fill the viewport.
>
>> The case I'm thinking about is when a Canvas element is taken
>> fullscreen; on that element changing the .width and .height properties
>> changes the size of the backing store, but applying a CSS style to
>> change its width and height causes the backing store to be scaled to
>> fit. The desired behavior is for the backing store to be resized.
>
>
> The author would have to handle the beginfullscreen event and manually set
> the canvas width/height attributes, e.g. to
> getBoundingClientRect().width/height. I don't think we should change
> width/height attributes automatically, since that has the side effect of
> clearing the canvas.

OK, that sounds reasonable. Thanks.

-Ken

> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>

Brian Campbell | 1 Feb 22:41 2010

Re: api for fullscreen()

On Jan 28, 2010, at 9:42 PM, Robert O'Callahan wrote:

> enterFullscreen always returns immediately. If fullscreen mode is currently supported and permitted,
enterFullscreen dispatches a task that a) imposes the fullscreen style, b) fires the beginfullscreen
event on the element and c) actually initiates fullscreen display of the element. The UA may
asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never).

I like this proposal overall. I'm looking forward to being able to display content full screen; this is one
of the last features necessary to start moving the kind of content that I work on to the web.

I'm a bit concerned about when the fullscreen events and styles apply, though. If the page can tell whether
or not the user has actually allowed it to enter fullscreen mode, it can refuse to display content until the
user gives it permission to enter fullscreen mode. Or even if it's not refusing to display content, it may
simply not scale the content up to the full window if the user neglects to give permission for full screen.
This could lead to the problem that Hixie mentions, of training users to click through security dialogs,
even if this is done through a drop-down asynchronous notification instead of a modal dialog.

If a user clicks a fullscreen button, and declines to give permission to the site to actually use the whole
screen, the behavior should probably be to simply resize the element to the full viewport. A standard
interface (close button, or escape key, or the like) could then take the element back out of fullscreen (or
in this case, full viewport) mode; the application would behave the same as if it were in fullscreen mode,
it would just be constrained within the window without knowing it. If the user does give permission, using
an asynchronous notification drop down or similar interface, then the browser would have to send a resize
event or something like that to let the application know that it needs to resize again. The
beginfullscreen/endfullscreen events, and pseudoclass, would apply when resizing to the full window,
if full screen permission hasn't been granted.

This would also help applications deal more gracefully with users who don't give permission to go full
screen; the application would likely have to do the resizing to the full window itself if it doesn't get
permission to use the full screen, but it won't know how long to wait before deciding that the user hasn't
given permission. This way, it would resize immediately and automatically to the viewport before
permission is granted, and resize again to the full screen if permission has been granted.

-- Brian

Gmane