[chromium-dev] Re: Is there any good tool on Linux to browser and cross reference chromium source code?
+1 for an LXR-like tool. Codesearch is decent if you're just trying to find something, but symbols and .h files aren't hyperlinked, which makes it a lot less useful. OpenGrok http://www.opensolaris.org/os/project/opengrok/ seems pretty cool, but it requires a Java serverlet container (I'm not sure how much of a barrier to setup that would impose). It also doubles as a SCM viewer, which would be a nice alternative to ViewVC. rsesek / @chromium.org On Thu, Sep 17, 2009 at 12:39 AM, James Su su...@chromium.org wrote: I just found DXR http://dxr.proximity.on.ca/dxr/index.html, which is awesome. Might be worth to have a try. Regards James Su 2009/9/17 Evan Martin e...@chromium.org I'd like to set up a web-based code browser on chromium.org, but I played around with a couple and wasn't too happy with any of them. Suggestions are welcome. On Tue, Sep 15, 2009 at 9:19 PM, James Su su...@chromium.org wrote: Hi, I'm currently using cscope + vim, but it's so slow and hard to use. Is there any better choice? Regards James Su --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Dashboard to show which UI/unit/etc (non-webkit) tests are slowest
The slowness dashboard is ready at http://build.chromium.org/buildbot/slowness-report/ There are some problems with it (like garbage in test names), and it could possibly display more data (like median and stddev), but it's generally usable. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linux: Browser side font problems
If you don't care about linux browser side font issues you can skip this. I've been chasing Linux font metrics problems all week and wanted to send around a summary in case anyone has insight or opinions. app/gfx/font on linux uses Skia for measuring metrics, and app/gfx/canvas uses Pango to draw the text. When rendering the text we often times clip to the height returned from font, which is the size returned from Skia. This means that if Skia returns a size smaller than Pango wants to draw at, we get clipping; which was in fact happening. In theory both Skia and Pango should be using the same font files so this doesn't happen, but in practice we get clipping. See http://crbug.com/20823 for one manifestation of this. My first attempt at fixing this was to change font to use Pango for measuring rather than Skia. This resulted in no clipping, but a huge performance regression (close to 2x). Why so big? ResourceBundle creates a number of fonts the first time you ask for one, which triggers asking for the metrics. Apparently asking Pango for the metrics is excruciatingly slow as compared to Skia. It turns out we really only need the metrics of one font at startup (tab heights). My second attempt delayed getting metrics until needed, which brought performance down, but still resulted in a slow down of ~10%. Better, but still no good. The slow down is entirely contributed to the call pango_context_get_metrics. It's worth noting that Gtk calls this function at times as well, so presumably our Gtk code hits this function at some point (if you have bookmarks bar open we'll hit it, or open preferences...). I then spent some time with a debug build of pango and a profiler. This was not terribly enlightening, the profiler attributed the extra time to libfontconfig. I then started tracing through pango code to see if I could locate where Skia and Pango diverge on getting metrics. I traced through some calls and these quickly ended up in Cairo. *SIGH* At that point I talked with Mike Reed and he suggested using the bounding box rather than the ascent/descent. Converting font to use this gets us much closer. For the default font on hardy we are dead on, but at some point sizes we are off by 1. For the time being I'm going with using the bounding box rather than ascent/descent. I believe using pango to get metrics is the right thing to do, but a 10% startup is hard to justify. -Scott --~--~-~--~~~---~--~~ 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: Dashboard to show which UI/unit/etc (non-webkit) tests are slowest
On Thu, Sep 17, 2009 at 8:52 AM, Paweł Hajdan Jr.
phajdan...@chromium.org wrote:
The slowness dashboard is ready
at http://build.chromium.org/buildbot/slowness-report/
ProcessSingletonLinuxTest.NotifyOtherProcessFailure 20.43
This one should be trivial to fix; that 20 second timeout is hardcoded
into the code.
ProcessSingleton::NotifyResult ProcessSingleton::NotifyOtherProcess() {
[...]
timeval timeout = {20, 0};
setsockopt(socket, SOL_SOCKET, SO_SNDTIMEO, timeout, sizeof(timeout));
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] JSNES: A NES emulator that runs well in Chrome
http://benfirshman.com/projects/jsnes/ I highly recommend you use Google Chrome to play JSNES. ... it just about runs on Firefox 3.5 or Safari 4, but it's hardly playable. I wonder if we can get this guy to throw this into chromeexperiments.com ? 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: JSNES: A NES emulator that runs well in Chrome
I was stoked to play SMB III, but without music it isn't the same :-/. - a On Thu, Sep 17, 2009 at 10:14 AM, Peter Kasting pkast...@google.com wrote: http://benfirshman.com/projects/jsnes/ I highly recommend you use Google Chrome to play JSNES. ... it just about runs on Firefox 3.5 or Safari 4, but it's hardly playable. I wonder if we can get this guy to throw this into chromeexperiments.com ? 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: JSNES: A NES emulator that runs well in Chrome
Queue complaints about audio :P On Thu, Sep 17, 2009 at 10:35 AM, Aaron Boodman a...@chromium.org wrote: I was stoked to play SMB III, but without music it isn't the same :-/. - a On Thu, Sep 17, 2009 at 10:14 AM, Peter Kasting pkast...@google.comwrote: http://benfirshman.com/projects/jsnes/ I highly recommend you use Google Chrome to play JSNES. ... it just about runs on Firefox 3.5 or Safari 4, but it's hardly playable. I wonder if we can get this guy to throw this into chromeexperiments.com? 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] Important; gclient failure
If you synchronized sources between [26423, 26461[, be sure to sync to 26461 or manually run gclient runhooks. The hooks weren't called anymore, causing stale project files to be used, causing all kind of weird build failures. Sorry for the trouble, 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: JSNES: A NES emulator that runs well in Chrome
On Thu, Sep 17, 2009 at 10:21 AM, Evan Martin e...@chromium.org wrote: On Thu, Sep 17, 2009 at 10:14 AM, Peter Kasting pkast...@google.com wrote: http://benfirshman.com/projects/jsnes/ I highly recommend you use Google Chrome to play JSNES. ... it just about runs on Firefox 3.5 or Safari 4, but it's hardly playable. I notice that Contra gets 40fps on my (Linux) laptop, but feels much slower than I remember it being. I wonder if this is revealing any Linux-specific timing bugs. More testing: - 32-bit Linux laptop: 40fps, feels slow - 64-bit beefy Linux desktop (maybe slower v8): 40fps, feels slow - Julie's 4 year old Windows machine: 40fps, feels the same slow - new insano Windows machine: 60fps, feels just right I don't have a fast 32-bit Linux machine handy to determine whether it's a Lin/Win thing or if it's just hardware. --~--~-~--~~~---~--~~ 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: JSNES: A NES emulator that runs well in Chrome
On Thu, Sep 17, 2009 at 11:59 AM, Evan Martin e...@chromium.org wrote: - new insano Windows machine: 60fps, feels just right I am happy that I could contribute insano (though I believe the correct spelling is insane-o) to the Chromium lexicon. - 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: JSNES: A NES emulator that runs well in Chrome
There are some neo-retro NES ROMs that have been developed this decade. I bet we could get permission to use them. e.g. http://bobrost.com/nes/games.php I know some of the authors. - nick On Thu, Sep 17, 2009 at 11:59 AM, Evan Martin e...@chromium.org wrote: On Thu, Sep 17, 2009 at 10:21 AM, Evan Martin e...@chromium.org wrote: On Thu, Sep 17, 2009 at 10:14 AM, Peter Kasting pkast...@google.com wrote: http://benfirshman.com/projects/jsnes/ I highly recommend you use Google Chrome to play JSNES. ... it just about runs on Firefox 3.5 or Safari 4, but it's hardly playable. I notice that Contra gets 40fps on my (Linux) laptop, but feels much slower than I remember it being. I wonder if this is revealing any Linux-specific timing bugs. More testing: - 32-bit Linux laptop: 40fps, feels slow - 64-bit beefy Linux desktop (maybe slower v8): 40fps, feels slow - Julie's 4 year old Windows machine: 40fps, feels the same slow - new insano Windows machine: 60fps, feels just right I don't have a fast 32-bit Linux machine handy to determine whether it's a Lin/Win thing or if it's just hardware. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] custom built chromium *much* slower than chrome
This is my problem, I build chromium (yes, in release) and when I benchmark it in sunspider I consistently get worse performance than in chrome. With chrome I always get 700 ms and with my freshly built chromium I always get 1200 ms. I'm building the exact same revision (the one corresponding to the last 3.x stable). I'm building in release and my system type is set to _offficial in the environment. I checked that I'm getting /LTCG as part of the linking options and all seems ok. My platform is VS2008 on Windows 7-64 with the 7.0 Windows SDK. Maybe it's related to _SECURE_SCL setting? I don't see it explicitly set to 0 anywhere in the release property sheets. Does Google use iterator checking? Otherwise, maybe it's because of my platform? maruel told me in irc that Google still uses VS2005 and the 6.1 SDk. Should I try downgrading? (If somebody knows, I'd like to know what OS Google uses as host to build the official releases, as reference). Ideas about what I'm missing? --~--~-~--~~~---~--~~ 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: Is there any good tool on Linux to browser and cross reference chromium source code?
I use a Search engine too: http://www.google.com/codesearch?hl=enlr=q=package:chromium.org+%s Or just search in site: chromium trunk in Google.com. -v1c1ous On Sep 16, 1:19 am, James Su su...@chromium.org wrote: Hi, I'm currently using cscope + vim, but it's so slow and hard to use. Is there any better choice? Regards James Su --~--~-~--~~~---~--~~ 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: Dashboard to show which UI/unit/etc (non-webkit) tests are slowest
How often is this updated? How many runs does it look at to calculate the test run times? On Thu, Sep 17, 2009 at 8:52 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: The slowness dashboard is ready at http://build.chromium.org/buildbot/slowness-report/ There are some problems with it (like garbage in test names), and it could possibly display more data (like median and stddev), but it's generally usable. --~--~-~--~~~---~--~~ 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: custom built chromium *much* slower than chrome
Release mode doesn't correspond to how public Chrome builds are made. Those builds do whole-program optimization IIRC. Correct. As I said I'm setting the build type to _official so I'm getting all the relevant settings defined in that file such as whole-program optimization, LTCG, etc. I'm missing something else. --~--~-~--~~~---~--~~ 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: custom built chromium *much* slower than chrome
The corresponding revision is not the right revision.Did you try to sync your Chromium source code to the 196 branch? This is the source code used for the 3.x release, not the corresponding revision you mentioned. Many improvements, code and bug fixes were merged into the branch after that revision, so it is not the right one to sync to. The branch is available here -http://src.chromium.org/viewvc/chrome/branches/196/ I downloaded the chrome I wanted to compare to (Stable 3.0.195.21). Then visited about:version, looked at the revision number, 26042, and synced to that revision with gclient sync --revision s...@26042. So, are you saying that about:version is unreliable cause Google manually adds patches after syncing? *confused* --~--~-~--~~~---~--~~ 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: custom built chromium *much* slower than chrome
On Thu, Sep 17, 2009 at 4:41 PM, Rozenkraft rozenkr...@gmail.com wrote: The corresponding revision is not the right revision.Did you try to sync your Chromium source code to the 196 branch? This is the source code used for the 3.x release, not the corresponding revision you mentioned. Many improvements, code and bug fixes were merged into the branch after that revision, so it is not the right one to sync to. The branch is available here - http://src.chromium.org/viewvc/chrome/branches/196/ I downloaded the chrome I wanted to compare to (Stable 3.0.195.21). Then visited about:version, looked at the revision number, 26042, and synced to that revision with gclient sync --revision s...@26042. So, are you saying that about:version is unreliable cause Google manually adds patches after syncing? *confused* No, the revision is right, but that doesn't say what build directory kicked it all off. We don't build releases off the trunk, instead they are off a branch (http://src.chromium.org/viewvc/chrome/branches/), so you need to use the information in right branch at that revision. TVL --~--~-~--~~~---~--~~ 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: Dashboard to show which UI/unit/etc (non-webkit) tests are slowest
I don't think the focus tests need as much a delay between tab presses, do they Jay? I have actually a CL almost ready to go that uses a notification instead of waiting for the tab press to trigger a focus change. Takes the test time from 20s to 1s. That should fix both focus related tests. Jay --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] The process for backporting changes to 3.0
Howdy folks, If there is a change you would like merged on to 3.0, the easiest way to ensure that will happen is to ensure: a.) That there is a bug associated with your checkin b.) That the bug is labeled mstone:3.0 I'll do a double check at the end of every week for CL's which meet that criteria. If something is pressing or urgent please send me an IM. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: custom built chromium *much* slower than chrome
Ok, it makes sense now, sorry. I was confused because Phistuck mentioned 196 when I expected 195. In that case, just a problem remaining: how do I know the branch? Upon examination of the branches I would expect the right branch to be 195, as I said, (because it was last updated the day before the release) but PhistucK says it's 196 which was updated 11 days ago. So, how am I supposed to know this? On Sep 17, 10:44 pm, Thomas Van Lenten thoma...@chromium.org wrote: On Thu, Sep 17, 2009 at 4:41 PM, Rozenkraft rozenkr...@gmail.com wrote: The corresponding revision is not the right revision.Did you try to sync your Chromium source code to the 196 branch? This is the source code used for the 3.x release, not the corresponding revision you mentioned. Many improvements, code and bug fixes were merged into the branch after that revision, so it is not the right one to sync to. The branch is available here - http://src.chromium.org/viewvc/chrome/branches/196/ I downloaded the chrome I wanted to compare to (Stable 3.0.195.21). Then visited about:version, looked at the revision number, 26042, and synced to that revision with gclient sync --revision s...@26042. So, are you saying that about:version is unreliable cause Google manually adds patches after syncing? *confused* No, the revision is right, but that doesn't say what build directory kicked it all off. We don't build releases off the trunk, instead they are off a branch (http://src.chromium.org/viewvc/chrome/branches/), so you need to use the information in right branch at that revision. TVL --~--~-~--~~~---~--~~ 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: custom built chromium *much* slower than chrome
Also, if you search for chromium 26042, then the paths all start with branches/195/src/ -scott On Thu, Sep 17, 2009 at 2:15 PM, Amanda Walker ama...@chromium.org wrote: On Thu, Sep 17, 2009 at 5:10 PM, Rozenkraft rozenkr...@gmail.com wrote: Ok, it makes sense now, sorry. I was confused because Phistuck mentioned 196 when I expected 195. In that case, just a problem remaining: how do I know the branch? Upon examination of the branches I would expect the right branch to be 195, as I said, (because it was last updated the day before the release) but PhistucK says it's 196 which was updated 11 days ago. So, how am I supposed to know this? The branch is the third component of the version number in an official build. So, for example, to build a version corresponding to 4.0.207.0 (a recent dev channel release), you'd look at branch 207. --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: Crashes due to 25633
We've decided to keep this CHECK until it hits dev channel for a few days. The fact that users are hitting this means that we need to get meaningful dumps so we can file actionable bugs from it. We'll monitor the crash rate and release a patch for dev channel if it is too high. In the meantime the solution is either: 1) Have the affected users use a new profile. If the user want to send us his/her corrupted profile that is great. or 2) comment out line 53 in sqlite_utils.cc and roll your own build I recommend option 1. You can simply delete the existing profile dir (default) or user --user-data-dir to specify the location for a new profile. -cpu ps. There is a new sqlite wrapper but is not being used extensively yet. --~--~-~--~~~---~--~~ 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: Crashes due to 25633
On 09/17/2009 05:41 PM, cpu wrote: We've decided to keep this CHECK until it hits dev channel for a few days. The fact that users are hitting this means that we need to get meaningful dumps so we can file actionable bugs from it. We'll monitor the crash rate and release a patch for dev channel if it is too high. FWIW, I've backed this change out in the Fedora builds. Too many users jumping ship and refusing to test or help debug. ~spot --~--~-~--~~~---~--~~ 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: Crashes due to 25633
On Thu, Sep 17, 2009 at 2:50 PM, spotrh spo...@gmail.com wrote: We've decided to keep this CHECK until it hits dev channel for a few days. The fact that users are hitting this means that we need to get meaningful dumps so we can file actionable bugs from it. We'll monitor the crash rate and release a patch for dev channel if it is too high. FWIW, I've backed this change out in the Fedora builds. Too many users jumping ship and refusing to test or help debug. We don't get any crash reports from Fedora users anyway, so I guess having more testers doesn't matter much either way? Which reminds me: do you (or have you considered) driving users towards a page like this? https://wiki.ubuntu.com/Chromium/Debug It is kind of frustrating when users file bug reports but aren't tech-savvy enough to include a backtrace; when they're on Ubuntu we can at least point them there. --~--~-~--~~~---~--~~ 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: Crashes due to 25633
On 09/17/2009 06:07 PM, Evan Martin wrote: On Thu, Sep 17, 2009 at 2:50 PM, spotrh spo...@gmail.com wrote: We've decided to keep this CHECK until it hits dev channel for a few days. The fact that users are hitting this means that we need to get meaningful dumps so we can file actionable bugs from it. We'll monitor the crash rate and release a patch for dev channel if it is too high. FWIW, I've backed this change out in the Fedora builds. Too many users jumping ship and refusing to test or help debug. We don't get any crash reports from Fedora users anyway, so I guess having more testers doesn't matter much either way? Which reminds me: do you (or have you considered) driving users towards a page like this? https://wiki.ubuntu.com/Chromium/Debug It is kind of frustrating when users file bug reports but aren't tech-savvy enough to include a backtrace; when they're on Ubuntu we can at least point them there. I will make that sort of a page, but until Fedora includes chromium into its official package repo, few, if any, users will find it. ~spot --~--~-~--~~~---~--~~ 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: Clear Strict-Transport-Security state checkbox added
On Thu, Sep 17, 2009 at 3:37 PM, Ben Goodger (Google) b...@chromium.org wrote: Whoever added this UI, please remove it before I have to when I get back next week. Very well, reverting. 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: Clear Strict-Transport-Security state checkbox added
Thanks! On Thu, Sep 17, 2009 at 3:38 PM, Adam Langley a...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:37 PM, Ben Goodger (Google) b...@chromium.org wrote: Whoever added this UI, please remove it before I have to when I get back next week. Very well, reverting. 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: Clear Strict-Transport-Security state checkbox added
On Thu, Sep 17, 2009 at 3:31 PM, Adam Langley a...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:03 PM, Peter Kasting pkast...@google.com wrote: It's disappointing to me that this change was made without any bug in the bug database linked, and without any input from a member of the UI team, despite the code reviewer (abarth) explicitly wondering about getting UI review. Glen recently moved this dialog so that's it's now four clicks away from the main UI. That certainly starts to put it in the realm of trival UI changes. Also, the dialog is already concerned with things that our users don't know about (like 'cookies') and it has sensible default if you don't know what it means. I'm more bothered that people who care about their privacy have the ability to control the information we store about them. Advanced users (including me) know what everything means in that dialog except the checkbox, and it's very scary and obscure sounding. I agree with Peter that it should not have gone in. 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] Re: Clear Strict-Transport-Security state checkbox added
It clears the list of hosts in StrictTransportSecurityState: // StrictTransportSecurityState // // Tracks which hosts have enabled StrictTransportSecurityState. After a host // enables StrictTransportSecurityState, then we refuse to talk to the host // over HTTP, treat all certificate errors as fatal, and refuse to load any // mixed content. // rsesek / @chromium.org On Thu, Sep 17, 2009 at 7:28 PM, Erik Kay erik...@chromium.org wrote: For those of us who are curious, could someone explain what this does? Erik On Thu, Sep 17, 2009 at 4:20 PM, Finnur Thorarinsson fin...@chromium.org wrote: +1 to what Peter is saying. Like Brett, I have no clue what this checkbox means and think it shouldn't have been added. However, the question I have... is it appropriate to tuck this in with something like deleting the history (like we do with last session, recently closed tabs, autogenerated keywords, etc)? It is hard for me to evaluate that, not knowing what this does... :) -F On Thu, Sep 17, 2009 at 16:09, Evan Martin e...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:54 PM, Brett Wilson bre...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:50 PM, Evan Martin e...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:38 PM, Adam Langley a...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:37 PM, Ben Goodger (Google) b...@chromium.org wrote: Whoever added this UI, please remove it before I have to when I get back next week. Very well, reverting. Why not #ifdef around it? I fear if you revert you'll never check it in again. If that happens, it's the best possible argument that this is a silly thing to add. No, it's just the argument that it's not the sort of thing people are willing to expend the energy to argue about. With this sort of response I'd be tempted to just give up on the patch. --~--~-~--~~~---~--~~ 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: [linux] computing cpu usage
Is the last version released under the LGPL version good enough for our needs? If so, we can just use that. And not feel too bad. :-) As a side note, if we use ps or /proc we're just scraping information that was printed out by a GPL program. :-) J On Thu, Sep 17, 2009 at 4:22 PM, Peter Kasting pkast...@chromium.orgwrote: On Thu, Sep 17, 2009 at 4:18 PM, Evan Martin e...@chromium.org wrote: While within the law, I'd prefer to respect the spirit of the author's intention. Your call. Generally I would prioritize users' benefit (which they get both from libgtop being better and from our Linux devs not wasting their time reimplementing it, and thus fixing other important stuff) over other considerations, but I could be speaking from my bias, which is pretty violently anti-GPL. 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: Clear Strict-Transport-Security state checkbox added
There's a published paper about it too: http://www.adambarth.com/papers/2008/jackson-barth.pdf On Thu, Sep 17, 2009 at 4:34 PM, Robert Sesek rse...@chromium.org wrote: It clears the list of hosts in StrictTransportSecurityState: // StrictTransportSecurityState // // Tracks which hosts have enabled StrictTransportSecurityState. After a host // enables StrictTransportSecurityState, then we refuse to talk to the host // over HTTP, treat all certificate errors as fatal, and refuse to load any // mixed content. // rsesek / @chromium.org On Thu, Sep 17, 2009 at 7:28 PM, Erik Kay erik...@chromium.org wrote: For those of us who are curious, could someone explain what this does? Erik On Thu, Sep 17, 2009 at 4:20 PM, Finnur Thorarinsson fin...@chromium.org wrote: +1 to what Peter is saying. Like Brett, I have no clue what this checkbox means and think it shouldn't have been added. However, the question I have... is it appropriate to tuck this in with something like deleting the history (like we do with last session, recently closed tabs, autogenerated keywords, etc)? It is hard for me to evaluate that, not knowing what this does... :) -F On Thu, Sep 17, 2009 at 16:09, Evan Martin e...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:54 PM, Brett Wilson bre...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:50 PM, Evan Martin e...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:38 PM, Adam Langley a...@chromium.org wrote: On Thu, Sep 17, 2009 at 3:37 PM, Ben Goodger (Google) b...@chromium.org wrote: Whoever added this UI, please remove it before I have to when I get back next week. Very well, reverting. Why not #ifdef around it? I fear if you revert you'll never check it in again. If that happens, it's the best possible argument that this is a silly thing to add. No, it's just the argument that it's not the sort of thing people are willing to expend the energy to argue about. With this sort of response I'd be tempted to just give up on the patch. --~--~-~--~~~---~--~~ 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: [linux] computing cpu usage
On Thu, Sep 17, 2009 at 4:40 PM, Jeremy Orlow jor...@chromium.org wrote: Is the last version released under the LGPL version good enough for our needs? If so, we can just use that. In that case, we'd need to ship our own version of libgtop rather than relying on the system one, which would be more effort to bring into our build system than I am willing to bear. Also, Tom would shoot me. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
