Re: [webkit-dev] Total Memory used
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 also grabs these numbers from JSC. It is the size of internal JSC heap used for all the javascript things in the browser. Regards, Tim. On Sat, Sep 17, 2011 at 10:10 AM, Amit Shahi shahiwo...@gmail.com wrote: Dear All, Web Inspector show the Timeline pannel in which Memory is also displayed for webkit. On Each entry there is two field , one is Total Heap Size and other is Used Heap Size . What does these fields mean, is they denote to Memory used by a particular function like in Chrome Heap Profiler or it is diffrent information ? Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Total Memory used
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 other external tools to measure their memory consumption. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
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 sort of fear normally associated with installing software on desktop platforms. Interfering with mouse movement would be one of the most dangerous and frustrating things Web pages could possibly do. The specification draft acknowledges the problem of inability to interact with user agent and the rest of the OS in mouse lock mode. However, the suggested mitigations seem fairly weak. Users are not trained to hit Esc anytime their computer stops properly reacting to their actions - I certainly wouldn't think of doing that. A permanent reminder would be extremely annoying, and we cannot expect that it would be read anyway. Fullscreen is one mode where browsers are expected to take more control over user interaction. Perhaps mouse lock could be appropriate in fullscreen. However, regular fullscreen applications do not use a mouse lock, so users are not trained to escape it - one can always move the mouse pointer to top of screen to get back their menu bar. The only related case I can think of is emulators, which release the mouse on certain modifier keys, such as Cmd or Ctrl+Option. So, I'm not sure how a safe UI would work even in this case. 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 malicious cross origin click redirecting. My understanding is that when browser is in control, the primary security concern is with making the user believe that they are interacting with a different site, and thus stealing confidential data the user types (especially passwords). Displaying a pop-up window sounds like a very minor issue when malicious code is already in main frame, can draw anything, and can control mouse movement. Is there a specific attack scenario where this limitation helps? - WBR, Alexey Proskuryakov 20.09.2011, в 20:53, Vincent Scheib написал(а): I have proposed Mouse Lock to be adopted by the W3 WebEvents Working Group: http://lists.w3.org/Archives/Public/public-webevents/2011JulSep/0064.html http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1424.html On Mon, Sep 12, 2011 at 4:50 PM, Vincent Scheib sch...@chromium.org wrote: A Mouse Lock API has been under discussion on the W3 public-webapps list Mouse Lock(1) and earlier Mouse Capture for Canvas(2). The primary goal is to enable use cases such as first person perspective 3D applications. This is done by providing scripted access to mouse movement data while locking the target of mouse events to a single element and removing the cursor from view. I have been working to formalize the discussions into a draft specification: http://goo.gl/9G8pd, and have a work in progress prototype for WebKit | Chrome. I will publish a WIP patch when it is ready for more eyes. It will be developed behind a compile (and runtime) time flag. I'd like to invite any specification discussion to the Mouse Lock thread (1), and WebKit implementation discussion here. Cheers, -Vince -- 1. http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread.html#msg960 2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437 W3 issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=633602 Chrome issue: http://code.google.com/p/chromium/issues/detail?id=72754 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
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 do many things, and are thus relatively safe to use, not yet triggering the sort of fear normally associated with installing software on desktop platforms. Interfering with mouse movement would be one of the most dangerous and frustrating things Web pages could possibly do. The specification draft acknowledges the problem of inability to interact with user agent and the rest of the OS in mouse lock mode. However, the suggested mitigations seem fairly weak. Users are not trained to hit Esc anytime their computer stops properly reacting to their actions - I certainly wouldn't think of doing that. A permanent reminder would be extremely annoying, and we cannot expect that it would be read anyway. Fullscreen is one mode where browsers are expected to take more control over user interaction. Perhaps mouse lock could be appropriate in fullscreen. However, regular fullscreen applications do not use a mouse lock, so users are not trained to escape it - one can always move the mouse pointer to top of screen to get back their menu bar. Is that a Mac thing? Mousing around in a fullscreen flash app on Linux or Windows 7 certainly doesn't pop up a menu bar when I hit the top. And the way out is always to hit ESC [although there's often a button as well, depending on the application], so I'm not sure what the problem with fullscreen mouse lock would be. The only related case I can think of is emulators, which release the mouse on certain modifier keys, such as Cmd or Ctrl+Option. So, I'm not sure how a safe UI would work even in this case. 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 malicious cross origin click redirecting. My understanding is that when browser is in control, the primary security concern is with making the user believe that they are interacting with a different site, and thus stealing confidential data the user types (especially passwords). Displaying a pop-up window sounds like a very minor issue when malicious code is already in main frame, can draw anything, and can control mouse movement. Is there a specific attack scenario where this limitation helps? - WBR, Alexey Proskuryakov 20.09.2011, в 20:53, Vincent Scheib написал(а): I have proposed Mouse Lock to be adopted by the W3 WebEvents Working Group: http://lists.w3.org/Archives/Public/public-webevents/2011JulSep/0064.html http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1424.html On Mon, Sep 12, 2011 at 4:50 PM, Vincent Scheib sch...@chromium.org wrote: A Mouse Lock API has been under discussion on the W3 public-webapps list Mouse Lock(1) and earlier Mouse Capture for Canvas(2). The primary goal is to enable use cases such as first person perspective 3D applications. This is done by providing scripted access to mouse movement data while locking the target of mouse events to a single element and removing the cursor from view. I have been working to formalize the discussions into a draft specification: http://goo.gl/9G8pd, and have a work in progress prototype for WebKit | Chrome. I will publish a WIP patch when it is ready for more eyes. It will be developed behind a compile (and runtime) time flag. I'd like to invite any specification discussion to the Mouse Lock thread (1), and WebKit implementation discussion here. Cheers, -Vince -- 1. http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread.html#msg960 2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437 W3 issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=633602 Chrome issue: http://code.google.com/p/chromium/issues/detail?id=72754 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
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 doesn't pop up a menu bar when I hit the top. And the way out is always to hit ESC [although there's often a button as well, depending on the application], so I'm not sure what the problem with fullscreen mouse lock would be. I do not have recent knowledge of Linux, but my understanding is that Windows UI is undergoing a major redesign with Metro, so basing APIs largely on how Windows used to work up to version 7 may not be future proof. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit Bug #68499 - Proposal to remove the script gdb-safari and instead use debug-safari
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, debug-safari executes the script gdb-safari on Mac OS X and creates a Visual Studio debug project on Windows. If anyone feels that it's beneficial to keep the gdb logic separated from debug-safari in the script gdb-safari then please comment on bug #68499 https://bugs.webkit.org/show_bug.cgi?id=68499. I am also open to suggestions on the patch and how we can better consolidate this duplicate code. Dan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
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 latitude to allow each browser to do what it feels is best for its users as far as security and annoyance is concerned. If your browser simply prompted or required whitelisting before allowing a page to mouse lock along with directions on how to cancel, it doesn't seem like it would be problematic to me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
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 that I've used on my mac. The interaction there is that upon entering fullscreen Flash displays an overlay indicating that hitting ESC will exit fullscreen mode and the video player displays its controls near the bottom of the screen. After these fade away, the video controls appear only when moving the mouse pointer to the bottom ~1/3rd of the screen. Moving the mouse pointer to the top of the screen does nothing. Hitting ESC or clicking on the appropriate button in the video player's controls exits fullscreen mode. This seems entirely reasonable to me, the keyboard control is provided by Flash itself to prevent bad SWFs from taking control of my computer and the SWF itself provides the additional controls that make sense for its domain. You are describing how Flash exits full screen, and the fact that it apparently always has mouse lock in full screen (so you cannot get to browser menu bar by moving mouse pointer up). It's a different behavior from what this API provides. Besides being a security measure for a subtly different feature, Flash behavior is quite annoying, and not very efficient - see e.g. http://www.bunnyhero.org/2008/05/10/scaring-people-with-fullscreen/. To demonstrate the difference with Flash, there is no mouse lock in Safari fullscreen, so you can move the mouse pointer up to get the menu bar. 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. 21.09.2011, в 11:22, Darin Fisher написал(а): basing APIs largely on how Windows used to work up to version 7 may not be future proof. Yes, but 90% of internet users are not familiar with Metro. They are familiar with Windows as it exists today (XP thru 7). More than 90% is an understatement :) Is your implication that Microsoft will be forced to make future Windows UI behave the same as Windows 7 does? Otherwise, it's not clear to me how a reference to old behavior is relevant to being future proof. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
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 OS X. This is not true for several Flash-based fullscreen video players that I've used on my mac. The interaction there is that upon entering fullscreen Flash displays an overlay indicating that hitting ESC will exit fullscreen mode and the video player displays its controls near the bottom of the screen. After these fade away, the video controls appear only when moving the mouse pointer to the bottom ~1/3rd of the screen. Moving the mouse pointer to the top of the screen does nothing. Hitting ESC or clicking on the appropriate button in the video player's controls exits fullscreen mode. This seems entirely reasonable to me, the keyboard control is provided by Flash itself to prevent bad SWFs from taking control of my computer and the SWF itself provides the additional controls that make sense for its domain. You are describing how Flash exits full screen, and the fact that it apparently always has mouse lock in full screen (so you cannot get to browser menu bar by moving mouse pointer up). It's a different behavior from what this API provides. Besides being a security measure for a subtly different feature, Flash behavior is quite annoying, and not very efficient - see e.g. http://www.bunnyhero.org/2008/05/10/scaring-people-with-fullscreen/. To demonstrate the difference with Flash, there is no mouse lock in Safari fullscreen, so you can move the mouse pointer up to get the menu bar. 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. 21.09.2011, в 11:22, Darin Fisher написал(а): basing APIs largely on how Windows used to work up to version 7 may not be future proof. Yes, but 90% of internet users are not familiar with Metro. They are familiar with Windows as it exists today (XP thru 7). More than 90% is an understatement :) Is your implication that Microsoft will be forced to make future Windows UI behave the same as Windows 7 does? Otherwise, it's not clear to me how a reference to old behavior is relevant to being future proof. My point was that emulating the behavior that most users are familiar with will likely create a predictable user experience. Most users are familiar with hitting ESC to exit fullscreen, so it seems sensible to piggyback on that. By the way, wouldn't it be better to debate this API in the WebEvents WG? -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
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 allow. It's reasonable to want to play many mouse-lock-requiring games (Quake, Starcraft, etc.) in non-fullscreen mode, e.g. so one can still keep some other critical display open elsewhere on the screen. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
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 in browser windows. Indeed, this is explicitly a use case we want to allow. It's reasonable to want to play many mouse-lock-requiring games (Quake, Starcraft, etc.) in non-fullscreen mode, e.g. so one can still keep some other critical display open elsewhere on the screen. PK True, although there are still questions about how the user experience will work for non-fullscreen. I think we only feel confident that we have a decent fullscreen solution at this point, and the plan was to restrict the initial implementation to fullscreen mode for that reason. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
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 malicious cross origin click redirecting. My understanding is that when browser is in control, the primary security concern is with making the user believe that they are interacting with a different site, and thus stealing confidential data the user types (especially passwords). Displaying a pop-up window sounds like a very minor issue when malicious code is already in main frame, can draw anything, and can control mouse movement. Is there a specific attack scenario where this limitation helps? The concern I was attempting to address is primarily that of click jacking. E.g. Preventing a malicious top level page from directing unintended clicks to an iframe with a target site (e.g. a bank). Upon reflection, perhaps the correct way to limit this is to require the target element to match the top level origin as well. Then user gestures can only be delivered to the top level origin. Re: Mouse lock can be a nuisance. Yes, it can, but it also is essential for many compelling applications and user interactions. We believe user-agents can find a balance of providing that ability and diminishing it's abuse. The example of Flash's abusable full screen mode is relevant in that I believe the amount of users enjoying the feature vastly outweigh the amount of nuisance caused. We'll seek to find the appropriate ease of use and reduction of nuisance, but in the extreme can fall back onto heavy weight measures such as installing a web-app or prompting for permission first. The API is designed to tolerate these methods (asynchronous success/failure). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mouse Lock API
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 windows) should not be treated as user gestures when under mouse lock to prevent malicious cross origin click redirecting. My understanding is that when browser is in control, the primary security concern is with making the user believe that they are interacting with a different site, and thus stealing confidential data the user types (especially passwords). Displaying a pop-up window sounds like a very minor issue when malicious code is already in main frame, can draw anything, and can control mouse movement. Is there a specific attack scenario where this limitation helps? The concern I was attempting to address is primarily that of click jacking. E.g. Preventing a malicious top level page from directing unintended clicks to an iframe with a target site (e.g. a bank). Upon reflection, perhaps the correct way to limit this is to require the target element to match the top level origin as well. Then user gestures can only be delivered to the top level origin. I wouldn't worry too much about that. A site can already mount a clickjacking attack without using mouselock. It's not clear to me that mouselock make the situation any worse than it is already. Adam Re: Mouse lock can be a nuisance. Yes, it can, but it also is essential for many compelling applications and user interactions. We believe user-agents can find a balance of providing that ability and diminishing it's abuse. The example of Flash's abusable full screen mode is relevant in that I believe the amount of users enjoying the feature vastly outweigh the amount of nuisance caused. We'll seek to find the appropriate ease of use and reduction of nuisance, but in the extreme can fall back onto heavy weight measures such as installing a web-app or prompting for permission first. The API is designed to tolerate these methods (asynchronous success/failure). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Chromium Mac moving to Skia
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 the CoreGraphics image baselines for Chromium Mac. (I've added some notes inline.) Adam -- Forwarded message -- From: Elliot Poger epo...@chromium.org Date: Wed, Sep 21, 2011 at 3:07 PM Subject: [chromium-dev] Chromium-on-Mac changing from Core Graphics to Skia tomorrow To: Chromium-dev chromium-...@chromium.org Sometime in the next 24-48 hours, I plan to commit a Chromium change that will change the default value of use_skia on Mac from 0 to 1. This will cause the default graphics layer on Chromium-for-Mac from Apple's Core Graphics to our Skia library. We already use Skia by default for Windows and Linux; this change will bring Mac in line with those other platforms. If you run into any problems with this, please let me know... and you can set use_skia=0 to get the old functionality back (at least until we are satisfied that Skia is stable and happy). Additional notes for those who are interested: (links will work for Googlers only, sorry about that) This change will cause the accelerated canvas path to be enabled by default on the Mac. We have been running the chromium.webkit buildbots against both Skia and CG for a couple of weeks now. As of Wednesday afternoon, the Skia bots have been as green as the CG ones. (We have marked a lot of tests as known-to-fail to greenify these tests; the vast majority of the failures just indicate baselines that need to be regenerated, but there may be a few real errors lurking in there... we already corrected some, but there may be more.) http://goto.google.com/skia-webkit-canaries [abarth] http://tinyurl.com/3wdaoqf http://goto.google.com/cg-webkit-canaries [abarth] http://tinyurl.com/3mf9le7 I have a subset of the Chromium buildbots running locally, which I have been using to compare results with Skia vs CG. They haven't been running as long as the chromium.webkit buildbots above, but so far so good... http://goto.google.com/skia-chromium-bots http://goto.google.com/cg-chromium-bots [abarth] These don't appear to be visible on the public web. There are further details about the transition process at http://goto.google.com/SkiaWebkitStatus [abarth] This document doesn't appear to be public, probably because it contains release dates. On Tue, Aug 16, 2011 at 11:31 AM, Adam Barth aba...@webkit.org wrote: Hi WebKit, In an effort to make the Chromium port more consistent across platforms, we're moving the Chromium Mac port from CoreGraphics to Skia. This should mostly have little effect on the rest of the WebKit community, but you'll be seeing some patches shortly that shuffle a bunch of test expectations around so that we can make the transition carefully and avoid regressions. Specifically, we're planing to do the following: 1) Move the chromium-mac and chromium-mac-leopard results directories to chromium-mac-cg and chromium-mac-cg-leopard, respectively. This will let use keep both CG and Skia results during the transition so that we can compare them and avoid regressions. 2) Introduce MACCG modifies for test_expectations. This will let use have separate expectations for CG and Skia. 3) Introduce new chromium-mac and chromium-mac-leopard results directories, which will correspond to the new Skia configuration. 4) Move the Chromium Mac builders on build.webkit.org over to using the Skia configuration. Two of these steps will generate somewhat large svn update steps. I'd like to thank you in advance for being patient with us as we make this transition. If you have any questions or concerns, please feel to respond to this thread or to ask Cary or myself. Thanks again, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
