On Thu, 19 May 2011 19:52:20 +0200, Aryeh Gregor
simetrical+...@gmail.com wrote:
On Thu, May 19, 2011 at 7:30 AM, Philip Jägenstedt phil...@opera.com
wrote:
Are there security issues with this setup?
* fullscreen can only be requested by direct user interaction
* fullscreen is entered with
On Fri, May 20, 2011 at 5:19 AM, Philip Jägenstedt phil...@opera.com wrote:
About video in particular, why would we not want video to be keyboard
accessible in full-screen? I very often pause/unpause and seek using the
keyboard when using standalone video players, and I'd like to do the same in
On Wed, May 11, 2011 at 11:27 AM, Jer Noble jer.no...@apple.com wrote:
WebKit is in the process of implementing Mozilla's proposed Full Screen API
https://wiki.mozilla.org/Gecko:FullScreenAPI. Basic full screen support
is available in WebKit Nightlies http://nightly.webkit.org/ on Mac and
On Thu, 19 May 2011 12:22:44 +0200, Robert O'Callahan
rob...@ocallahan.org wrote:
On Thu, May 19, 2011 at 9:34 PM, Philip Jägenstedt
phil...@opera.comwrote:
Regarding user prompts, I am tentatively in favor of the approach that
Jer
appears to be arguing for, which is to never prompt the
On May 13, 2011, at 19:17, Eric Carlson wrote:
I don't know of exploits in the wild, but I've read about
proof-of-concept exploits that overwhelmed the user's attention visually
so that the user didn't notice the Press ESC to exit full screen
message. This allowed subsequent UI spoofing. (I
On Thu, 2011-05-12 at 20:29 -0400, Aryeh Gregor wrote:
In
particular, Flash has allowed this for years, with 95%+ penetration
rates, so we should already have a good idea of how this feature can
be exploited in practice.
I don't know of exploits in the wild, but I've read about
On May 13, 2011, at 12:46 AM, Henri Sivonen wrote:
On Thu, 2011-05-12 at 20:29 -0400, Aryeh Gregor wrote:
In
particular, Flash has allowed this for years, with 95%+ penetration
rates, so we should already have a good idea of how this feature can
be exploited in practice.
I don't know of
On 5/13/11 4:52 AM, Maciej Stachowiak wrote:
I'm not sure extensions like NoScript alone are sufficient reason to impose the
additional complexity required by a user prompting model.
My point was that someone authoring a browser intended to be more secure
against phishing attempts may want
On May 13, 2011, at 12:46 AM, Henri Sivonen wrote:
On Thu, 2011-05-12 at 20:29 -0400, Aryeh Gregor wrote:
In
particular, Flash has allowed this for years, with 95%+ penetration
rates, so we should already have a good idea of how this feature can
be exploited in practice.
I don't know of
On 5/12/11 2:25 AM, Robert O'Callahan wrote:
On Thu, May 12, 2011 at 4:45 PM, Jer Noblejer.no...@apple.com wrote:
And your geolocation example actually argues the other way: the existing
geolocation API includes an asynchronous error handler that is explicitly
called when a request is denied.
On May 11, 2011, at 11:25 PM, Robert O'Callahan wrote:
On Thu, May 12, 2011 at 4:45 PM, Jer Noble jer.no...@apple.com wrote:
2. Animating into and out of full screen.
WebKit's current video full-screen support will animate an element between
its full-screen and non-full-screen
On 5/12/11 3:24 AM, Jer Noble wrote:
A) If an author calls requestFullScreen(), at some point in the future they will receive either a
fullscreenchanged event or a fullscreendenied event.
B) If an author calls requestFullScreen(), at some point in the future they may receive a
On May 12, 2011, at 12:31 AM, Boris Zbarsky wrote:
On 5/12/11 3:24 AM, Jer Noble wrote:
A) If an author calls requestFullScreen(), at some point in the future they
will receive either a fullscreenchanged event or a fullscreendenied
event.
B) If an author calls requestFullScreen(), at some
On May 12, 2011, at 12:54 AM, Jer Noble wrote:
Surely there's a way to achieve the security benefits you're hoping for
without requiring intentionally obtuse API?
Okay, here's another proposal that should work with Firefox's passive
permission system:
Proposal:
- Add a new boolean
On Thu, May 12, 2011 at 11:12 AM, Jer Noble jer.no...@apple.com wrote:
Okay, here's another proposal that should work with Firefox's passive
permission system:
Proposal:
- Add a new boolean Element property canRequestFullScreen. This would map
to Firefox's Never permission choice.
- Add
Why can't the browser just do the fullscreen in a window behaviour
until/if the user approves?
No need for new events even, although a fullscreen lost, sourced eg. from
some browser UI or loss of focus, might be useful.
I don't see why it would make a difference from the page's perspective
On Thu, May 12, 2011 at 1:46 PM, James May wha...@fowlsmurf.net wrote:
Why can't the browser just do the fullscreen in a window behaviour
until/if the user approves?
I don't see anything wrong with this offhand :)
No need for new events even, although a fullscreen lost, sourced eg. from
some
On 5/12/11 3:54 AM, Jer Noble wrote:
No, that still doesn't make sense. At the time when the user decides to allow
or deny full screen access
The point is this may be never. They might just wake forever to make a
decision.
Saying that fullscreendenied will confuse users is akin to
On 5/12/11 4:12 AM, Jer Noble wrote:
- Add a new boolean Element property canRequestFullScreen. This would map to Firefox's
Never permission choice.
- Add the fullscreendenied event. This would map to Firefox's Not now
permission choice.
So if the user just dismisses the notification
On May 12, 2011, at 1:42 AM, timeless wrote:
Your proposal makes it fairly easy for sites to stick up annoying full
content blocking you must change your settings to proceed elements.
That ability exists in the current API as well. A malicious website would just
require the
On May 12, 2011, at 5:44 AM, Boris Zbarsky wrote:
On 5/12/11 3:54 AM, Jer Noble wrote:
No, that still doesn't make sense. At the time when the user decides to
allow or deny full screen access
The point is this may be never. They might just wake forever to make a
decision.
Saying
On May 12, 2011, at 5:47 AM, Boris Zbarsky wrote:
On 5/12/11 4:12 AM, Jer Noble wrote:
- Add a new boolean Element property canRequestFullScreen. This would map
to Firefox's Never permission choice.
- Add the fullscreendenied event. This would map to Firefox's Not now
permission choice.
On Thu, May 12, 2011 at 2:25 AM, Robert O'Callahan rob...@ocallahan.org wrote:
It seems rational to me: click on fullscreen, the video fills the entire
window (but not the screen), and some browser UI appears to suggest going
the rest of the way.
This sounds really bad to me. The user
On 5/12/11 12:48 PM, Jer Noble wrote:
I'm saying that if authors expect to get one or the other but then never do,
that will confuse authors.
Again, I fail to see how this is a problem for the denial event but not for the
change event.
The problem is not for any particular event. The
On 5/12/11 1:16 PM, Jer Noble wrote:
On May 12, 2011, at 5:47 AM, Boris Zbarsky wrote:
On 5/12/11 4:12 AM, Jer Noble wrote:
- Add a new boolean Element property canRequestFullScreen. This would map to Firefox's
Never permission choice.
- Add the fullscreendenied event. This would map to
On 5/12/11 1:43 PM, Aryeh Gregor wrote:
On Thu, May 12, 2011 at 2:25 AM, Robert O'Callahanrob...@ocallahan.org wrote:
It seems rational to me: click on fullscreen, the video fills the entire
window (but not the screen), and some browser UI appears to suggest going
the rest of the way.
This
First things first:
On May 12, 2011, at 11:24 AM, Boris Zbarsky wrote:
I believe you have _completely_ misunderstood what I said. I'm describing a
problem in the geolocation API as it stands. You're talking about
something else. Unfortunately, I'm not quite sure how you got there
On Fri, May 13, 2011 at 10:15 AM, Jer Noble jer.no...@apple.com wrote:
On May 12, 2011, at 11:24 AM, Boris Zbarsky wrote:
On 5/12/11 12:48 PM, Jer Noble wrote:
I'm saying that if authors expect to get one or the other but then
never do, that will confuse authors.
Again, I fail to see
On Fri, May 13, 2011 at 4:48 AM, Jer Noble jer.no...@apple.com wrote:
I don't consider the following to be a usable UI:
- User clicks a full screen button
- Content resizes to occupy full window
- Browser pops up a permissions dialog
- User has to click the Allow button*
- Window then
[Re-CCing list, hope that's OK.]
On Fri, May 13, 2011 at 11:03 AM, Jer Noble jer.no...@apple.com wrote:
On May 12, 2011, at 3:49 PM, Robert O'Callahan wrote:
On Fri, May 13, 2011 at 10:15 AM, Jer Noble jer.no...@apple.com wrote:
I understand what you're saying. By making the error case
On May 12, 2011, at 4:23 PM, Robert O'Callahan wrote:
That only works if the browser can detect a deferral. If the user simply
ignores the browser's UI, you wouldn't know when to fire the event. And
there's also the issue of a fullscreendenied being followed by a
fullscreenchange, which
On Thu, May 12, 2011 at 2:34 PM, Boris Zbarsky bzbar...@mit.edu wrote:
To be clear, we are NOT designing the UI for this thing here. I'm not a UI
designer. Robert is not a UI designer. As far as I know, you are not a UI
designer.
Definitely correct on that last point.
We are trying to
On 5/12/11 6:15 PM, Jer Noble wrote:
I understand what you're saying. By making the error case deliberately
ambiguous, you're trying to force the author to behave in a certain way.
Not quite. I think Robert handled this in his response to this mail, so
I'll just stick to following that
On 5/12/11 8:29 PM, Aryeh Gregor wrote:
If we can figure out in advance what UIs browsers will want to use in
practice, though, that should inform what API we settle on.
Generality is not always good.
Yes.
If it turns out no one wants to ask the user before fullscreening
I'm 99% sure that
On Fri, May 13, 2011 at 12:29 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Thu, May 12, 2011 at 7:02 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
For this case, I think probably a better UI would be what Flash has, to
actually go full-screen immediately but temporarily show a
WebKit is in the process of implementing Mozilla's proposed Full Screen API
https://wiki.mozilla.org/Gecko:FullScreenAPI. Basic full screen support is
available in WebKit Nightlies http://nightly.webkit.org/ on Mac and Windows
(other ports are adding support as well), and can be enabled
On Wed, May 11, 2011 at 11:27 AM, Jer Noble jer.no...@apple.com wrote:
3. fullscreenchange events and their targets.
The current proposal states that a fullscreenchange event must be
dispatched when a document enters or leaves full-screen. Additionally, when
the event is dispatched, if the
On May 11, 2011, at 3:03 PM, Jonas Sicking wrote:
On Wed, May 11, 2011 at 11:27 AM, Jer Noble jer.no...@apple.com wrote:
3. fullscreenchange events and their targets.
The current proposal states that a fullscreenchange event must be
dispatched when a document enters or leaves full-screen.
On Wed, May 11, 2011 at 3:27 PM, Jer Noble jer.no...@apple.com wrote:
On May 11, 2011, at 3:03 PM, Jonas Sicking wrote:
On Wed, May 11, 2011 at 11:27 AM, Jer Noble jer.no...@apple.com wrote:
3. fullscreenchange events and their targets.
The current proposal states that a fullscreenchange
On Thu, May 12, 2011 at 6:27 AM, Jer Noble jer.no...@apple.com wrote:
1. Z-index as the primary means of elevating full screen elements to the
foreground.
The spec suggests that a full screen element is given a z-index of BIGNUM
in order to cause the full screen element to be visible on top
On May 11, 2011, at 7:41 PM, Robert O'Callahan wrote:
On Thu, May 12, 2011 at 6:27 AM, Jer Noble jer.no...@apple.com wrote:
1. Z-index as the primary means of elevating full screen elements to the
foreground.
The spec suggests that a full screen element is given a z-index of BIGNUM in
41 matches
Mail list logo
