Hi Tim ,
Thanks for your reply
It means it is the memory used by javascript core , It does not have memory
component used by Webkit (DOM , Rendering and parsing ) process ?
On 18 September 2011 01:36, Ilya Tikhonovsky loi...@chromium.org wrote:
Each time when Timeline records an event it
On Wed, 21 Sep 2011 11:40:16 +0200, Amit Shahi shahiwo...@gmail.com
wrote:
Hi Tim ,
Thanks for your reply
It means it is the memory used by javascript core , It does not have
memory
component used by Webkit (DOM , Rendering and parsing ) process ?
Hi,
it does not have so you need
This API seems clearly necessary to implement traditional FPS game controls.
On the other hand, I would not want my browser to have this kind of
functionality. Arguably the main benefit of browsers is that they cannot do
many things, and are thus relatively safe to use, not yet triggering the
On Wed, Sep 21, 2011 at 10:44 AM, Alexey Proskuryakov a...@webkit.org wrote:
This API seems clearly necessary to implement traditional FPS game controls.
On the other hand, I would not want my browser to have this kind of
functionality. Arguably the main benefit of browsers is that they cannot
21.09.2011, в 10:56, Eric Uhrhane написал(а):
one can always move the mouse pointer to top of screen to get back their
menu bar.
Is that a Mac thing?
Yes, this is how fullscreen applications regularly work on OS X.
Mousing around in a fullscreen flash app on
Linux or Windows 7 certainly
Hi WebKit-Dev:
As suggested by Mark Rowe and David Kilzer for bug #68499
https://bugs.webkit.org/show_bug.cgi?id=68499, I am writing to propose
that we remove the script Tools/Scripts/gdb-safari after incorporating its
functionality into the script Tools/Scripts/debug-safari. Currently,
2011/9/21 Alexey Proskuryakov a...@webkit.org:
platforms. Interfering with mouse movement would be one of the most
dangerous and frustrating things Web pages could possibly do.
While I agree, that doesn't seem like a problem with the spec. As I
read the spec, it seems that it leaves enough
21.09.2011, в 11:21, James Robinson написал(а):
one can always move the mouse pointer to top of screen to get back their
menu bar.
Is that a Mac thing?
Yes, this is how fullscreen applications regularly work on OS X.
This is not true for several Flash-based fullscreen video players
On Wed, Sep 21, 2011 at 12:05 PM, Alexey Proskuryakov a...@webkit.org wrote:
21.09.2011, в 11:21, James Robinson написал(а):
one can always move the mouse pointer to top of screen to get back their
menu bar.
Is that a Mac thing?
Yes, this is how fullscreen applications regularly work on
On Wed, Sep 21, 2011 at 12:05 PM, Alexey Proskuryakov a...@webkit.org wrote:
Anyway, I'm not sure if we already agreed that mouse lock is only desirable
in full screen. I think that the spec has the goal of enabling it in browser
windows.
Indeed, this is explicitly a use case we want to
On Wed, Sep 21, 2011 at 12:46 PM, Peter Kasting pkast...@chromium.orgwrote:
On Wed, Sep 21, 2011 at 12:05 PM, Alexey Proskuryakov a...@webkit.orgwrote:
Anyway, I'm not sure if we already agreed that mouse lock is only
desirable in full screen. I think that the spec has the goal of enabling it
Re: Alexey Proskuryakov's comment:
I'm curious about the following provision in the spec:
Mouse events normally considered user gestures (e.g. mousedown, click)
for security purposes (such as when allowing pop-up windows) should not be
treated as user gestures when under mouse lock to prevent
On Wed, Sep 21, 2011 at 1:15 PM, Vincent Scheib sch...@chromium.org wrote:
Re: Alexey Proskuryakov's comment:
I'm curious about the following provision in the spec:
Mouse events normally considered user gestures (e.g. mousedown, click)
for security purposes (such as when allowing pop-up
To keep everyone updated, here's the latest from Elliot. The
one-sentence summary is that Chromium Mac will be flipping the switch
to Skia tomorrow. We'll probably want to keep both sets of baselines
for a couple weeks to make sure the Skia transition sticks, but then
we should be able to remove
14 matches
Mail list logo
