Re: [webkit-dev] VS2010 compilation
Hi, Make sure that your .bashrc file isn't setting(and exporting) TMP or TEMP either. Eric -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of foru...@smartmobili.com Sent: 21 juillet 2012 08:06 To: webkit-dev@lists.webkit.org Subject: [webkit-dev] VS2010 compilation Hi, I am trying to compile webkit on the following platform Windows 7 Pro x64 Intel i5 2500K - 3.3 GHz Microsoft Visual Studio 2010 Ultimate -ENU Version 10.0.30319 Microsoft Visual Studio 2010 Service Pack 1 Version 10.0.40219 Microsoft Visual Studio 2010 SDK SP1 Version 10.0.40219 Cygwin 1.7.15-1 installed in C:\Developer\cygwin using VS2010 Ultimate with SP1 on a windows platform (Windows 7 x64 - Intel i5 2500K - 3.3 GHz) folllowing this blog : http://blog.ashodnakashian.com/2012/01/building-webkit-on-windows-7-with-vs2010/ but unfortunately it nevers succeeds. I would be curious to know if you are using cygwin 1.5 or 1.7 and what version of gcc? For people interested here is my personal investigations about how to progress on this subject : 0) Check you don't have any visual open and zombie process MSBuild.exe 1) Install cygwin 1.7 with the following packages (perl, python, make, curl, unzip).(Personaly I like to install it inside c:\Developer\cygwin) We need an additional perl dependency Http/Datep.pm so let's install it too: $ perl -MCPAN -e shell $ install 'Http::Date' 2) Edit /etc/profile and comment the 3 lines like this ORIGINAL_TMP=$TMP ORIGINAL_TEMP=$TEMP #unset TMP TEMP tmp=$(cygpath -w $ORIGINAL_TMP 2 /dev/null) temp=$(cygpath -w $ORIGINAL_TEMP 2 /dev/null) #TMP=/tmp #TEMP=/tmp 3) Launch cygwin and enter the following commands (I have modified original script from ashodnakashian to allow more configurations ie check if cygwin is installed or not in the default path, ...) $ mkdir tmp cd tmp $ curl -k http://builds.nightly.webkit.org/files/trunk/src/WebKit-r123220.tar.bz2 WebKit-r123220.tar.bz2 $ curl -k http://www.smartmobili.com/downloads/WebKit-vs201x-Patch.zip WebKit-vs201x-Patch.zip $ tar xvf WebKit-r123220.tar.bz2 $ mv WebKit-r123220/Tools/Scripts/pdevenv WebKit-r123220/Tools/Scripts/ORG_pdevenv $ unzip -d WebKit-r123220 WebKit-vs201x-Patch.zip Ok so now we are ready to launch the compilation, go to Start Menu\Microsoft Visual Studio 2010\Visual Studio Tools and right-click on Visual Studio Command Prompt (2010) and click on Run as Administrator cd C:\Developer\cygwin\home\Vincent\WebKit-r123220 vs201x-build-env.cmd If everything goes well you should see something like : Setting up Cygwin directory... Note: Using custom cygwin path Lien symbolique créé pour C:\cygwin === C:\Developer\cygwin Setting up WebKit directory... Exporting environment varibles... Note: Remember to set devenv.exe to run as administrator! Running Cygwin... and now you are in cygwin. $ build-webkit --wincairo 21 | tee build.txt And now I am a bit stuck with this error : Microsoft (R) Visual Studio Version 10.0.40219.1. Copyright (C) Microsoft Corp. All rights reserved. 1-- Build started: Project: WTFGenerated, Configuration: Release_Cairo_CFLite Win32 -- 1 /cygdrive/c/Developer/cygwin/bin/bash 1 touch %ConfigurationBuildDir%\buildfailed 1 bash build-generated-files.sh %ConfigurationBuildDir% C:\Developer\cygwin\home\Vincent\WebKit-r123220\WebKitLibraries\win 1 bash -c python work-around-vs-dependency-tracking-bugs.py 1 copy-files.cmd 1 Copying WTF headers... 1 '#' n'est pas reconnu en tant que commande interne ou externe, un 1 programme ex‚cutable ou un fichier de commandes. 1 Copying other files... 1 del %ConfigurationBuildDir%\buildfailed 2-- Build started: Project: WTF (WTF\WTF), Configuration: Release_Cairo_CFLite Win32 -- 2 /cygdrive/c/Developer/cygwin/bin/bash 2C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(153,5): error MSB6001: Invalid command line switch for CL.exe. Item has already been added. Key in dictionary: 'TMP' Key being added: 'tmp' 3-- Build started: Project: JavaScriptCoreGenerated, Configuration: Release_Cairo_CFLite Win32 -- The first error is weird because when I have a look at Source\WTF\WTF.vcproj\copy-files.cmd I can see the following line starting by # # FIXME: Why is WTF copying over create_hash_table? The second error is about cl and duplicated key and I know it has something to do with cygwin way of declaring tmp and TMP and I thought my modification would fix it but it seems it's not the case Like suggested on the original blog I have also renamed Tools\vcbin\cl.exe and midl.exe to use the ones from Visual Studio, could it explain this problem ? Any help would be appreciated. Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebKit memory instrumentation
*Hi WebKit, Almost all developers would like to know why the render process takes so much memory. We are trying to address this problem by providing an information on how much memory is consumed by some high-level WebKit parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in Web Inspector that shows the render process memory broken down into several components: To achieve that we instrumented several classes in WebCorehttp://code.google.com/searchframe#search/q=reportMemoryUsage%20package:chromiumtype=csto report an estimation of their memory footprint. The main problem with that approach is that it can be easily broken by changes to the instrumented clasess. We need a way to guard from such changes that would automatically validate the instrumentation and make sure it matches current class structure. We see several ways of doing that. First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/attachment.cgi?id=153479action=review for more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. The second option is to write a tool/script/llvm-plugin and use it on a build-bot to monitor the relevance of instrumentation and update it on when a new field is added to an already instrumented class. However, a question remains who and how often would do this. Pros: a committer may not need to update the instrumentation immediately. Cons: the instrumentation may be behind the actual memory usage. An addifitional effort required to create the tooling. We would like to know what you think about it and will greatly appreciate any ideas and suggestions. Regards, Yury, Alexei, Ilya * ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
Is there no way to use the sizeof operator to help? That might not help if we restructure the data, but it would at least help us track the size of individual objects. Adam On Mon, Jul 23, 2012 at 8:09 AM, Yury Semikhatsky yu...@chromium.orgwrote: *Hi WebKit, Almost all developers would like to know why the render process takes so much memory. We are trying to address this problem by providing an information on how much memory is consumed by some high-level WebKit parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in Web Inspector that shows the render process memory broken down into several components: To achieve that we instrumented several classes in WebCorehttp://code.google.com/searchframe#search/q=reportMemoryUsage%20package:chromiumtype=csto report an estimation of their memory footprint. The main problem with that approach is that it can be easily broken by changes to the instrumented clasess. We need a way to guard from such changes that would automatically validate the instrumentation and make sure it matches current class structure. We see several ways of doing that. First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/attachment.cgi?id=153479action=review for more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. The second option is to write a tool/script/llvm-plugin and use it on a build-bot to monitor the relevance of instrumentation and update it on when a new field is added to an already instrumented class. However, a question remains who and how often would do this. Pros: a committer may not need to update the instrumentation immediately. Cons: the instrumentation may be behind the actual memory usage. An addifitional effort required to create the tooling. We would like to know what you think about it and will greatly appreciate any ideas and suggestions. Regards, Yury, Alexei, Ilya * ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
Hi guys, First off, this is a really neat addition for web and WebKit developers alike, so thanks for hacking it! We're already using the reference class with same size as original class pattern to guard against object size regression for some of our very high-volume objects. While that's fine for those issues, I worry that it won't be sufficient in your case since a refactoring could easily replace one member with another, changing the effective memory consumption with no change to sizeof(Object). I know from experience that anything in this area that isn't tested at compile-time *will* break/bloat eventually. -Kling On Mon, Jul 23, 2012 at 4:09 PM, Yury Semikhatsky yu...@chromium.orgwrote: *Hi WebKit, Almost all developers would like to know why the render process takes so much memory. We are trying to address this problem by providing an information on how much memory is consumed by some high-level WebKit parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in Web Inspector that shows the render process memory broken down into several components: To achieve that we instrumented several classes in WebCorehttp://code.google.com/searchframe#search/q=reportMemoryUsage%20package:chromiumtype=csto report an estimation of their memory footprint. The main problem with that approach is that it can be easily broken by changes to the instrumented clasess. We need a way to guard from such changes that would automatically validate the instrumentation and make sure it matches current class structure. We see several ways of doing that. First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/attachment.cgi?id=153479action=review for more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. The second option is to write a tool/script/llvm-plugin and use it on a build-bot to monitor the relevance of instrumentation and update it on when a new field is added to an already instrumented class. However, a question remains who and how often would do this. Pros: a committer may not need to update the instrumentation immediately. Cons: the instrumentation may be behind the actual memory usage. An addifitional effort required to create the tooling. We would like to know what you think about it and will greatly appreciate any ideas and suggestions. Regards, Yury, Alexei, Ilya * ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
Hi there, On Mon, 23 Jul 2012 17:09:19 +0200, Yury Semikhatsky yu...@chromium.org wrote: *Hi WebKit, Almost all developers would like to know why the render process takes so much memory. We are trying to address this problem by providing an information on how much memory is consumed by some high-level WebKit parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in Web Inspector that shows the render process memory broken down into several components: To achieve that we instrumented several classes in WebCorehttp://code.google.com/searchframe#search/q=reportMemoryUsage%20package:chromiumtype=csto report an estimation of their memory footprint. The main problem with that approach is that it can be easily broken by changes to the instrumented clasess. We need a way to guard from such changes that would automatically validate the instrumentation and make sure it matches current class structure. The goals are cool! Have you talked about how much code would be introduced/changed by this approach? We see several ways of doing that. First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/attachment.cgi?id=153479action=review for more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. I think we can't demand this from the committers. Although it seems a trivial task to do the modification, it's too much effort to take care of these individually. Can't we just automatize it somehow (or support the modifications) with a clever script? The second option is to write a tool/script/llvm-plugin and use it on a build-bot to monitor the relevance of instrumentation and update it on when a new field is added to an already instrumented class. However, a question remains who and how often would do this. Pros: a committer may not need to update the instrumentation immediately. Cons: the instrumentation may be behind the actual memory usage. An addifitional effort required to create the tooling. This sounds a bit better for me, I think the effort that we put on tooling will save time later. Since we can tell that when the change and its instrumentation were introduced, the delay shouldn't be a big trouble. We would like to know what you think about it and will greatly appreciate any ideas and suggestions. Done. :) Regards, Yury, Alexei, Ilya * Cheers, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] nightly and www.webkit.org migration - Today 4pm PDT
The nightly and www servers will be migrating to the new hardware this starting today at 4pm PDT. The nightly site will not go down during the migration. The www server needs to go down for 30-60m in order to migrate the database behind it. This downtime includes the blog and sunspider. Thanks, -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
Hi, parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in Web Inspector that shows the render process memory broken down into several components: Unfortunately this part is removed by the mail server, and from webkit-dev archives, but as far as I remember (we measured the memory consumption of webkit several times before), the main memory consumers were JavaScriptCore (to reduce GC calls) and Resource caches, not rendering. First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/attachment.cgi?id=153479action=review for more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. This looks complicated and will likely break. The second option is to write a tool/script/llvm-plugin and use it on a build-bot to monitor the relevance of instrumentation and update it on when a new field is added to an already instrumented class. However, a question remains who and how often would do this. Pros: a committer may not need to update the instrumentation immediately. Cons: the instrumentation may be behind the actual memory usage. An addifitional effort required to create the tooling. Guys here have a lot of experience with static source code analysis, I can give their contacts if you interested. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
On Mon, Jul 23, 2012 at 8:07 PM, Zoltan Horvath zol...@webkit.org wrote: Hi there, On Mon, 23 Jul 2012 17:09:19 +0200, Yury Semikhatsky yu...@chromium.org wrote: *Hi WebKit, Almost all developers would like to know why the render process takes so much memory. We are trying to address this problem by providing an information on how much memory is consumed by some high-level WebKit parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in Web Inspector that shows the render process memory broken down into several components: To achieve that we instrumented several classes in WebCorehttp://code.google.**com/searchframe#search/q=** reportMemoryUsage%20package:**chromiumtype=cshttp://code.google.com/searchframe#search/q=reportMemoryUsage%20package:chromiumtype=cs to report an estimation of their memory footprint. The main problem with that approach is that it can be easily broken by changes to the instrumented clasess. We need a way to guard from such changes that would automatically validate the instrumentation and make sure it matches current class structure. The goals are cool! Have you talked about how much code would be introduced/changed by this approach? We need to add one method for each interesting class that would report its structure. So far we've instrumented about 20 classes and got a pretty good coverage (unknown part is ~10-40% depending on the site). We see several ways of doing that. First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/**attachment.cgi?id=153479**action=reviewhttps://bugs.webkit.org/attachment.cgi?id=153479action=reviewfor more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. I think we can't demand this from the committers. Although it seems a trivial task to do the modification, it's too much effort to take care of these individually. Can't we just automatize it somehow (or support the modifications) with a clever script? We considered putting the code collecting memory data separately from the instrumented classes and generating it but given that we needed to access private fields we preferred current approach. The tool described as the second option could generate a possible fix for the instrumentation if there is an error. That code can be manually committed then. The second option is to write a tool/script/llvm-plugin and use it on a build-bot to monitor the relevance of instrumentation and update it on when a new field is added to an already instrumented class. However, a question remains who and how often would do this. Pros: a committer may not need to update the instrumentation immediately. Cons: the instrumentation may be behind the actual memory usage. An addifitional effort required to create the tooling. This sounds a bit better for me, I think the effort that we put on tooling will save time later. Since we can tell that when the change and its instrumentation were introduced, the delay shouldn't be a big trouble. We would like to know what you think about it and will greatly appreciate any ideas and suggestions. Done. :) Regards, Yury, Alexei, Ilya * Cheers, Zoltan __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
On Jul 23, 2012, at 11:14 AM, Zoltan Herczeg zherc...@webkit.org wrote: Hi, parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in Web Inspector that shows the render process memory broken down into several components: Unfortunately this part is removed by the mail server, and from webkit-dev archives, but as far as I remember (we measured the memory consumption of webkit several times before), the main memory consumers were JavaScriptCore (to reduce GC calls) and Resource caches, not rendering. This is no longer true, with accelerated compositing. Compositing layer backing stores (under GraphicsLayer) can easily be the highest consumer of memory on a web page. It's a glaring omission from your chart in the inspector. GraphicsLayers already report memory use (via backingStoreMemoryEstimate()). This should be easy to hook into the graph. Some other high consumers of memory that I think you're ignoring: * audio and video media elements * Web Audio * decoded images Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
This is somewhat tangential but once we've solved this problem, can we expose the data via testRunner or internals object so that we may use it in our performance tests? It'll be very valuable to be able to monitor changes in these metrics. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
On Mon, 23 Jul 2012 21:21:54 +0200, Ryosuke Niwa rn...@webkit.org wrote:This is somewhat tangential but once we've solved this problem, can we expose the data via testRunner or internals object so that we may use it in our performance tests? It'll be very valuable to be able to monitor changes in these metrics. - RyosukeI totally agree with Ryosuke, from these numbers we can produce really meaningful memory measurement results for the performance[memory] tests. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
On Jul 23, 2012, at 8:09 AM, Yury Semikhatsky yu...@chromium.org wrote: First option we consider is to define a class with the same set of fields as the instrumented one, then have a compile time assert that size of the reference class equals to the size of the instrumented one. See https://bugs.webkit.org/attachment.cgi?id=153479action=review for more details. Pros: compile time error whenever size of an instrumented class changes with the appropriate modifications to the instrumentation function. Cons: it will require each committer to adjust the reference class and the instrumentation on any modification that affects size of the instrumented class. Changes that don't affect size of the class will go unnoticed. What is the advantage of this approach compared to just using the sizeof operator on the relevant classes? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebDriver support in WebKit
The WebDriver w3c spec http://www.w3.org/TR/2012/WD-webdriver-20120710/ was recently published as a first public working draft. The primary goal of the API is to enable website testing from a user's perspective (finding elements, typing, clicking). Like the WebKit Inspector, WebDriver hopes to aid developers in the process of developing/testing their website. Currently Chromium supports this API through a separately distributed binary. I wanted to get some feedback on the idea of supporting WebDriver in WebCore itself (perhaps as a WebCore module, or perhaps in a similar way as the WebKit Inspector). The main benefit of this would be that the WebDriver implementation could be shared among all interested WebKit ports. Thanks Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit memory instrumentation
On Mon, Jul 23, 2012 at 11:21 PM, Ryosuke Niwa rn...@webkit.org wrote: This is somewhat tangential but once we've solved this problem, can we expose the data via testRunner or internals object so that we may use it in our performance tests? It'll be very valuable to be able to monitor changes in these metrics. At the moment the data are only accessible through the Web Inspector protocol but I don't see any issues with exposing it via internals object. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] new -webkit-user-select value: atomic
We intend to work on an experimental implementation of a new -webkit-user-select value that we are calling atomic. This value causes the element to which it is applied to behave atomically for selection purposes; either all of none of the element and its contents are contained in the selection. The user-select property is not currently specified in any CSS specification, but we intend to start discussion on www-style. Firefox implements this property (prefixed with -moz). They have a value, all, that superficially behaves like atomic, but has some different behavior under incremental selection, which is why we're not using that value. Since the property name is prefixed, we don't intend to prefix the new value. Alice ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] new -webkit-user-select value: atomic
On Mon, Jul 23, 2012 at 3:32 PM, Alice Cheng alice_ch...@apple.com wrote: We intend to work on an experimental implementation of a new -webkit-user-select value that we are calling atomic. This value causes the element to which it is applied to behave atomically for selection purposes; either all of none of the element and its contents are contained in the selection. Could you give us an example of how this properly might be used? The user-select property is not currently specified in any CSS specification, but we intend to start discussion on www-style. Yes! Given that IE10 now supports -ms-user-select, it is imperative that we spec this property in the CSS working group. Firefox implements this property (prefixed with -moz). They have a value, all, that superficially behaves like atomic, but has some different behavior under incremental selection, which is why we're not using that value. Could you elaborate more on the difference? Maybe the difference is small enough that it makes sense to reuse all. e.g. Mozilla might be willing to change their behavior for all. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] new -webkit-user-select value: atomic
On Jul 23, 2012, at 3:39 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Jul 23, 2012 at 3:32 PM, Alice Cheng alice_ch...@apple.com wrote: We intend to work on an experimental implementation of a new -webkit-user-select value that we are calling atomic. This value causes the element to which it is applied to behave atomically for selection purposes; either all of none of the element and its contents are contained in the selection. Could you give us an example of how this properly might be used? The user-select property is not currently specified in any CSS specification, but we intend to start discussion on www-style. Yes! Given that IE10 now supports -ms-user-select, it is imperative that we spec this property in the CSS working group. Firefox implements this property (prefixed with -moz). They have a value, all, that superficially behaves like atomic, but has some different behavior under incremental selection, which is why we're not using that value. Could you elaborate more on the difference? Maybe the difference is small enough that it makes sense to reuse all. e.g. Mozilla might be willing to change their behavior for all. Mozilla is not selecting atomically using shift + right. It also does not select atomically upon dragging. These might just be bugs, but we do hope Mozilla will clarify their behavior via the www-style thread. Here is a link: http://lists.w3.org/Archives/Public/www-style/2012Jul/0541.html - Ryosuke Thanks, Alice ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Apple EWS down temporarily
Hi folks, Apple owned Windows and Mac EWS bots are currently not functional due to a network infrastructure change. The cause of the problem is known, and and fix is targeted for Wednesday evening. The bots should be back online then. Thanks, Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] new -webkit-user-select value: atomic
Alice Cheng wrote: Could you elaborate more on the difference? Maybe the difference is small enough that it makes sense to reuse all. e.g. Mozilla might be willing to change their behavior for all. Mozilla is not selecting atomically using shift + right. It also does not select atomically upon dragging. These might just be bugs, but we do hope Mozilla will clarify their behavior via the www-style thread. Here is a link: http://lists.w3.org/Archives/Public/www-style/2012Jul/0541.html Mozilla people will take this up on www-style and in the CSS WG. We would prefer if vendors not add more divergence to user-select or other prefixed properties. We'll try to work quickly to reach consensus in the WG. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] new -webkit-user-select value: atomic
On Mon, Jul 23, 2012 at 5:05 PM, Brendan Eich bren...@mozilla.org wrote: Alice Cheng wrote: Could you elaborate more on the difference? Maybe the difference is small enough that it makes sense to reuse all. e.g. Mozilla might be willing to change their behavior for all. Mozilla is not selecting atomically using shift + right. It also does not select atomically upon dragging. These might just be bugs, but we do hope Mozilla will clarify their behavior via the www-style thread. Here is a link: http://lists.w3.org/Archives/** Public/www-style/2012Jul/0541.**htmlhttp://lists.w3.org/Archives/Public/www-style/2012Jul/0541.html Mozilla people will take this up on www-style and in the CSS WG. We would prefer if vendors not add more divergence to user-select or other prefixed properties. We'll try to work quickly to reach consensus in the WG. Thanks for the follow up :) Yeah, I'm quite concerned about adding even more values to this completely under-speced CSS property as well. We're already divergent on some aspects of none (see https://bugs.webkit.org/show_bug.cgi?id=82692 and https://bugs.webkit.org/show_bug.cgi?id=80159), and I would love to see some progress in the CSS WG before we proceed with the implementation of this new value (would be fine if the consensus was to add a new value; I just want to make sure other browser vendors are well informed). - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
