[chromium-dev] Thinking about refactoring the confluence of processes and ipc channels.
[Reposting from wrong mailing list, sorry for dupe.] On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named pipes), with one end passed through the spawn to the child process. Right now the interfaces don't expose this dependency, so I'm thinking of refactoring things a bit to do so. Jeremy suggested that I talk to Carlos, and I know tvl is looking at this - anyone else want in? Basic notion would be to modify LaunchApp() (or whatever Tom is doing to it) to accept an IPC::Channel (versus the current vector of fds). The appropriate endpoint would not be marked close-on-exec, and would be passed down to the child via a new command-line parameter (versus the current static location). This could pretty easily be expanded to pass through multiple channels and make the new command-line parameter have multiple values, if we need to go there. Once we can pass fds over channels, that may be immaterial. From there, the Windows code could be adjusted to use the create-channel-spawn-process ordering to match, and the calling points would hopefully become less forked. Adam mentioned on the wrong-mailing-list version of this thread that it's accepted to wire file descriptors into fixed places. Either way, my goal is to make sure that launching Chrome-internal helper tasks is distinct from launching arbitrary tasks, because the Chrome-internal case most likely wants to make special provisions WRT the child, and right now that seems to be in the calling code. -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: Thinking about refactoring the confluence of processes and ipc channels.
On Wed, Feb 4, 2009 at 11:02 AM, Darin Fisher da...@chromium.org wrote: On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote: On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named pipes), with one end passed through the spawn to the child process. Right now the interfaces don't expose this dependency, so I'm thinking of refactoring things a bit to do so. Jeremy suggested that I talk to Carlos, and I know tvl is looking at this - anyone else want in? Basic notion would be to modify LaunchApp() (or whatever Tom is doing to it) to accept an IPC::Channel (versus the current vector of fds). LaunchApp is in base/, but IPC::Channel is in chrome/common/. You can't have base/ depend on chrome/common/, so if this dependency is the right answer, then we'd need to move IPC::Channel down to base/. Why is passing an IPC::Channel to LaunchApp the answer? In order to wire up IPC::Channel on Unix, we must do something on the order of passing an fd retrieved from IPC::Channel to whatever it is which spawns the subprocess. Right now, the callers pulls the fd from the channel and passes it to LaunchApp(). So like casting to void*, the dependency is there, it's just not cleanly exposed. Another option I was thinking about over the weekend was to have the spawn code expose API for passing fds down to children (using a distinct socketpair per child), then IPC::Channel and base::SharedMemory could use that. -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: Thinking about refactoring the confluence of processes and ipc channels.
On Wed, Feb 4, 2009 at 11:10 AM, Thomas Van Lenten thoma...@chromium.org wrote: On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher da...@chromium.org wrote: On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote: [Reposting from wrong mailing list, sorry for dupe.] On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named pipes), with one end passed through the spawn to the child process. Right now the interfaces don't expose this dependency, so I'm thinking of refactoring things a bit to do so. Jeremy suggested that I talk to Carlos, and I know tvl is looking at this - anyone else want in? Basic notion would be to modify LaunchApp() (or whatever Tom is doing to it) to accept an IPC::Channel (versus the current vector of fds). LaunchApp is in base/, but IPC::Channel is in chrome/common/. You can't have base/ depend on chrome/common/, so if this dependency is the right answer, then we'd need to move IPC::Channel down to base/. Why is passing an IPC::Channel to LaunchApp the answer? Just for reference, I'm still sorting things out here, but on the Mac, we might want to actually bounce some of these launches through LaunchServices so the app think it was launched from the Dock/Finder/by the user and avoid it inherriting fds, mach info, etc. (I realize the renderers might need this, so we might end up w/ 1 launch api so we can get different style of launches, the current api seems to be mangled/extended w/ a collection of args to sorta cover different needs.) It seems reasonable to me to distinguish launching an app to process a download from launching a renderer or plug-in process. We probably want to be pretty pedantic about the renderer process, and I'm very certain we don't want to rely on external services to deal with it (relying on Finder to launch renderer processes feels very uncomfortable to me). Due to the differences in process model between Unix and Windows, there may be bits which would be easier/cleaner/safer to setup in the parent process and inherited into the child versus passing parameters to the child and having it set things up (the bootstrap fd for IPC is one such thing). -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: Linux Omnibox
On Thu, Feb 19, 2009 at 4:53 AM, Dean McNamee de...@chromium.org wrote: I've started working on a GTK omnibox widget. I'll let you know when I have some more progress. I've been trying to figure out omnibox from the Mac side. I don't see anyone else having claimed it, let me know if I'm wrong. -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] Unit tests and anonymous namespaces.
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like this:
warning: ‘MyTest_ATest_Test’ has a field
‘MyTest_ATest_Test::anonymous’ whose type uses the anonymous
namespace
warning: ‘MyTest_ATest_Test’ has a base ‘unnamed::MyTest’ whose type
uses the anonymous namespace
Removing the namespace fixes it, which is poor because we seem to want
to move towards more anonymous namespace use. Putting the test case
inside the namespace also fixes it, but is incompatible with
FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
http://gcc.gnu.org/gcc-4.2/changes.html
Members of the anonymous namespace are now local to a particular
translation unit, along with any other declarations which use them,
though they are still treated as having external linkage for language
semantics.
At this point, I'm sort of at the bleeding edge of my knowledge. For
FRIEND_TEST() cases, it seems like the anonymous namespace needs to
go, but elsewhere it can be changed to enclose the entire file. Does
that seem reasonable for now?
-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: Profile Corruption, cause?
If SQLite is crashing due to corruption in the database, we should be able to get Dr Hipp to help fix it. But we'd need a repeatable case to send to him. If we had a database which demonstrated this, I could certainly see about crafting a simplified database of example data to replicate the problem. If it's due to the in-memory data structures being corrupted, that's a whole 'nother kettle of fish, I'm not sure what SQLite can really do about that. An idea I've had in the past was so implement a custom memory allocator to keep the SQLite data structures in a distinct zone from regular data structures, so that you at least can't get the case of stale references being used to overwrite data structures, and should help protect against other code's buffer overflows. Random rogue pointers would still be dangerous, though! Some of our databases we preemptively read to warm up the disk cache, so just running PRAGMA integrity_check; might be cheap enough to be useful. Another option we could consider would be adding (or looking for) code to checksum pages. We could also perhaps implement independent page validity checks at the VFS layer, before things go to disk, to protect against in-memory structures being corrupted, which could at least keep things valid at a metadata level. In my experience SQLite is pretty good about throwing SQLITE_CORRUPT when it detects corruption, but due to how data is encoded there are a lot of cases where the corruption is not easy to detect w/in SQLite (you get back garbage, but it's well-formed garbage :-). If SQLite itself is overrunning buffers or something, that's a definite bug which I'm sure Dr Hipp would be interested in helping fix. -scott On Fri, Mar 6, 2009 at 10:02 AM, Erik Kay erik...@chromium.org wrote: On Fri, Mar 6, 2009 at 9:33 AM, Brett Wilson bre...@google.com wrote: Getting the database has helped in a few cases where it turned out some assumptions were being violated, but if the sqlite data structures are corrupted, getting the DB has never been helpful to diagnose the root cause. It might help us make sqlite not crash for these types of corruption, though. I think we should install an exception handler on the DB threads, and if we get two crashes in a row from sqlite, recreate the DB. Yep. This would be nice. If these crashes are really this frequent, perhaps we should move the db out of the browser process. Or perhaps we could simply have an out of process validator that we could run if we got a single browser crash from sqlite. Erik Brett On Mar 6, 2009 9:19 AM, Erik Kay erik...@chromium.org wrote: One thing that would help is if some of the users who are running into this would be willing to share their whole profile with us. While our best guess is that this is sqlite corruption, we don't know for sure. Even if it is sqlite corruption, having the specific db might help us figure out how to more reliably detect it. Erik On Thu, Mar 5, 2009 at 10:39 PM, Finnur Thorarinsson fin...@chromium.org wrote: I suspect 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: Unit tests and anonymous namespaces.
I just wanted to make sure I understood your proposal.
Right now, test classes want to be in the anonymous namespace so that
unit test files do not have to coordinate with each other in the
naming of test classes. With your proposal, the thing which is
exposed outside of the anonymous namespace (MyClassPeer) is based on a
thing already known to be unique (MyClass), so coordinate is not an
issue unless you have multiple unit test files testing the same class.
There are still just as many items exposed outside of the anonymous
namespace, but they are named in a way which prevents collisions.
Is that about right?
Thanks,
scott
On Tue, Mar 3, 2009 at 4:49 PM, William Chan (陈智昌)
willc...@chromium.org wrote:
My old team never really used FRIEND_TEST. We found it ugly that our
production code depended on test code. We typically used friended
Peer classes defined in the unittest file, but not in the anonymous
namespace. These are simple shims that provide access to the private
section. It also saves on having to FRIEND_TEST each individual test
as you add them. It looks like almost every time FRIEND_TEST is used,
it's used for multiple tests, not just a single one. I'm not sure how
much of a problem chrome has with build dependencies leading to
rebuilds, but it was very annoying in google projects to add a
FRIEND_TEST to a widely used .h file, thus forcing everyone to
rebuild, even though you're only adding a new test.
On Tue, Mar 3, 2009 at 4:30 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess sh...@chromium.org wrote:
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like this:
warning: 'MyTest_ATest_Test' has a field
'MyTest_ATest_Test::anonymous' whose type uses the anonymous
namespace
warning: 'MyTest_ATest_Test' has a base 'unnamed::MyTest' whose type
uses the anonymous namespace
Removing the namespace fixes it, which is poor because we seem to want
to move towards more anonymous namespace use. Putting the test case
inside the namespace also fixes it, but is incompatible with
FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
http://gcc.gnu.org/gcc-4.2/changes.html
Members of the anonymous namespace are now local to a particular
translation unit, along with any other declarations which use them,
though they are still treated as having external linkage for language
semantics.
At this point, I'm sort of at the bleeding edge of my knowledge. For
FRIEND_TEST() cases, it seems like the anonymous namespace needs to
go, but elsewhere it can be changed to enclose the entire file. Does
that seem reasonable for now?
-scott
Assuming that you really need to use TEST_F, then it would be unfortunate to
lose the anonymous namespace. The anonymous namespace has allowed us to
have short names for helper classes used by tests without fear of colliding
with other short names used by other tests. (We have had those kinds of
conflicts in the past.)
We don't use FRIEND_TEST that much. Maybe we can just use #ifdef UNIT_TEST
to expose class APIs to unit tests?
-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] Re: Unit tests and anonymous namespaces.
2009/3/6 William Chan (陈智昌) willc...@chromium.org: 2009/3/6 Scott Hess sh...@chromium.org: I just wanted to make sure I understood your proposal. Right now, test classes want to be in the anonymous namespace so that unit test files do not have to coordinate with each other in the naming of test classes. With your proposal, the thing which is exposed outside of the anonymous namespace (MyClassPeer) is based on a thing already known to be unique (MyClass), so coordinate is not an issue unless you have multiple unit test files testing the same class. There are still just as many items exposed outside of the anonymous namespace, but they are named in a way which prevents collisions. Is that about right? Mostly right. It's fewer things exposed outside of the anonymous namespace, since previously you needed each TEST/TEST_F class to exist outside the anonymous namespace in order for you to FRIEND_TEST it. In this way, you only have one Peer per class you're testing. I don't know enough about Chrome yet, but if there were some very commonly used classes, then it might make sense to put the Peer class in a header file for multiple tests to share. My gut instinct is this use case doesn't happen enough in Chrome to make it worthwhile, but I have no clue. It made more sense in the Google code base for various reasons. Also, I'm a big fan of testing via the public interface methods as much as possible. Hopefully we don't need to friend most classes in order to tell them well. The complaint I got about putting the test class outside the anonymous namespace is that there was another completely unrelated test far away which used the same name (and was also outside the anonymous namespace, but could be put inside). Having files implementing unittests around a single class needing to coordinate with each other seems much more reasonable. Thanks, 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] Omnibox q around Mac+Chromium best-practices.
I'm refactoring my Omnibox code towards something I'm willing to put up for review, and am realizing that I need to find a way to rule on whether I should have thick Objective-C helpers or thin ones. Say for instance that I have an NSTableView, I'll need a data source for that, which needs to be an Objective-C object. At the thin extreme, I can put the minimum amount of code in that object to fulfill the data source protocol, plus anything I need for handling delegation or target/action type things, which leaves setup and wiring in the C++ code. At the thick extreme I would push most of the Objective-C code into the Objective-C object, and have the C++ code call into that. Or there's something in the middle. WDYT? Right now it's somewhere in the middle. I don't create Objective-C methods solely to be called from C++, nor C++ methods solely to be called from Objective-C, except for cases where either would need to poke through the encapsulation boundary. Thanks, 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: Mac ui_tests blows away from fraction of your profile.
I can see how that's happening in pref_service_uitest.cc and memory_test.cc, but AFAICT I don't see how it's being done generally for ui_tests test cases. Perhaps it's that --user-data-dir should be passed to ui_tests itself, which means if you run ui_tests without that flag, it will still use your default profile. Or maybe I misunderstand entirely. BTW, I was just stupid when I thought that Mac was broken because of being hacked together. Some of the profile setup is certainly hacked together, but as far as I can tell, it does the right thing for --user-data-dir (though having it fall back to the default dir when the provided one doesn't exist threw me for awhile, that seems unexpected). -scott On Wed, Apr 8, 2009 at 11:23 AM, Darin Fisher da...@chromium.org wrote: Also, unless you do something like this, it ends up being difficult for developers to dogfood the product, or if they do try to dogfood the product, then they are strongly inscentivized not to run the ui_tests. Neither option is good. -Darin On Wed, Apr 8, 2009 at 11:21 AM, Darin Fisher da...@chromium.org wrote: Maybe this is well known, but what we did to avoid this problem on Windows is to leverage the --user-data-dir command line switch to force the chrome instance launched by the ui_tests to use a dedicated user data directory. We toss that directory prior to each test case IIRC. -Darin On Wed, Apr 8, 2009 at 11:10 AM, Scott Hess sh...@chromium.org wrote: I posted this on the irc channel yesterday, I know at least Peter noticed, but John suggested something more overt. When you run ui_tests on Mac, you will blow away some fraction of your Chromium.app profile. Things like history and bookmarks. This is a known issue, but may not be a known consequence. If anyone wants to circle back and fix profiles, that would be wonderous. I was thinking of looking at it myself, but am instead trying to figure out where my omnibox stuff is going wrong. It occurs to me that if you ran ui_tests while running Chromium.app, or two ui_tests, you may also see strange and wonderful results. -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: DO NOT ADD DEPENDENCIES FROM CHROME/VIEWS on CHROME/COMMON
On Fri, Apr 24, 2009 at 10:19 PM, Brett Wilson bre...@chromium.org wrote: On Fri, Apr 24, 2009 at 10:10 PM, Aaron Boodman a...@chromium.org wrote: Is it possible to enforce these rules with code rather than capital letters? I don't think I've made this particular error, but it's something I could see myself doing. From their names, chrome/common seems like a reasonable thing to include from chrome/views. Just a thought. Don't we have something already to enforce dependency rules like this? The problem is that there are already some dependencies, so we can't enforce them. The dependencies are checked on a per-directory basis. I would like to prevent people from including browser from renderer_host and tab_contents but can't for the same reason. We could have some complicated exception list in the checkdeps tool, but that's much harder than shouting on the mailing list. A stupid solution might be to allow a dependency on target_indirection/, and allow target_indirection/ to depend on target/, and have files in target_indirection/ like: file.h: // Copyright blah blah... // If you add dependencies to this file, Ben will harangue you. #include chrome/target/file.h As things get detangled, files disappear from target_indirection/ until all are gone! -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: Unpacking Extensions and the Sandbox
On Fri, May 1, 2009 at 11:17 AM, Aaron Boodman a...@chromium.org wrote: We can use DuplicateHandle() to get the input file handle in, but I am not sure what to do about getting the directory sturcture out. Crazy-talk: Have the renderer unpack the zip into a SQLite database. Architecture-astronaut-talk: Have a virtual filesystem API which you could expose either from the browser to a renderer (chroot-like sandboxing), or from a utility process to a renderer (utility process handles the unzipping). It's only crazy if this problem never comes up again. -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: Unforking: Canary Bot Lives!
HEROIC! On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Hello all, This is kind of a momentous occasion. For the first time -- ever, our WebKit Canary bot (the one that pulls directly from WebKit upstream) has built successfully and was able to run tests: http://build.chromium.org/buildbot/waterfall.fyi/builders/Webkit%20(webkit.org)/builds/2937 What does this mean? This means that our unforking efforts have finally paid off -- we can now pull directly from WebKit upstream! Congratulations to all of you who worked and helped during the last 7 months! This was a long run, and despite various setbacks, we have reached this milestone. This also means that the daily merge as we know it is soon to be replaced with a less daunting activity -- WebKit gardening. I am working on the document to define what this will entail. Stay tuned. :DG --~--~-~--~~~---~--~~ 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: Suggestion for crossplatform ProcessSingleton and ChromeBrowserProcessId()
I agree with the earlier argument about not larding startup with things like writing new files to id the coming-up Chrome to late-coming instances. An alternative might be to acquire a lock to protect the profile, and write an id asynchronously after startup. The late-coming instance would see the lock and wait for the id to appear (or the lock to evaporate). This does mean the late-coming instance will have to wait sometimes, but in those cases the coming-up instance presumably is not ready to respond to requests anyhow. On Mac and Linux, all we need for the lock is an agreed-upon open file descriptor, which should be easy to find. We could acquire the lock in parallel with other startup activity which doesn't modify system state. -scott On Tue, May 5, 2009 at 10:16 AM, Amanda Walker ama...@chromium.org wrote: Thanks for elaborating. So if we look at it another way, there are several different problems that ProcessSingleton is currently used to solve: - Prevent multiple instances of Chromium from referring to the same profile/user data directory. In the general sense, what we need here is a way to acquire and test locks on data directories. This is a cross-platform requirement: all platforms should be able to launch instances of Chromium in different user sessions with different user data / profiles (in order to support fast user switching on Mac Windows, single Linux boxes with multiple people logged in, etc. Currently, ProcessSingleton really only solves this by accident. It seems cleaner to me to meet this requirement with an explicit mechanism: Something like a ProfileLock or DirectoryLock, for example. This also gives a way to ease this requirement if someone fixes the concurrent-access problem, without affecting other uses of ProcessSingleton. - Testing, since a number of tests are not multiple-instance safe. I would describe this as a defect in those tests or the test framework, which again ProcessSingleton only mitigates by accident. I would prefer we address this by fixing the tests and/or test scripts so that we can indeed run tests in parallel without worrying about them stepping on each other. We have a strong desire to reduce our build cycle time, of which having to run tests serially instead of in parallel is a large component. - Within a user session, ensuring that requests to open URLs get processed by a currently running instance of Chromium instead of launching a new one. This is where platform differences are strongest, and is ProcessSingleton's main function. Registering properties on windows or the like for Windows and X11 seems cleaner to me than putting breadcrumbs into the file system, since window properties are inherently tied to the user session and to an active instance of the application (and thus do not need to be cleaned up on a crash, etc.). On the Mac, this function is provided by the OS, so there's no need for Chromium to duplicate it. --Amanda On Tue, May 5, 2009 at 12:27 PM, Никита Офицеров himi...@gmail.com wrote: I'm sorry for the late response, I've been quite busy last week. 2009/4/27 Amanda Walker ama...@chromium.org: Hacky is fairly subjective: are there particular things about the existing implementation that bother you? Currently they are different for each OS because each OS has its own issues surrounding launching multiple instances of the browser, different mechanisms for handling incoming requests from the OS to open web pages, and so on. 2009/4/28 stoyan sto...@chromium.org: Well, on Windows code looks racy, does not work well across multiple desktops, and probably will create troubles accessing userdata when same instance is running in different terminal sessions (with same user account). The problem with quick, baroque source code is that usually there are lots of corner cases. I have rethought the idea after your comments, and there are several problems with current Windows implementation: 1. As Stoyan mentioned, window messaging does not work across multiple desktops. Therefore it doesn't work across multiple terminal sessions. Consider the following use case: A user has a version of Windows that allows multiple consequent terminal sessions on his PC, and leaves Chrome opened. Then he opens a session from his laptop and launches Chrome. Preferred result is opening a new window in the second session, but AFAIK it's impossible for the Chrome master process to open a window in a different window station. Hence quite a lot of changes are required for this to function, like delegating handling of a widget to the newly created process, and these fall out of the scope of this idea. But current ProcessSingleton will just fail to detect another Chrome instance and crash or show weird behavior. If it worked, we could at least show some message telling user that running Chrome from different terminal sessions is not yet implemented. So IMHO
[chromium-dev] Re: Why is the Mac Omnibox stealing focus?
The why is probably because I misunderstood something. With an NSTextField there, we can't set the selection without having focus, which may have confused me into grabbing focus in cases where it isn't needed (or requested). I've been spending some time figuring out where all that code can get called from. Now that some of the other code is more fleshed out, the original reason for it to be there might be completely gone. http://crbug.com/11920 -scott On Wed, May 13, 2009 at 2:27 PM, Avi Drissman a...@google.com wrote: OK, so this was r15790. The code already exists to set the focus to the location bar if it already had it, though. Avi On Wed, May 13, 2009 at 2:24 PM, Avi Drissman a...@google.com wrote: I'm implementing save/restore focus when switching tabs, and a recent checkin on the Mac omnibox is causing it to steal the focus. To see this: (gdb) b -[NSWindow makeFirstResponder:] Then switch tabs: #5 0x961f7f7b in -[NSTextField becomeFirstResponder] () #6 0x000c209f in AutocompleteEditViewMac::UpdateAndStyleText (this=0x595a220, display_te...@0x595a260, user_text_length=0) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:281 #7 0x000c24d7 in AutocompleteEditViewMac::SetWindowTextAndCaretPos (this=0x595a220, te...@0x595a260, caret_pos=0) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:203 #8 0x000bcd36 in AutocompleteEditModel::Revert (this=0x595a250) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit.cc:174 #9 0x000c23bd in AutocompleteEditViewMac::RevertAll (this=0x595a220) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:215 #10 0x000c25b4 in AutocompleteEditViewMac::Update (this=0x595a220, tab_for_state_restoring=0x619da00) at /Users/avi/Source/chrome/src/chrome/browser/autocomplete/autocomplete_edit_view_mac.mm:125 #11 0x001862bf in LocationBarViewMac::Update (this=0x5959720, contents=0x619da00, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/cocoa/location_bar_view_mac.mm:62 #12 0x00197ac8 in -[ToolbarController updateToolbarWithContents:shouldRestoreState:] (self=0x59554a0, _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at /Users/avi/Source/chrome/src/chrome/browser/cocoa/toolbar_controller.mm:102 #13 0x00181465 in -[BrowserWindowController updateToolbarWithContents:shouldRestoreState:] (self=0x5944880, _cmd=0x169a0a8, tab=0x619da00, shouldRestore=1 '\001') at /Users/avi/Source/chrome/src/chrome/browser/cocoa/browser_window_controller.mm:305 #14 0x0017f1ff in BrowserWindowCocoa::UpdateToolbar (this=0x5949b10, contents=0x619da00, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/cocoa/browser_window_cocoa.mm:145 #15 0x00127b49 in Browser::UpdateToolbar (this=0x59432c0, should_restore_state=true) at /Users/avi/Source/chrome/src/chrome/browser/browser.cc:2257 UpdateToolbar ends up in AutocompleteEditViewMac::UpdateAndStyleText() which, on lines 280-3 insists on becoming the keyboard focus. Why? Avi --~--~-~--~~~---~--~~ 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: Changes to FilePath?
This post made me think that we should have infrastructure so that
certain unit tests can opt to run in a restricted environment to
enforce that someone doesn't come along and add filesystem-access code
or other known-bad synchronous APIs.
I realize that that is probably hard, and that patches would be
welcome. Just throwing it out there in hopes that someone says Hey,
I know how to do that and someone else says Hey, do that.
-scott
[It could also be a rathole that only seems like a good idea until you
actually try it, like getting const-ness propagation thoroughly
correct.]
On Wed, May 13, 2009 at 1:03 PM, Mark Mentovai m...@chromium.org wrote:
If you've got a file that begins its life as something on-disk, and
you just need to carry the path to it around, then that's fine, it
should live its life as a FilePath.
If you've got to create a file using some name where the name is some
constant in code, use FilePath with ASCII constants. AppendASCII
exists to stick new ASCII components onto existing FilePaths. This is
fine and is considered safe because ASCII is a subset of any rational
filesystem encoding.
If you've got to take an arbitrary FilePath and convert it for display
to the user, or take an arbitrary string in a known encoding and
re-encode it for the filesystem, then we don't have anything in
FilePath for this. I believe that if we do add something, it should
strictly operate only on single pathname components at a time, and not
entire pathnames. We could add it to FilePath or we could add it
somewhere else, because it is sort of distinct from what FilePath is
really supposed to be, which is just a container for ferrying around
native paths.
It's also a specification and implementation nightmare. Everyone has
a different idea of what normalization means. What's your idea?
Yes, I know it's a nightmare all around, but I think it would be useful to
have something that addresses this. My idea would be the same as Python's
os.path.normpath, mainly because it's a well-tested, seasoned example with
test cases. Windows also has a routine for this (PathCanonicalize) that
could be used (but I know it doesn't work for UNC paths).
Why would it be useful? Do you want to compare paths for equality?
Then we should have an API that compares paths for equality. It would
have to hit the disk to do so. You might need general-purpose
canonization to implement that on some systems. Great, you need to
hit the disk to do that too. It's fine if you want these things, but
we can't put them into FilePath. It's important that FilePath remain
lightweight and not make any system calls, because system calls can
block and FilePath is just a data carrier.
os.path.normpath is known to be buggy. It might be well-tested and
seasoned, but only within the confines of its known limitations.
Watch this.
m...@anodizer bash$ ls -l a/b/../c
-rw-r--r-- 1 mark staff 0 May 13 15:47 a/b/../c
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
import os.path
os.path.normpath('a/b/../c')
'a/c'
^D
m...@anodizer bash$ ls -l a/c
ls: a/c: No such file or directory
Probably the same as os.path.normcase in Python. I want this stuff so that
I can make sure that I can at least semi-reliably compare/manipulate
FilePaths to do things like absolute-relative path conversion, or store
FilePaths in a set or map and be sure I don't have multiple entries pointing
to the same file. Without these kinds of operations, doing these things is
pretty much impossible.
I don't think os.path.normcase does what you're asking for either.
m...@anodizer bash$ ls -lid /System/Library
81 drwxr-xr-x 64 root wheel 2176 May 12 18:37 /System/Library
m...@anodizer bash$ ls -lid /system/LIBRARY
81 drwxr-xr-x 64 root wheel 2176 May 12 18:37 /system/LIBRARY
m...@anodizer bash$ python
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright, credits or license for more information.
import sys
sys.platform
'darwin'
import os.path
os.path.normcase('/System/Library')
'/System/Library'
os.path.normcase('/system/LIBRARY')
'/system/LIBRARY'
^D
Even os.path.realpath returns the same results.
Again, it sounds like what you really want is a pathname comparator
that hits the disk. You really can't do this stuff correctly on most
systems without talking to the filesystem. You can't even do
general-purpose canonization without talking to the filesystem.
Let me make clear: I'm not trying to shoot down the idea of needing to
be able to compare paths or even necessarily canonize them. I'm
arguing primarily against doing it in FilePath, but I'm also also
trying to illustrate that doing proper comparisons and canonization is
harder than it seems, that even seasoned and well-tested APIs
[chromium-dev] Re: [chromium-reviews] Re: Add in boost_tuple into third-party for use by googlemock in windows.
If this is the only reason gmock needs boost, it seems like a better idea would be to push a copy of tuple.h into gmock and submit a patch to make it more self-contained in the first place. -scott On Fri, May 15, 2009 at 11:17 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: One other idea to explore...what about reimplementing tr1::tuple using base::Tuple? It'd be a pretty naughty hack (adding something to the tr1:: namespace), but for the limited use-case of gmock, it could be good enough? -Albert On Fri, May 15, 2009 at 11:11 AM, Marc-Antoine Ruel mar...@chromium.org wrote: [-chromium-reviews, +chromium-dev] (take 2) From their website, To use Google Mock, you will need the TR1 tuple C++ library installed. and not directly boost. Up to now, chromium source tree assumed defined(_MSC_VER) == No TR1, which is not exactly true. This is particularly not true on VS2008 + SP1 + Feature Pack. Since it's included in VS2008 as an addon and there's only VS2005 that truly lacks it, it could be a compelling reason to drop support for VS2005. We'd be at odds with WebKit but 'eh' is all I have to say. :) It'd be a bit awkward with a potentially eminent move to VS2010 within a year or so. So to summarize my mind; If TR1 is available natively on MSVC, I want its stl tr1 library to be used with conditional include magic. I'm fine to include boost only as a supplicant to continue supporting MSVC8 and MSVC9 without FP. Is that fine? M-A 2009/5/15 John Grabowski j...@chromium.org I did a quick test. The minimal set of files needed to get only boost's tuple is 390 (down from ~1200 in the zip), and size drops from 9M to 1.3M. Windows may differ a tad that OSX (e.g. uses platform/win32.hpp instead of platform/macos.hpp) but it'll be in the same ballpark. Is an extra 1.3M in the source tree acceptable for the benefit of getting gmock? I think yes. maruel brettw? jrg On Fri, May 15, 2009 at 9:48 AM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Fri, May 15, 2009 at 9:14 AM, Steven Knight s...@google.com wrote: Guys, it would be a major win to get gmock landed. I'd like to keep trying here, even if not trivially small. Re: boost size. If necessary we could probably checkin only the few files actually needed (e.g. tuple.hpp, boost/config.hpp, boost/static_assert.hpp, and perhaps 10 more). maruel, is that something you'd be happier with? That seems much more acceptable to me. Especially if it doing it also sidesteps the svn:external issue. Unfortunately, it does not sidestep svn:external. What about just adding --ignore-externals to all our svn commands in gclient? I don't think anyone else uses externals, and give people's reactions, I don't think they should be. As for reducing boost to something sane, this is supposedly the reduced subset... -Albert (Seriously, svn:external really only works for such a narrow use case, and introduces so many other problems down the road when things need to change (branching+merging, local mods, etc.) that I'd really try to wave off upstream gmock from using it.) --SK On Fri, May 15, 2009 at 7:40 AM, nsylv...@chromium.org wrote: LGTM with my comment and sgk's comments. As for maruel's comment : It made me sad too. gmock seems to be a lot of troubles (svn:external, then ugly dependencies). Have we at least considered using something else? Or not using it at all? http://codereview.chromium.org/115398/diff/1/2 File third_party/boost/README.chromium (right): http://codereview.chromium.org/115398/diff/1/2#newcode3 Line 3: http://googlemock.googlecode.com/files/boost_tr1_tuple_1_36_0.zip Can you add a line that says what the license is. http://codereview.chromium.org/115398 --~--~-~--~~~---~--~~ 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: Print Settings Mockup
I think the headers and footers are confusing (everywhere). Why not just a single popup for each selection which displays a real-time view of each thing? So it might have items like: Header: Bonsai Kitten http://www.shorty.com/bonsaikitten/; Footer: Page 1 of 2 June 2, 2009 Even better if it were in-line in the box that shows the page (header above, footer below). Also better if it integrates with the margins, since the header and footer presumably take up some space, showing how that space is reclaimed might be valuable. -scott [not a UI designer, I hate almost all print panels, they almost always make what I want hard to do] On Tue, Jun 2, 2009 at 11:31 AM, Marc-Antoine Ruel mar...@chromium.org wrote: I like the mock. Glen has a veto on any UI. I think the Options is unnecessary until implemented so it can be trimmed off. The inches/mm issue is well done in Microsoft Word where you can type the units you want to use instead of being forced to use one or another. M-A On Tue, Jun 2, 2009 at 2:15 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hi guys, how are you doing? I asked Marc-Antoine about creating a mock-up of the print settings so I was looking into different printer settings user interfaces from various products. http://i44.tinypic.com/rka0c5.png The similarities between them is quite similar, but I really like what Firefox has done with how they divide their sections, as well, how the display the marginal data on the fly. They all have the following things in common: Real-Time displaying of margin changes on the paper Changing headers / footers and allow custom desc Page orientations (Landscape and Portrait) What I liked about the Microsoft products is that everything is in one page. The user will not be confused with many clicks, and everything is there. But, the sections are not divided, they all look squished. Here is my initial proposal. http://i40.tinypic.com/14ki9w0.png Only a single page, where the user will enter his format, options (if any), margins, and header/footer. The components are same as Firefox but all in one page. We should probably do a drop down to state which metric to use (inch/cm) since only America uses inches. I have brought my mother to test this, and mind you, she is very new to computers (very inexperienced), she liked the above version because everything she needs is in her finger tips and understands it better than the others. So that is my take, what do you think? I would like to send this email off to Ben/Glen/Nick since they are the UI team and may have a better UI perspective on how to do things. Let me know if its allowed to be sent to dev mailing list! Thanks! -- Mohamed Mansour --~--~-~--~~~---~--~~ 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: Print Settings Mockup
What I meant was to have a popup full of formatted choices which look like the thing you want to have. So instead of Page # of #, which is pretty abstract, Page 1 of 2. Also, instead of have six places where you can list five different things (Firefox has five, two of which are variants of each other), just have two popups each with all 48 sensible combinations. Well, OK, that's a little excessive, but maybe someone can think of a better something to constrain that. Personally, I don't think a popup with 48 items which are easy to navigate (because each item is only a small edit-distance from the previous one) is materially worse than three popups with 5 items. It's sort of like the search suggest popup, it's easy to navigate because things are constrained by what you've typed so far. Just in case it was the contents that was confusing, I mean instead of three independently-settable positions, show a formatted cell made up of the literal bits from the page, arranged as they would be shown on the output. So in your png, the single Header: popup would show a cell with the left-justified title and right-justified URL and nothing in the middle. When you pop it up the change things, you'd get the different variations to choose from, again formatted with the literal items from the page you're printing. -scott On Tue, Jun 2, 2009 at 6:28 PM, Mohamed Mansour m0.interact...@gmail.com wrote: I removed the options part to give a more visualized idea: http://i41.tinypic.com/syvz7p.png Scott, I agree headers / footers are confusing everywhere, can you elaborate on how we can do inline header/footer representation. I was thinking of the same thing, but I thought it would be confusing for the user to actually click that area, unless it is visually appealing. Ideas? -- Mohamed Mansour On Tue, Jun 2, 2009 at 3:48 PM, Scott Hess sh...@chromium.org wrote: I think the headers and footers are confusing (everywhere). Why not just a single popup for each selection which displays a real-time view of each thing? So it might have items like: Header: Bonsai Kitten http://www.shorty.com/bonsaikitten/; Footer: Page 1 of 2 June 2, 2009 Even better if it were in-line in the box that shows the page (header above, footer below). Also better if it integrates with the margins, since the header and footer presumably take up some space, showing how that space is reclaimed might be valuable. -scott [not a UI designer, I hate almost all print panels, they almost always make what I want hard to do] On Tue, Jun 2, 2009 at 11:31 AM, Marc-Antoine Ruel mar...@chromium.org wrote: I like the mock. Glen has a veto on any UI. I think the Options is unnecessary until implemented so it can be trimmed off. The inches/mm issue is well done in Microsoft Word where you can type the units you want to use instead of being forced to use one or another. M-A On Tue, Jun 2, 2009 at 2:15 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hi guys, how are you doing? I asked Marc-Antoine about creating a mock-up of the print settings so I was looking into different printer settings user interfaces from various products. http://i44.tinypic.com/rka0c5.png The similarities between them is quite similar, but I really like what Firefox has done with how they divide their sections, as well, how the display the marginal data on the fly. They all have the following things in common: Real-Time displaying of margin changes on the paper Changing headers / footers and allow custom desc Page orientations (Landscape and Portrait) What I liked about the Microsoft products is that everything is in one page. The user will not be confused with many clicks, and everything is there. But, the sections are not divided, they all look squished. Here is my initial proposal. http://i40.tinypic.com/14ki9w0.png Only a single page, where the user will enter his format, options (if any), margins, and header/footer. The components are same as Firefox but all in one page. We should probably do a drop down to state which metric to use (inch/cm) since only America uses inches. I have brought my mother to test this, and mind you, she is very new to computers (very inexperienced), she liked the above version because everything she needs is in her finger tips and understands it better than the others. So that is my take, what do you think? I would like to send this email off to Ben/Glen/Nick since they are the UI team and may have a better UI perspective on how to do things. Let me know if its allowed to be sent to dev mailing list! Thanks! -- Mohamed Mansour --~--~-~--~~~---~--~~ 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: Print Settings Mockup
Aha, perfect setup to a point I neglected to make: Lets make simple things simple, and hard things possible, here. I feel for Ian, but only a little. The reason I threw out an idea around headers and footers is not because I use them a lot, it's because I have no idea at all what my current headers and footers are set to, and I don't care, so having a half-dozen popups to control them isn't useful to me. My main complaints about browser printing is that too often bits of the content get cut off - nice page numbering doesn't help when the results are in the round file. If we can get all the output on the page in every situation, I'd be more than happy to lose headers, footers, and margin settings entirely. [Only 50% kidding, there!] -scott On Tue, Jun 2, 2009 at 11:31 PM, Ian Fette i...@chromium.org wrote: I notice you did not include page size, yet all the MSFT ones have it. I personally find this useful (my printer has both 8.5x11 and A4 loaded, and I use them both -- mostly 8.5x11, but a4 when I'm printing certain PDFs (magazine articles, forms, etc from anywhere other than the US). Maybe I'm abnormal, but I really like being able to select the page size there, rather than having to go into printer options... -ian 2009/6/2 Scott Hess sh...@chromium.org What I meant was to have a popup full of formatted choices which look like the thing you want to have. So instead of Page # of #, which is pretty abstract, Page 1 of 2. Also, instead of have six places where you can list five different things (Firefox has five, two of which are variants of each other), just have two popups each with all 48 sensible combinations. Well, OK, that's a little excessive, but maybe someone can think of a better something to constrain that. Personally, I don't think a popup with 48 items which are easy to navigate (because each item is only a small edit-distance from the previous one) is materially worse than three popups with 5 items. It's sort of like the search suggest popup, it's easy to navigate because things are constrained by what you've typed so far. Just in case it was the contents that was confusing, I mean instead of three independently-settable positions, show a formatted cell made up of the literal bits from the page, arranged as they would be shown on the output. So in your png, the single Header: popup would show a cell with the left-justified title and right-justified URL and nothing in the middle. When you pop it up the change things, you'd get the different variations to choose from, again formatted with the literal items from the page you're printing. -scott On Tue, Jun 2, 2009 at 6:28 PM, Mohamed Mansour m0.interact...@gmail.com wrote: I removed the options part to give a more visualized idea: http://i41.tinypic.com/syvz7p.png Scott, I agree headers / footers are confusing everywhere, can you elaborate on how we can do inline header/footer representation. I was thinking of the same thing, but I thought it would be confusing for the user to actually click that area, unless it is visually appealing. Ideas? -- Mohamed Mansour On Tue, Jun 2, 2009 at 3:48 PM, Scott Hess sh...@chromium.org wrote: I think the headers and footers are confusing (everywhere). Why not just a single popup for each selection which displays a real-time view of each thing? So it might have items like: Header: Bonsai Kitten http://www.shorty.com/bonsaikitten/; Footer: Page 1 of 2 June 2, 2009 Even better if it were in-line in the box that shows the page (header above, footer below). Also better if it integrates with the margins, since the header and footer presumably take up some space, showing how that space is reclaimed might be valuable. -scott [not a UI designer, I hate almost all print panels, they almost always make what I want hard to do] On Tue, Jun 2, 2009 at 11:31 AM, Marc-Antoine Ruel mar...@chromium.org wrote: I like the mock. Glen has a veto on any UI. I think the Options is unnecessary until implemented so it can be trimmed off. The inches/mm issue is well done in Microsoft Word where you can type the units you want to use instead of being forced to use one or another. M-A On Tue, Jun 2, 2009 at 2:15 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hi guys, how are you doing? I asked Marc-Antoine about creating a mock-up of the print settings so I was looking into different printer settings user interfaces from various products. http://i44.tinypic.com/rka0c5.png The similarities between them is quite similar, but I really like what Firefox has done with how they divide their sections, as well, how the display the marginal data on the fly. They all have the following things in common: Real-Time displaying of margin changes on the paper Changing headers / footers
[chromium-dev] Re: Throttling URLRequestFileJobs rate?
In my experience, taking code which assumes a low number of file descriptors and just ramping up the file descriptor limits to accommodate a particular case doesn't work out well. You end up finding out that there are three or four other edge cases which cause problems, things like O(N^2) code paths, or other places where people assume there will only be 2 to 4 file descriptors. If we were some other kind of program, like a database server, well, darn well we had better make it work. But we aren't that kind of program. -scott On Thu, Jun 11, 2009 at 5:23 PM, Jeremy Orlow jor...@google.com wrote: On Thu, Jun 11, 2009 at 5:13 PM, Stuart Morgan stuartmor...@chromium.org wrote: I'm working on getting the Intl2 test set from the page cycler up and running on the Mac, which currently crashes very quickly. It turns out that one of the test pages has hundreds of images on it, and we simultaneously make hundreds of URLRequestFileJobs to load them. Each of those uses a SharedMemory for communication, each of which requires a file descriptor. This test page generates enough requests at once that we blow out the file descriptor limit (which defaults to 256 on the Mac) and fall apart. It's tempting to say that we should just a) bump up the limit, and b) make failure to create a SharedMemory non-fatal At least some degree of b) is probably a good idea, but it's not entirely clear that we *want* all the layers involved to silently accept failure. Even if we do, local pages with more images than whatever limit we set in a) won't load correctly, and making that limit too high can get ugly. A seemingly better option would be to limit the number of simultaneous URLRequestFileJobs we will allow. Personally this seems like the only sane way to do it. Even if you bump the limits, you will hit pretty major slow downs in most OS's (last time I saw anyone try). I assume we have plumbing in place to deal with limiting the number of simultaneous URLRequestJobs we make per server; is it flexible enough that it could be extended to handle file URLs as well? If so, is there any reason that would be a bad idea? (And can someone point me to the relevant code?) -Stuart --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Crash reporting and about:crash.
about:crash is quite naturally one of our top crashers. When the Mac dev channel went out, I saw this an entered http://crbug.com/13453 , thinking that the fact that we were receiving those crashes probably meant we'd forgot to disable something before executing the handler. But, no, it's also a popular crasher on Windows. It has been suggested to me that disabling the crash reporting for this might not be appropriate. As-is, it can perhaps be used to debug whether crash-reporting is working for a particular user. So, I'm inclined to mark it WontFix, except that then searches in the Issues database won't find it. Instead I'm going to mark it Assigned to me, and describe the situation in a comment. Anyone think that's an unreasonable disposition? Thanks, 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: Crash reporting and about:crash.
On Tue, Jun 16, 2009 at 3:37 PM, Stuart Morganstuartmor...@chromium.org wrote: On Tue, Jun 16, 2009 at 2:32 PM, Scott Hesssh...@chromium.org wrote: So, I'm inclined to mark it WontFix, except that then searches in the Issues database won't find it. Do we think it's something people are actually likely to search for? The crash aggregator will still have the bug number listed for that stack, and that seems like the most likely (only?) place someone would be inspired to look for a bug about it in the first place. Is the crash aggregator's annotation stable across releases? If so, then that makes sense. I was assuming that if the fingerprint changes because we rearrange the calling sequence somehow, then maybe someone has to re-annotate things. -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: Is it possible to create branches?
Against that, I sometimes use git to manage breaking reviews up. I'm always a bit unhappy to get a review which includes one bit of complex stuff that needs a bunch of back-and-forth, and another few bits of uncontentious stuff which is easy to +1. I'd rather see those separately, so that the easy-to-review stuff can get committed and we don't have to worry about accidental changes creeping into that code. 'git rebase -i' and keeping your local commits small and targeted makes this pretty easy to do. -scott On Tue, Jun 16, 2009 at 11:07 PM, Evan Martine...@chromium.org wrote: As the team's git fanatic I feel it's my duty to tell you that git would help with this, but I agree with the commenters who say that your commits must be reviewed. The way I use it is a single git branch manages the period between start typing and think this is ready for review commit, while a series of interrelated git branches track the larger arc of your feature. Then you can get each branch reviewed and committed separately. As the team's git fanatic I'll throw in that I think git is very useful for managing an interrelated series of changes -- you can, for example, iterate on feedback on change A while still working on dependent change B. But you also need to be decently comfortable with git for that and learning is slow. On Tue, Jun 16, 2009 at 9:35 PM, Daniel Cowxdaniel.c...@gmail.com wrote: What is the recommended procedure for working on long/big features? In the past, I've always created a separate branch and then done all my work there. I then do regular integrations from trunk into my branch to ensure that that my branch doesn't drift too far out of sync with the trunk (i.e. so as to minimize the amount of merge work I have to do when I'm ready to have my branch-specific changes reviewed and merged back into the trunk). However, being that chromium is hosted on a remote SVN server which I have no control over, what is the recommended way of doing dev? I'd really like to be able to do commits of my incremental work, but without a sep branch to fiddle around with, how can I accomplish this? All input and feedback welcome. Cheers, Daniel --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
As a general observation on large development teams, infrastructure can get less love, because everyone comes to the team to work on the exciting main product, not the more mundane build infrastructure. If you have ideas on how to fix this stuff, I think it would be perfectly reasonable to put up patches that will improve things. Not as exciting as changing something that millions of people will see, perhaps, but if your request is ever to happen, SOMEONE has to do the gruntwork to make it happen... -scott On Wed, Jul 8, 2009 at 8:14 AM, nakroyoav.zilberb...@gmail.com wrote: Pawel, since i have it working on my machine (or i really could not code with chrome) i can tell you it is much more than a flag just as an example the name of chrome_dll.vcproj produces chrome.dll, but the incremental files would clash with chrome.vcproj who does the exe another example : you seem to have several 'TCMalloc_SystemAlloc' functions, which the linker can resolve if they are in a lib but would clash if linked as objects but none of this is too hard to solve, and i think is worth it i have a T5200 cpu (translated slow) and a very slow hard disk, but unless all of you have 8 cores and SSD i think we would all benefit from it especially that lately it seems more non google employees are trying to help with chrome --~--~-~--~~~---~--~~ 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: base::string16 / WebCore::String incompatibility
On Mon, Jul 13, 2009 at 10:10 AM, Jeremy Orlowjor...@chromium.org wrote: On Mon, Jul 13, 2009 at 10:08 AM, Brett Wilson bre...@chromium.org wrote: Yes, I think NullableString16 is better than passing a separate bool. Can anyone think of a better name for it? What's wrong with NullableString16? Writing string code which assumes the input is non-NULL is a really common source of bugs. We shouldn't encourage people to pass null-capable fields unless the API really really does want actual null-capable fields. This isn't something you can address generally by encapsulating it in the wrapper, because the NULL has meaning (it IS a separate bool, regardless of how you dress it up). -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: Buildbot performance issue.
If I understand right, simply serving the auto-refresh requests is substantial? At least for the main page, a reverse in accelerator mode could turn that into a constant load. [I'd offer to help, but I don't know what kind of technology we're talking about, here.] -scott On Tue, Jul 14, 2009 at 2:25 PM, Evan Martine...@chromium.org wrote: On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvainnsylv...@chromium.org wrote: The underlying problem with buildbot is the database format, which is just hundred of thousand of files on the harddrive, with no seek capability, and the fact that the webserver itself is single threaded. We currently have 63 slaves on our main waterfall. I think this is too many for what buildbot can really support. We would ideally need to split it. Can we get upstream buildbot devs involved in this discussion? It seems they ought to be able to scale better than they have. It seems to me a caching layer that only ever hit the backend every ten seconds would allow it ten seconds to grind through its computations, which should be more than sufficient, without any extra splitting up required. That is, we should (a) fix the proxy and (b) make every use the proxy. Q3: What kind of auto-refresh do we need? We used to be at 60 secs for a long time, and I changed it a couple of weeks ago to 90 secs. No one complained, so I guess this is good. Should we go even higher than that? I personally hate auto-refresh. We should make it opt-in since I doubt most users need it and it adds load. I expect many people (myself included) leave the buildbot page open in a background tab and have it continually refreshing despite not looking at it. (My other common use case: the tree is red, I start scrolling down to see what's gone wrong, and then the page refreshes out from under me and I lose where I was looking.) - Get a better machine. It's already running on a dedicated dual quad core nehalem server with 24gb of RAM and 15k rpm drives. This is absurdly powerful! It should have all the data necessary to generate the page in RAM already, no need for even touching the disks (?). --~--~-~--~~~---~--~~ 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 crash
Looks to me like the code in question wouldn't be compiled into release builds in the first place (it's under NDEBUG). So it might be problematic to match it to a known bug, since the known bugs would mostly look different. The general case of Started typing in omnibox and crashed is obviously not something which happens every time. That would certainly be noticed! -scott On Sun, Jul 19, 2009 at 2:48 PM, Thiago Farinathiago.far...@gmail.com wrote: I thought this problem was known. Thanks! On Jul 19, 6:33 pm, Peter Kasting pkast...@google.com wrote: On Sun, Jul 19, 2009 at 12:52 PM, Thiago Farina thiago.far...@gmail.comwrote: When I start typing in omnibox from Chromium (I'm debugging) the browser crashes... Since yo're debugging, you can track down what's going on. Then you can look it up in the bug database. 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: Mozilla design challenge
+1. There are tabs which I am using and will use consistently all the time (mail, calendar, things like that). For awhile on Firefox I had those pinned and turned into favicon-only tabs using extensions, and it mostly worked well. Then there are collections of on deck tabs associated with things I'm doing. These might be documentation and the like, and mostly I don't need them to be live, I just need them to be easily available, and I'd like them to be grouped together. And then there are one-off tabs like watching a video and looking at someone's photos or reading news, where I'm just going to grind through their contents and dismiss them. There may be new and interesting presentation ideas in there. For a collection of documentation tabs, I might be happy to freeze-dry them in a form which will let me easily come back to them, but which doesn't have to be live at all. Like PDFifying them, except I'd still want them to be resizable and stuff. I'd be very happy if I could do searches over the entire group, or have the browser show me snippets from other docs in the group which might reflect on the doc I'm reading, I'd be super happy if these docs were optimized such that I could flip between them super-duper fast. -scott On Tue, Jul 21, 2009 at 8:28 AM, Dean McNameede...@chromium.org wrote: I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. 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: Mozilla design challenge
I don't think it's reasonable to require the user to specify which tabs to suspend, except, perhaps, if we develop a metric for power-hungry tabs and expose that. I think there is some potential for UI geared towards particular use-cases which could be overloaded to also allow more aggressive suspend. For instance, WRT my earlier posting, I would expect my pinned tabs to be given stronger priority, and my on-deck-to-read tabs to be treated more like preloaded/rendered bookmarks. There could be other UI advantages in there, like the on-deck tabs for a particular project could group under a single tab with other UI widgets to select which document within the group. -scott On Tue, Jul 21, 2009 at 1:50 PM, Ryosuke Niwarn...@google.com wrote: Is it possible to provide an intuitive UI that allows users to choose which tabs to be suspended? For example, just like users can click buttons on taskbar to pop up a particular window, we could provide a small window that pop-in tabs / windows. And then we can suspend all windows / tab that are popped into. Ryosuke On Tue, Jul 21, 2009 at 9:32 AM, Erik Kay erik...@chromium.org wrote: You may be on to something, but I think it's more complex than this. For example bookmark systems don't work because people use them for a number of conflicting purposes (my list of things to read every day, a simple history system, a 'to read' list, a collection of links for research), which have different UI requirements. I think the same thing has happened with tabs (and there's a surprising amount of overlap). Here are the use cases I know I wind up using: - a few long running apps that need to keep running, potentially notifying me of new events (calendar, mail, chat, buildbot, etc.) - a few pages that I'm currently actively using (a screenshot from a bug I'm looking at, some reference documentation, a writely page I'm editing between compiles, etc.) - a to read list of pages that I started reading but didn't finish yet (sometimes this is a collection of related pages when researching something) - I'm sure there are others. In my use case, 80% of my tabs could easily be killed / suspended (or even hidden altogether) without any downside to me. The problem is that there isn't a way to automatically figure out which ones are which. Which ones have pending state that might be lost? (yes, some of this is bad app design, but there are many like this) Which ones do I expect to keep running all of the time because of notifications? What about that flash game that I left running in the background? Maybe we could come up with some heuristics that could detect some of this automatically, but I worry that there will be so many exceptions that it won't work. That means we'd need to come up with a better UI to express these concepts where the user chose to treat tabs differently in some explicit way. There are a number of extensions that try to do this for some specific use cases (to read lists, pinned tabs, etc.). I'm not sure that these are better than bandaids though. Erik On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee de...@chromium.org wrote: I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. 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: Proposal for adding ChangeLog files to Chromium
If reverting RELEASE_NOTE really becomes a big problem, someone could write a wrapper script to manage that. That seems more sensible than adding a manually-maintained file. I'm not really sure if the right solution would be to drop RELEASE_NOTE for items which are reverted. If they are reverted quickly, say because they broke the build, sure, but at some point the original RELEASE_NOTE and the revert RELEASE_NOTE become distinct bits of information. -scott On Wed, Jul 22, 2009 at 9:31 AM, Aaron Boodmana...@chromium.org wrote: The point about reverts is confusing RELEASE_NOTE is a good one, but I don't think it outweighs the pain of maintaining ChangeLog. On Wed, Jul 22, 2009 at 8:41 AM, Erik Kayerik...@chromium.org wrote: You can still have a single file/URL with this info for convenience. Just auto-generate it from the svn-logs. You lose the ability to edit it and make it look nice, but that could be done manually as a separate file if you'd like. Erik On Tue, Jul 21, 2009 at 11:08 PM, Anthony LaForge lafo...@google.com wrote: The main advantage that I could see for a file would be that I could point people to a single file (at any given revision) which could tell then the exact state of feature work and history. It seems to me that the RELEASE_NOTE tag would be more cumbersome. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Jul 21, 2009 at 10:27 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:22 PM, Adam Langleya...@chromium.org wrote: On Tue, Jul 21, 2009 at 9:37 PM, Anthony LaForgelafo...@google.com wrote: In order to make it easier for the community to see the changes are going on inside Chromium I'd like to propose that we add one or more ChangeLog files into our code base. The proposed usage would go something like this: I'm not saying anything that Jeremy and Adam haven't already said, just reinforcing their point in case there's any question. What you want is `git log | grep RELEASE_NOTE` git log --grep=RELEASE_NOTE will show the full log entries that match that text. PS: I've gotta be 100% on responding to threads that mention git, huh. --~--~-~--~~~---~--~~ 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: Proposal for adding ChangeLog files to Chromium
The stuff I'm implementing is important to _me_, but is it important enough to be in the release notes? Maybe we should have a tag for the issue-tracker which indicates that the issue is release-note-worthy, and we could use action on those bugs to help figure out which items are worthy of being in the release notes? Then if someone complains that their change didn't make the release notes, we can tell them how to arrange for that in the future. From there, regular bug triage activities may suffice to work it down to a reasonable volume. -scott On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForgelafo...@google.com wrote: (Warning: TPM perspective) The main problem with the current system is that it's a very time consuming process to parse through ~1000 revisions each week. Even with filter tools which parse the SVN logs and look for revisions with closed bugs, specific keywords in the logs, specific files, auto-discarding reverts, etc... that still brings us down to about 150 entries that require manual review. Of those, a good portion are not immediately clear from either the bug title or the SVN summary as to exactly what the fix was for, which requires extra detective work. Once that's done we end up re-writing/ clarifying the text. Even with all that effort I'm not 100% satisfied that we're coming up with what I'd call good results (we hit most things, but it's easy to miss lots of important stuff). Given the labor intensiveness and the so so yield, it seems like this process is an excellent candidate for applying some distributed labor and automation. I understand the resistance to ChangeLogs, but it doesn't seem unreasonable to ask committers, who have the best sense of the nature of their work, to take an extra minute to put a single line descriptive comment along side their SVN commit (and for reviewers to check it). Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA External Phone: 1-650-214-4055 On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org wrote: On Wed, Jul 22, 2009 at 4:52 PM, Anthony LaForgelafo...@google.com wrote: Ok, I know when to stop pushing, that's reasonable and appreciated feedback. So shifting gears, it seems like everyone would be comfortable with using RELEASE_NOTES tag in SVN comments. Any thoughts from the group on best practices for using that the tag gets used effectively? Who said everyone was comfortable? I'm probably not going to bother writing RELEASE_NOTES pretty much ever. (In exchange, I frequently edit our release notes to be more complete or accurate.) If the goal is pointing people at something that lists all changes, we can do it with a script. If the goal is making the release notes for releases better, a ChangeLog wouldn't have helped you anyway. I'm not sure there is much advantage in modifications to the current system -- even if RELEASE_NOTES get written sometimes, you're still going to need to parse all the rest of the changes and decide what to say. * When reverting, the log is reverted as well: Actually, I've never been too sure about reverting in WebKit: does one revert the ChangeLog file too or add another ChangeLog entry at the top describing the revert? Unless my memory is faulty, according to the Apple folks who have guided me through reverts (in particular, bdash), you add a new entry at top saying you're reverting; you never remove the old CL entry. But, the commit message should match the change message on the code review, so our reviewers can already critique it. So, this would appear to be a review issue rather than a technological issue. Yes, and if reviewers aren't complaining about poor descriptions here, they should be. 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: Proposal for adding ChangeLog files to Chromium
BTW: if people aren't annotating their CL's with bugs, they SURELY won't annotate them with release notes or update the change log. Just aiming for the path of least resistance, here. -scott On Wed, Jul 22, 2009 at 11:46 AM, Scott Hesssh...@chromium.org wrote: The stuff I'm implementing is important to _me_, but is it important enough to be in the release notes? Maybe we should have a tag for the issue-tracker which indicates that the issue is release-note-worthy, and we could use action on those bugs to help figure out which items are worthy of being in the release notes? Then if someone complains that their change didn't make the release notes, we can tell them how to arrange for that in the future. From there, regular bug triage activities may suffice to work it down to a reasonable volume. -scott On Wed, Jul 22, 2009 at 11:33 AM, Anthony LaForgelafo...@google.com wrote: (Warning: TPM perspective) The main problem with the current system is that it's a very time consuming process to parse through ~1000 revisions each week. Even with filter tools which parse the SVN logs and look for revisions with closed bugs, specific keywords in the logs, specific files, auto-discarding reverts, etc... that still brings us down to about 150 entries that require manual review. Of those, a good portion are not immediately clear from either the bug title or the SVN summary as to exactly what the fix was for, which requires extra detective work. Once that's done we end up re-writing/ clarifying the text. Even with all that effort I'm not 100% satisfied that we're coming up with what I'd call good results (we hit most things, but it's easy to miss lots of important stuff). Given the labor intensiveness and the so so yield, it seems like this process is an excellent candidate for applying some distributed labor and automation. I understand the resistance to ChangeLogs, but it doesn't seem unreasonable to ask committers, who have the best sense of the nature of their work, to take an extra minute to put a single line descriptive comment along side their SVN commit (and for reviewers to check it). Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA External Phone: 1-650-214-4055 On Wed, Jul 22, 2009 at 10:09 AM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 22, 2009 at 10:03 AM, Adam Langley a...@chromium.org wrote: On Wed, Jul 22, 2009 at 4:52 PM, Anthony LaForgelafo...@google.com wrote: Ok, I know when to stop pushing, that's reasonable and appreciated feedback. So shifting gears, it seems like everyone would be comfortable with using RELEASE_NOTES tag in SVN comments. Any thoughts from the group on best practices for using that the tag gets used effectively? Who said everyone was comfortable? I'm probably not going to bother writing RELEASE_NOTES pretty much ever. (In exchange, I frequently edit our release notes to be more complete or accurate.) If the goal is pointing people at something that lists all changes, we can do it with a script. If the goal is making the release notes for releases better, a ChangeLog wouldn't have helped you anyway. I'm not sure there is much advantage in modifications to the current system -- even if RELEASE_NOTES get written sometimes, you're still going to need to parse all the rest of the changes and decide what to say. * When reverting, the log is reverted as well: Actually, I've never been too sure about reverting in WebKit: does one revert the ChangeLog file too or add another ChangeLog entry at the top describing the revert? Unless my memory is faulty, according to the Apple folks who have guided me through reverts (in particular, bdash), you add a new entry at top saying you're reverting; you never remove the old CL entry. But, the commit message should match the change message on the code review, so our reviewers can already critique it. So, this would appear to be a review issue rather than a technological issue. Yes, and if reviewers aren't complaining about poor descriptions here, they should be. 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 9:01 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Thu, Jul 23, 2009 at 8:53 AM, Evan Martin e...@chromium.org wrote: On Thu, Jul 23, 2009 at 7:47 AM, Nicolas Sylvainnsylv...@chromium.org wrote: gclient has nothing to do with this case. svn update src/ was trying to add a directory called src/bleh, but src/bleh already existed, so svn update failed. Sorry to back-seat drive, but can't you do something like svn status | xargs rm -rf before syncing? svn status does not show files that are svn:ignore'd, like all generated files should be. Hmm. In creating a clean client, would it make sense to delete all files which exist and are svn:ignore'd? Just as a matter of course? -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: Cross-compiling on ARM
Would it be possible/reasonable to use distcc plus a farm of cross-compiler machines to let you do faster self-hosted builds? It's not the right solution, but in the past I've found it to sometimes be an easier path to take in the short term while you're working on fixing all the little problems. -scott On Fri, Aug 21, 2009 at 12:54 PM, Antoine Labourpi...@chromium.org wrote: There's growing interest from several parties in getting Chrome to cross-compile onto linux/ARM. Let's make sure everyone is on the same page so that we don't duplicate efforts. I understand that Joel Stanley, Dean McNamee and Lei Zhang have already been doing a lot of work towards that. There's a wiki page there: http://code.google.com/p/chromium/wiki/LinuxChromiumArm I've identified a few missing pieces to get a full version of chrome - there may be others. They are mostly build infrastructure issues: - v8 snapshotting needs to be disabled currently, we'd like to enable it. That means executing mksnapshot as a target executable, either through qemu or directly on device, i.e. the infrastructure to run a target program. - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's going to look at the host for them. If your target distribution matches your host maybe you're fine, but it may not work at all, so it'd would be good to extract that and get a way to specify the dependencies explicitly. - The chrome os build relies on the protobuf compiler. The current build system builds it as a target executable, so we either need to run in qemu / on device it as above, or change the build system to understand target vs host executables. I wanted to double check if anyone was working on any of that, or if anyone has good ideas about how to achieve each of them. Please speak up ! Antoine --~--~-~--~~~---~--~~ 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: found corrupted db
fts uses what is effectively a form of compression for the index, so most any stream of data will decode at some level. My bet in this case is that the segdir is referencing a segment block which doesn't exist, so someone inappropriately tries to decode NULL. From what I recall of debugging such things in Gears, that case does tend to go along with being able to detect via PRAGMA integrity_check, because it happens when a page containing SQLite metadata has been corrupted. For instance, if an interior node of a b-tree is replaced by a random other page (perhaps a node was split and the target page did not get overwritten due to lying disk cache). What's puzzling is how I know this, but we still see the crash. I'm pretty sure we fixed something or other around this. That was a year or more back, though, so maybe I'm not remembering right. Regardless, best-case scenario for something like this would be someone throwing SQLITE_CORRUPT and higher-level code doing something like poisoning (*) or deletion or mount some sort of salvage operation. -scott (*) This is what Gears did, it marked the database unusable in a way that would be recognized by all outstanding handles, and bumped the version in the mapping so that on next open a fresh new database would be created. Probably not appropriate in this case. On Wed, Sep 9, 2009 at 6:34 PM, cpuc...@chromium.org wrote: Larson gave me a profile that can consistently crash windows chrome (beta). I haven't tried loading the profile myself but we have crash dumps from it. It crashes in: 0x69db6e5d [chrome.dll - fts2.c:453] getVarint --- access violation at 0x0 0x69db6ef0 [chrome.dll - fts2.c:468] getVarint32 0x69dbacbf [chrome.dll - fts2.c:5078] leavesReaderDataBytes 0x69dbb1d7 [chrome.dll - fts2.c:5407] segmentMerge 0x69dbb0f9 [chrome.dll - fts2.c:5359] segdirNextIndex 0x69dbba45 [chrome.dll - fts2.c:5932] writeZeroSegment 0x69dbbbf5 [chrome.dll - fts2.c:5966] flushPendingTerms 0x69dbbc3c [chrome.dll - fts2.c:5984] initPendingTerms 0x69dba135 [chrome.dll - fts2.c:4050] index_delete 0x69dbbca4 [chrome.dll - fts2.c:6005] fulltextUpdate 0x69dc284a [chrome.dll - vdbe.c:4945] sqlite3VdbeExec 0x69da170f [chrome.dll - vdbeapi.c:476] sqlite3Step 0x69da1856 [chrome.dll - vdbeapi.c:544] sqlite3_step 0x6a09c1ab [chrome.dll - text_database.cc:290] history::TextDatabase::DeletePageData(..) 0x6a07d145 [chrome.dll - text_database_manager.cc:338] history::TextDatabaseManager::DeletePageData(...) 0x6a081c4a [chrome.dll - expire_history_backend.cc:366] history::ExpireHistoryBackend::DeleteVisitRelatedInfo(..); 0x6a082496 [chrome.dll - expire_history_backend.cc:592] history::ExpireHistoryBackend::ArchiveSomeOldHistory(..) 0x6a0822fa [chrome.dll - expire_history_backend.cc:553] history::ExpireHistoryBackend::DoArchiveIteration() 0x69ee8de1 [chrome.dll - message_loop.cc:313] MessageLoop::RunTask (Task *) The novel part is that sqlite can detect corruption: D:\testsqlite3.exe zzz\User Data\Default\History Index 2009-09 SQLite version 3.6.17 sqlite PRAGMA integrity_check; wrong # of entries in index info_time --~--~-~--~~~---~--~~ 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: Enabling --disable-hang-monitor for new windows when Chrome is already running
Another alternative would be a ping type call to say I'm unresponsive, and I mean it. Like a watchdog timer. The plug-in could still effectively be hung, but at least it has to have things together enough to call the watchdog. -scott On Fri, Sep 11, 2009 at 3:37 PM, John Abd-El-Malek j...@chromium.org wrote: For reference, something similar is done for popups: void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled); void NPN_PopPopupsEnabledState(NPP instance); Perhaps we can do the same thing here: void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled); void NPN_Pop PluginHangDetectorState(NPP instance); On Fri, Sep 11, 2009 at 2:46 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 5:24 PM, Darin Fisher da...@chromium.org wrote: I think that is a reasonable feature request. It would be nice however if there were some way to know when to restore the old behavior. Unfortunately, Chrome won't know when you are done. I was thinking something like this for my case (substitute appropriate method names): NPN_SetPluginWarning(false); processSocketMessages(); NPN_SetPluginWarning(true); and trying to call NPN_SetPluginWarning where you didn't request that permission in the manifest would fail. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ 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: Enabling --disable-hang-monitor for new windows when Chrome is already running
Since the hang dialog comes up in the future after you've shifted your focus elsewhere, if we did any sort of user interaction at all I'd rather the plug-in could say Ask user for permission to disable hang monitor for this context right now. The plug-in hits the breakpoint, calls that function, and on successful return falls into the blocking mode. The browser could cache the response so that the user only has to be asked once per tab (or browser session). -scott On Fri, Sep 11, 2009 at 3:50 PM, Mike Mammarella m...@chromium.org wrote: Perhaps rather than disabling the hang monitor altogether what that could do is add an additional option to the warning the first time: don't notify me again. If you click that, then it will disable the hang monitor until the plugin is once again responsive and then becomes unresponsive again. (Or maybe even until the plugin terminates.) That avoids the need to have a plugin be trusted in any way, but keeps the UI simple unless the plugin knows it wants to display it and get debugged. You'd still have to deal with the dialog once but after that it would get out of your way. --Mike On Fri, Sep 11, 2009 at 3:41 PM, Scott Hess sh...@chromium.org wrote: Another alternative would be a ping type call to say I'm unresponsive, and I mean it. Like a watchdog timer. The plug-in could still effectively be hung, but at least it has to have things together enough to call the watchdog. -scott On Fri, Sep 11, 2009 at 3:37 PM, John Abd-El-Malek j...@chromium.org wrote: For reference, something similar is done for popups: void NPN_PushPopupsEnabledState(NPP instance, NPBool enabled); void NPN_PopPopupsEnabledState(NPP instance); Perhaps we can do the same thing here: void NPN_PushPluginHangDetectorState(NPP instance, NPBool enabled); void NPN_Pop PluginHangDetectorState(NPP instance); On Fri, Sep 11, 2009 at 2:46 PM, John Tamplin j...@google.com wrote: On Fri, Sep 11, 2009 at 5:24 PM, Darin Fisher da...@chromium.org wrote: I think that is a reasonable feature request. It would be nice however if there were some way to know when to restore the old behavior. Unfortunately, Chrome won't know when you are done. I was thinking something like this for my case (substitute appropriate method names): NPN_SetPluginWarning(false); processSocketMessages(); NPN_SetPluginWarning(true); and trying to call NPN_SetPluginWarning where you didn't request that permission in the manifest would fail. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ 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 Wed, Sep 16, 2009 at 1:07 PM, Mike Mammarella m...@chromium.org wrote: On Wed, Sep 16, 2009 at 12:59 PM, Evan Martin e...@chromium.org wrote: On Wed, Sep 16, 2009 at 12:44 PM, spotrh spo...@gmail.com wrote: On 09/16/2009 02:23 PM, Evan Martin wrote: What is the error message? I wonder if there is something Linux-specific where we're getting an error code that is harmless. (We've had a lot of that in code that checks errno where the value differs between Linux and OS X.) User says it reports: [5070:5093:8302515214:FATAL:/mnt/chromium/rpmbuild/BUILD/chromium-20090910svn25958/src/chrome/common/sqlite_utils.cc(52)] Check failed: false. sqlite fatal error 11 Hm, that doesn't sound good! #define SQLITE_CORRUPT 11 /* The database disk image is malformed */ FYI, I'm almost finished updating our (locally patched) SQLite to version 3.6.18 instead of 3.6.1 that we have now; apparently 3.6.18 handles corruption much better than 3.6.1 does. (I am holding off checking it in until I can run it through all the tests I can find to make sure something won't break, but other than that it's ready.) I don't know what effect it might have on this issue, but hopefully it will be a good effect... To be clear, newer SQLite handles corruption much better in the sense that it detects it and throws SQLITE_CORRUPT in cases which previous code did not detect. In general, if the older code throws SQLITE_CORRUPT, the newer code will also throw SQLITE_CORRUPT. -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: 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: OSX cocoa_test_helper.mm and the like in browser.lib.
Why is cocoa_test_helper.mm listed in the browser library? This results in the class being linked into Google Chrome Framework (meaning it ships). Doesn't seem appropriate to me. This came up because I have some helper code I was listing in the unit_tests section of chrome.gyp. Since it's in browser/cocoa/, it will already be excluded from other platforms correctly. I was wondering about test_support_unit or test_support_common, but AFAICT since the file is in chrome/browser/, that would not be appropriate for my file. [cocoa_test_helper.mm doesn't have any dependencies w/in browser, that I can see, so it could maybe move there.] Any thoughts? -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: XP Perf page load regression on morejs and moz page cyclers
I think we should be willing to take a temporary performance hit on the dev channel in the interests of generating data which will eventually improve stability. Could we set jemalloc on selected renderer processes? I realize that wouldn't necessarily only impact the target domains, but it might be better than making the change global. -scott On Thu, Oct 1, 2009 at 10:47 AM, Jim Roskind j...@chromium.org wrote: I'm quite sure it is jemalloc. I failed miserably by not over-communicating this checkin. My apologies to all that I have inconvenience. We have just this week identified a number of misteps in our use of TCMalloc. I think that we can eventually reach an excellent result with TCMalloc... and we had a few fixes... but we also wanted to be able to talk more precisely about how things contrast with jemalloc (as folks ask us why we're looking so intently at tcmalloc). If folks are cool with it, it might be interesting to push the dev build with this in place. JEMalloc appears to be very conservative in its memory usage, but doesn't get the speed we've seen with TCMalloc. We can already see some specific areas where the current (checked in) incarnation of TCMalloc stumbles (example: today, TCMalloc never decommits memory in the browser process... yeah... that's just a bug... but I was wondering how much it hurt... and a switch to jemalloc would instantly provide a temporary fix). It may be interesting to see the response on the dev channel to this temporary change. Side benefits include some feedback on crashers, as each allocator illuminates a different set of corruption problems (if we have any :-) ). Do other folks agree it would be interesting to see a dev build go out with this in place?? Thanks, Jim On Thu, Oct 1, 2009 at 8:46 AM, Mike Belshe mbel...@google.com wrote: Probably caused by jemalloc. Jim was experimenting with the idea of getting some dev-channel data from using jemalloc as opposed to tcmalloc. I'm not surprised there was a perf delta, but I am surprised by how much. The DOM benchmark in this test dropped by 8%. Several other benchmarks took similar hits. http://build.chromium.org/buildbot/perf/vista-release-dual-core/dom_perf/report.html?history=150 http://build.chromium.org/buildbot/perf/xp-release-single-core/bloat-http/report.html?history=150 But the memory test does use about 10% less RAM with jemalloc (as predicted): http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150 And almost all memory tests got better: http://build.chromium.org/buildbot/perf/dashboard/overview.html?graph=vm_peak_b So: tcmalloc == faster; jemalloc == smaller. We knew this. I think we should probably back out jemalloc - the perf hit is non-trivial, and the memory we can improve with other, upcoming tcmalloc work. Jim - how badly do you want jemalloc dev-channel data? I'm not sure it will buy us a lot other than what we already know. Mike On Thu, Oct 1, 2009 at 8:29 AM, Darin Fisher da...@chromium.org wrote: Note: my change was reverted for other reasons.-Darin On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.orgwrote: Hey everyone, A performance regression has appeared on the XP Perf bot in the morejs page cycler. Along with turning XP Perf red, the perf regression system notified me via email (forwarded below). The page load regression is about 30ms. There's a similar regression in the moz page cycler. Here's a link to the XP Perf dashboard to see the morejs regression: http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50 The interesting revisions between r27704 and r27710 are: r27705 - darin - Move various methods from glue to api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705 r27708 - jar - Set JEMalloc as the default allocator (instead of TCMalloc).http://src.chromium.org/viewvc/chrome?view=revrevision=27708 r27710 - thestig - Disable CheckSvnModifiedDirectories for now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710 @jar: Not meaning to pick on you, but my guess is the JEMalloc change is the cause. Did you expect a page load regression from your change? PS If you haven't heard of this perf regression system, don't worry -- it's a new tool in Chromium's toolbox. Email and docs describing it will be sent soon. Thanks, Chase -- Forwarded message -- From: build...@chromium.org Date: Thu, Oct 1, 2009 at 7:15 AM Subject: buildbot failure in Chromium on XP Perf, revision 27719 To: c...@google.com http://build.chromium.org/buildbot/waterfall/ Perf alert on XP Perf: page_cycler_morejs http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 Revision: 27719 Blame list: ida...@google.com XP Perf Build 9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 svnkill
[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers
On Thu, Oct 1, 2009 at 11:32 AM, Mike Belshe mbel...@google.com wrote: On Thu, Oct 1, 2009 at 11:27 AM, Scott Hess sh...@chromium.org wrote: Could we set jemalloc on selected renderer processes? I realize that wouldn't necessarily only impact the target domains, but it might be better than making the change global. It can be set by a per-process environment variable. So... yes, this could be done. Mix-and-match allocators might be a little strange for anything other than debugging/testing. I was thinking enabling for the gmail renderer (and whoever gets stuck in that process) might be more useful than enabling for everyone - but obviously we'd need ways to identify the source of any uploaded data. That said, being able to enable alternate malloc libraries in the browser process might have relatively low performance costs compared to the value of the data generated. I don't mean to imply that browser-process performance is not important, but rather that race conditions and double-frees and the like are much more dangerous there. Also, interpreting the data would probably be easier (renderer data and browser results would be internally consistent). -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: Paper about DRAM error rates
Our use of exclusive locking and page-cache preloading may open us up more to this kind of shenanigans. Basically SQLite will trust those pages which we faulted into memory days ago. We could mitigate against that somewhat, but this problem reaches into areas we cannot materially impact, such as filesystem caches. And don't even begin to imagine that there are not similar issues with commodity disk drives and controllers. That said, I don't think this is an incremental addition of any kind. I've pointed it out before, there are things in the woods which corrupt databases. We could MAYBE reduce occurrences to a suitable minimum using check-summing or something of the sort, but in the end we still have to detect corruption and decide what course to take from there. -scott On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote: On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote: I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? Many sqlite calls can return sqlite_corrupt. For example a query or an insert We just check for error codes 1 to 26 with 5 or 6 of them being serious error such as sqlite_corrupt I am sure that random bit flip in memory and on disk is the cause of some crashes, this is probably the 'limit' factor of how low the crash rate of a perfect program deployed in millions of computers can go. The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. Even if only a small fraction of these are harmful, spread over millions of users that's a lot of corruption. But I am unsure how to calculate, for example a random bit flip on the backingstores, which add to at least 10M on most machines does not hurt, or in the middle of a cache entry, or in the data part of some structure. I imagine there's no way we can know when corruption happen in steady-state and the next query leads to some other browser memory (or another database) getting corrupted? On Tue, Oct 6, 2009 at 3:58 PM, Huan Ren hu...@google.com wrote: It will be helpful to get our own measurement on database failures. Carlos just added something like that. Huan On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote: Saw this on slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf The conclusion is an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit. On my machine the browser process is usually 100MB, so that averages out to 176 to 493 error per year, with those numbers having big variance depending on the machine. Since most users don't have ECC, which means this will lead to corruption. Sqlite is a heavy user of memory, so even if it's 1/4 of the 100MB, that means we'll see an average of 40-120 errors naturally because of faulty DIMMs. Given that sqlite corruption means (repeated) crashing of the browser process, it seems this data heavily suggests we should separate sqlite code into a separate process. The IPC overhead is negligible compared to disk access. My hunch is that the complexity is also not that high, since the code that deals with it is already asynchronous since we don't use sqlite on the UI/IO threads. What do others think? --~--~-~--~~~---~--~~ 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: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 5:09 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote: On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote: I'm not sure how Carlos is doing it? Will we know if something is corrupt just on load/save? Many sqlite calls can return sqlite_corrupt. For example a query or an insert We just check for error codes 1 to 26 with 5 or 6 of them being serious error such as sqlite_corrupt I am sure that random bit flip in memory and on disk is the cause of some crashes, this is probably the 'limit' factor of how low the crash rate of a perfect program deployed in millions of computers can go. The point I was trying to make is that the 'limit' factor as you put it is proportional to memory usage. Given our large memory consumption in the browser process, the numbers from the paper imply dozens of corruptions just in sqlite memory per user. Even if only a small fraction of these are harmful, spread over millions of users that's a lot of corruption. For what it's worth: This makes sense to me. It seems like pulling SQLite into its own process would be helpful for the reasons you laid out. I wonder if the only reason no one else has chimed in on this thread is that no one wants to have to implement it. :-) I don't understand how this paper makes it very useful to pull SQLite into a separate process. I can see how it would make it useful to minimize how much in-memory data SQLite keeps, regardless of where SQLite lives. I can also see how this effect would increase our incidence of memory stompers, but in a lot of cases it just won't matter. If it corrupts a piece of data which we pass to SQLite, passing it direct or via IPC won't change that. Most memory stompers won't manifest by hitting SQLite anyhow, unless there's reason to believe specific bits will be munged. -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: Paper about DRAM error rates
On Tue, Oct 6, 2009 at 5:24 PM, Dan Kegel d...@kegel.com wrote: 1) zfs was right: checksums are a good idea. Can we add them to sqlite? I believe so, but I'm still working through the details. And by working I mean thinking. The challenge is in finding places to tuck things away where they won't break compatibility. I _think_ we could tuck page-level checksums into unused space w/in the page (and arrange for unused space to exist). Then row-level checksums to handle overflow pages (which I don't think allow the same unused-space trick). I haven't dug in to figure out the free list. Note, though, that checksums only get you so far, the real challenge might be in finding all the places to check the checksums. Checking them at read time is unsatisfactory, given this research! -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: detecting tabs using a lot of CPU?
You could replace the favicon with a spinning clock or something. It might also be interesting to provide indicators for high memory usage (or perhaps if the recent memory growth is high), or IPC issues. Then again, many users might prefer not to have their tabs attracting attention needlessly. I mostly don't care whether a tab is using lots of CPU. -scott On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy g...@chromium.org wrote: Something like yes! Maybe not a dialog, as I use things that peg my CPU (games) somewhat frequently. One idea we toyed with was marking such tabs as 'on fire' (icon or color), so at least there was a visual indication. I think this would be a good starting point before anything more obtrusive like a dialog or bar. On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] How expensive is setting a crash key for breakpad?
In fixing a Mac bug, I recently added a layer to intercept -[NSApplication sendAction:to:from:] and make sure a certain message wasn't forwarded if the target was known to be freed. Since this is sort of a core function for event dispatch, now we're seeing crashdumps with my new method on the stack. I don't think it's a new problem. In researching it, I realize that it maybe gives us a hook for tracking down some very random browser crashers we see, where there's a stack of generic Cocoa methods. I could register a crash key which would report the action that is being sent, and the class of the sender. If there is anything interesting which could be derived about the potentially-freed target, that could be reported, too. AFAICT, it's a matter of calling SetCrashKeyValue() and ClearCrashKeyValue() at the appropriate spots. AFAICT, we don't dynamically call SetCrashKeyValue() anywhere, we mostly just call it a couple times at startup. Is the approach I suggest feasible? -scott PS: The kind of backtrace I'm speaking of are those associated with http://crbug.com/13111 . They used to look like: 0x9518c688 [libobjc.A.dylib+ 0x00015688] objc_msgSend 0x953fddcb [AppKit + 0x00111dcb] -[NSControl sendAction:to:] 0x953fdc51 [AppKit + 0x00111c51] -[NSCell _sendActionFrom:] 0x953fd2aa [AppKit + 0x001112aa] -[NSCell trackMouse:inRect:ofView:untilMouseUp:] 0x953fcafd [AppKit + 0x00110afd] -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] 0x953fc3b7 [AppKit + 0x001103b7] -[NSControl mouseDown:] 0x953faaf6 [AppKit + 0x0010eaf6] -[NSWindow sendEvent:] 0x953c76a4 [AppKit + 0x000db6a4] -[NSApplication sendEvent:] 0x95324fe6 [AppKit + 0x00038fe6] -[NSApplication run] 0x02517eb2 [Google Chrome Framework- message_pump_mac.mm:482] base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) 0x02517f97 [Google Chrome Framework- message_pump_mac.mm:146] base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) 0x025148f3 [Google Chrome Framework- message_loop.cc:199] MessageLoop::Run() 0x0218a0da [Google Chrome Framework- browser_main.cc:152] BrowserMain(MainFunctionParams const) 0x020cadcf [Google Chrome Framework- chrome_dll_main.cc:603] ChromeMain 0x1fc5 [Google Chrome + 0x0fc5] Now they'll have a line like this at the top: 0x000ec978 [Google Chrome Framework- chrome_application_mac.mm:83] -[CrApplication sendAction:to:from:] That's where I can hook in to record a bit for breakpad. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] My Linux experience got better with a new version of flash.
Of course, it didn't ACTUALLY get better until I got annoyed enough to figure out how to upgrade my system's version of flash. I went out and followed web instructions for apt-removing the older version and installed the newer deb from Adobe. Of course, that didn't fix it either. Eventually it bugged me enough to do something else, so I figured Maybe about:plugins?, and it gave me a page, and I noticed that I had two flash plug-ins. Didn't tell me where they were coming from, though. Eventually I found the second plug-in in .mozilla/plugins. Being confident in my ability to restore Firefox from the ground up, I nuked it from orbit. Given the history of ways to install things on Linux, I wonder if it wouldn't be worth having additional information for that platform about stuff like this. about:plugins tells me the filename to look for, but not where to look. And about:plugins isn't very discoverable, even if you know that you should be looking for something - I think that if we see two versions of libflashplayer.so, we can be pretty sure something is wrong. [And I'm getting tired of not being able to use C-n in my compose windows. I had to dismiss four New Windows from just this email. I'm sure printing support will make me additionally happy on this front :-). Yes, I'll go file a bug or something.] -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: My Linux experience got better with a new version of flash.
On Fri, Oct 9, 2009 at 8:55 AM, Evan Martin e...@chromium.org wrote: We de-duplicate multiple instances of the same file. If you have multiple copies of the same file we attempt to prioritize non-nspluginwrapper versions over nspluginwrapper-wrapped versions. After that, the list of plugins displayed is not the list of plugins that are *loaded* -- we only actually plugins in a per-plugin process, and only the first match, so having multiple libflashplayer.so should be fine. Hmm. Maybe I should try to re-create my setup, then. When I had the 10.x player in /usr/whatever and the 7.x player in ~/.mozilla/plugins (*), things like Google Finance would tell me to get flash to get the interactive graphs, and I'd get a LOT of plug-in-crashed infobars. When I removed the ~/.mozilla/plugins .so and restarted Chrome, Google Finance started showing me the whizzy graphs. (*) libflashplayer.so dated 2004-08-03. Yeah, I've surely been haxor'ed. [I don't know how relevant it is, but I used many versions of Firefox for years on this system, and have never felt excessively held back by flash. Don't get me wrong, less reliable than I'd have liked, but I cobbled together the system out of individual atoms found in my backyard, so I expected it to lack polish.] -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: How expensive is setting a crash key for breakpad?
http://codereview.chromium.org/269039 ... On Wed, Oct 7, 2009 at 11:13 PM, Jeremy Moskovich jer...@chromium.org wrote: That sounds like a great idea!! Note that there are some limits on crash keys, here's the relevant quote from breakpad.h: // User defined key and value string storage. Generally this is used // to configure Breakpad's internal operation, such as whether the // crash_sender should prompt the user, or the filesystem location for // the minidump file. See Breakpad.h for some parameters that can be // set. Anything longer than 255 bytes will be truncated. Note that // the string is converted to UTF8 before truncation, so any multibyte // character that straddles the 255(256 - 1 for terminator) byte limit // will be mangled. // // A maximum number of 64 key/value pairs are supported. An assert() // will fire if more than this number are set. Unfortunately, right // now, the same dictionary is used for both Breakpad's parameters AND // the Upload parameters. If you look at the code that logs URLs you'll note that a URL is split over several keys. Best regards, Jeremy On Wed, Oct 7, 2009 at 10:48 PM, Scott Hess sh...@chromium.org wrote: In fixing a Mac bug, I recently added a layer to intercept -[NSApplication sendAction:to:from:] and make sure a certain message wasn't forwarded if the target was known to be freed. Since this is sort of a core function for event dispatch, now we're seeing crashdumps with my new method on the stack. I don't think it's a new problem. In researching it, I realize that it maybe gives us a hook for tracking down some very random browser crashers we see, where there's a stack of generic Cocoa methods. I could register a crash key which would report the action that is being sent, and the class of the sender. If there is anything interesting which could be derived about the potentially-freed target, that could be reported, too. AFAICT, it's a matter of calling SetCrashKeyValue() and ClearCrashKeyValue() at the appropriate spots. AFAICT, we don't dynamically call SetCrashKeyValue() anywhere, we mostly just call it a couple times at startup. Is the approach I suggest feasible? -scott PS: The kind of backtrace I'm speaking of are those associated with http://crbug.com/13111 . They used to look like: 0x9518c688 [libobjc.A.dylib + 0x00015688] objc_msgSend 0x953fddcb [AppKit + 0x00111dcb] -[NSControl sendAction:to:] 0x953fdc51 [AppKit + 0x00111c51] -[NSCell _sendActionFrom:] 0x953fd2aa [AppKit + 0x001112aa] -[NSCell trackMouse:inRect:ofView:untilMouseUp:] 0x953fcafd [AppKit + 0x00110afd] -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] 0x953fc3b7 [AppKit + 0x001103b7] -[NSControl mouseDown:] 0x953faaf6 [AppKit + 0x0010eaf6] -[NSWindow sendEvent:] 0x953c76a4 [AppKit + 0x000db6a4] -[NSApplication sendEvent:] 0x95324fe6 [AppKit + 0x00038fe6] -[NSApplication run] 0x02517eb2 [Google Chrome Framework - message_pump_mac.mm:482] base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) 0x02517f97 [Google Chrome Framework - message_pump_mac.mm:146] base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) 0x025148f3 [Google Chrome Framework - message_loop.cc:199] MessageLoop::Run() 0x0218a0da [Google Chrome Framework - browser_main.cc:152] BrowserMain(MainFunctionParams const) 0x020cadcf [Google Chrome Framework - chrome_dll_main.cc:603] ChromeMain 0x1fc5 [Google Chrome + 0x0fc5] Now they'll have a line like this at the top: 0x000ec978 [Google Chrome Framework - chrome_application_mac.mm:83] -[CrApplication sendAction:to:from:] That's where I can hook in to record a bit for breakpad. --~--~-~--~~~---~--~~ 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: Who owns crash...@chromium.org and why is there so many updates from it?
Does this relate to receiving crashbot emails adding Crash labels on closed-out bugs where the backtrace doesn't apparently have any relevance to the original backtraces involved with the bug? I've gotten a couple of these in the past week. -scott [Unfortunately, I don't remember the earlier one, the latter is http://crbug.com/13113 ] On Tue, Oct 6, 2009 at 9:58 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 8:57 PM, Anthony LaForge lafo...@chromium.org wrote: The short of it: People manually associated bugs in http:crash My tool creates its own map of signatures and for whatever reason that bug is on all of them It goes through each aggregate signature and updates the status of the bug (which is a flash crasher) It's made much worse because we are dealing w/ crashes that don't have symbols and cannot be aggregated... What went wrong: The limiting function (seeing if crash-VERSION) was applied does not happen for priority updates. This was actually intentional since we start looking at crash data early on. However this should no longer be needed since we wait for enough data that priority should no longer be shifting. What can be done about it? I will put a limiter on setting the priority Thanks. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 8:46 PM, Patrick Johnson patr...@chromium.org wrote: John's question is about why it's generating so many issue updates. Patrick On Tue, Oct 6, 2009 at 8:41 PM, Anthony LaForge lafo...@chromium.org wrote: It's the role account that manages crashes and crash related bugs. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 7:26 PM, Patrick Johnson patr...@chromium.org wrote: [+laforge] On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek j...@chromium.org wrote: I got 21 emails in the last day for http://code.google.com/p/chromium/issues/detail?id=20915 --~--~-~--~~~---~--~~ 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: Buildbot upgrade
On Mon, Oct 12, 2009 at 7:44 AM, Nicolas Sylvain nsylv...@chromium.org wrote: On Sun, Oct 11, 2009 at 11:33 AM, Jeremy Orlow jor...@chromium.org wrote: Is there documentation anywhere for all the parameters you can feed into the buildbot webpage? If not, a cheat sheet would be really helpful. the help link at the bottom has most of them http://build.chromium.org/buildbot/waterfall/waterfall/help Note that the help link at the bottom is at the bottom of the console page. That had me confused this morning :-). -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: Spellchecker and memory-mapped dicts
On Linux what about mmap() and then madvise() with MADV_WILLNEED? [or posix_fadvise() with POSIX_FADV_WILLNEED on the file descriptor). -scott On Thu, Oct 22, 2009 at 2:06 PM, Steve Vandebogart vand...@chromium.org wrote: If you plan to read the entire file, mmap()ing it, then faulting it in will be slower than read()ing it, at least in some Linux versions. I never pinned down exactly why, but I think the kernel read-ahead mechanism works slightly differently. -- Steve On Thu, Oct 22, 2009 at 2:02 PM, Chris Evans cev...@chromium.org wrote: There's also option 3) Pre-fault the mmap()ed region in the file thread upon dictionary initialization. On Linux at least, that may give you better behaviour than malloc() + read() in the event of memory pressure. Cheers Chris On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade est...@chromium.org wrote: Hi all, At its last meeting the jank task force discussed improving responsiveness of the spellchecker but we didn't come to a solid conclusion so I thought I'd bring it up here to see if anyone else has opinions. The main concern is that we don't block the IO thread on file access. To this end, I recently moved initialization of the spellchecker from the IO thread to the file thread. However, instead of reading in the spellchecker dictionary in one solid chunk, we memory-map it. Then later we check individual words on the IO thread, which will be slow since the dictionary starts off effectively completely paged out. The proposal is that we read in the dictionary at spellchecker intialization instead of memory mapping it. Memory mapping pros: - possibly uses less overall memory, depending on the structure of the dictionary and the usage pattern of the user. - strikeloading the dictionary doesn't block for a long time/strike this one no longer occurs either way due to my recent refactoring Reading it all at once pros: - costly disk accesses are kept to the file thread (excepting future memory paging) - overall disk access time is probably lower (since we can read in the dict in one chunk) For reference, the English dictionary is about 500K, and most dictionaries are under 2 megs, some (such as Hungarian) are much higher, but no dictionary is over 10 megs. Opinions? -- Evan Stade --~--~-~--~~~---~--~~ 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: Spellchecker and memory-mapped dicts
Faulting it in by hand is only helpful if we're right! If we're wrong, it could evict other stuff from memory to support a feature which a user may not use until the memory is faulted back out anyhow. [From the rest of the thread, though, it sounds like maybe we should just fix hunspell to be more efficient for our usage.] -scott On Thu, Oct 22, 2009 at 2:42 PM, Steve Vandebogart vand...@chromium.org wrote: It's been awhile since I looked at this, but the email I was able to dig up suggests that madvise is no faster than faulting in the mmap()ed region by hand. However, using posix_fadvise should give the same speeds as read()ing it into memory. IIRC though, posix_fadvise will only read so much in a single request and will let readahead handle the rest after that. -- Steve On Thu, Oct 22, 2009 at 2:27 PM, Scott Hess sh...@chromium.org wrote: On Linux what about mmap() and then madvise() with MADV_WILLNEED? [or posix_fadvise() with POSIX_FADV_WILLNEED on the file descriptor). -scott On Thu, Oct 22, 2009 at 2:06 PM, Steve Vandebogart vand...@chromium.org wrote: If you plan to read the entire file, mmap()ing it, then faulting it in will be slower than read()ing it, at least in some Linux versions. I never pinned down exactly why, but I think the kernel read-ahead mechanism works slightly differently. -- Steve On Thu, Oct 22, 2009 at 2:02 PM, Chris Evans cev...@chromium.org wrote: There's also option 3) Pre-fault the mmap()ed region in the file thread upon dictionary initialization. On Linux at least, that may give you better behaviour than malloc() + read() in the event of memory pressure. Cheers Chris On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade est...@chromium.org wrote: Hi all, At its last meeting the jank task force discussed improving responsiveness of the spellchecker but we didn't come to a solid conclusion so I thought I'd bring it up here to see if anyone else has opinions. The main concern is that we don't block the IO thread on file access. To this end, I recently moved initialization of the spellchecker from the IO thread to the file thread. However, instead of reading in the spellchecker dictionary in one solid chunk, we memory-map it. Then later we check individual words on the IO thread, which will be slow since the dictionary starts off effectively completely paged out. The proposal is that we read in the dictionary at spellchecker intialization instead of memory mapping it. Memory mapping pros: - possibly uses less overall memory, depending on the structure of the dictionary and the usage pattern of the user. - strikeloading the dictionary doesn't block for a long time/strike this one no longer occurs either way due to my recent refactoring Reading it all at once pros: - costly disk accesses are kept to the file thread (excepting future memory paging) - overall disk access time is probably lower (since we can read in the dict in one chunk) For reference, the English dictionary is about 500K, and most dictionaries are under 2 megs, some (such as Hungarian) are much higher, but no dictionary is over 10 megs. Opinions? -- Evan Stade --~--~-~--~~~---~--~~ 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: Spellchecker and memory-mapped dicts
WILLNEED says Hey, OS, I think I'm going to look at these pages soon, get yourself ready, but the OS could implement them as a nop, and can do it async. If memory is under pressure the system can do less, if memory is clear it can do more. Actually reading the data into memory blocks and actually reads them into memory. -scott On Thu, Oct 22, 2009 at 3:01 PM, Steve Vandebogart vand...@chromium.org wrote: Probably a bit off topic at this point, but but your response confuses me - MADV_WILLNEED and POSIX_FADV_WILLNEED will bring the pages into ram, just like faulting in mmap()'ed pages by hand, or read()ing it into memory. In my experience, read() and fadvise() are faster than mmap()+faulting everything in, or madvise(). Of course, read()ing it in means it has to be swapped out and can't just be dropped. If you want to suck the entire file in at some point, probably the best way is to fadvise() it in, then mmap() it and use it from there. -- Steve On Thu, Oct 22, 2009 at 2:52 PM, Scott Hess sh...@chromium.org wrote: Faulting it in by hand is only helpful if we're right! If we're wrong, it could evict other stuff from memory to support a feature which a user may not use until the memory is faulted back out anyhow. [From the rest of the thread, though, it sounds like maybe we should just fix hunspell to be more efficient for our usage.] -scott On Thu, Oct 22, 2009 at 2:42 PM, Steve Vandebogart vand...@chromium.org wrote: It's been awhile since I looked at this, but the email I was able to dig up suggests that madvise is no faster than faulting in the mmap()ed region by hand. However, using posix_fadvise should give the same speeds as read()ing it into memory. IIRC though, posix_fadvise will only read so much in a single request and will let readahead handle the rest after that. -- Steve On Thu, Oct 22, 2009 at 2:27 PM, Scott Hess sh...@chromium.org wrote: On Linux what about mmap() and then madvise() with MADV_WILLNEED? [or posix_fadvise() with POSIX_FADV_WILLNEED on the file descriptor). -scott On Thu, Oct 22, 2009 at 2:06 PM, Steve Vandebogart vand...@chromium.org wrote: If you plan to read the entire file, mmap()ing it, then faulting it in will be slower than read()ing it, at least in some Linux versions. I never pinned down exactly why, but I think the kernel read-ahead mechanism works slightly differently. -- Steve On Thu, Oct 22, 2009 at 2:02 PM, Chris Evans cev...@chromium.org wrote: There's also option 3) Pre-fault the mmap()ed region in the file thread upon dictionary initialization. On Linux at least, that may give you better behaviour than malloc() + read() in the event of memory pressure. Cheers Chris On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade est...@chromium.org wrote: Hi all, At its last meeting the jank task force discussed improving responsiveness of the spellchecker but we didn't come to a solid conclusion so I thought I'd bring it up here to see if anyone else has opinions. The main concern is that we don't block the IO thread on file access. To this end, I recently moved initialization of the spellchecker from the IO thread to the file thread. However, instead of reading in the spellchecker dictionary in one solid chunk, we memory-map it. Then later we check individual words on the IO thread, which will be slow since the dictionary starts off effectively completely paged out. The proposal is that we read in the dictionary at spellchecker intialization instead of memory mapping it. Memory mapping pros: - possibly uses less overall memory, depending on the structure of the dictionary and the usage pattern of the user. - strikeloading the dictionary doesn't block for a long time/strike this one no longer occurs either way due to my recent refactoring Reading it all at once pros: - costly disk accesses are kept to the file thread (excepting future memory paging) - overall disk access time is probably lower (since we can read in the dict in one chunk) For reference, the English dictionary is about 500K, and most dictionaries are under 2 megs, some (such as Hungarian) are much higher, but no dictionary is over 10 megs. Opinions? -- Evan Stade --~--~-~--~~~---~--~~ 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: Virtual dispatch doesn't work (as you might expect) in destructors!
Just to be clear for those of us who are wobbly on C++, this is because during the constructor or destructor, your object is of the class in question, NOT of the class it will finally be, because in the constructor the subclass has not been constructed, yet, and in the destructor the subclass was already destructed. So calling to the subclass virtual implementation would be bad. Scott Meyers says: http://www.artima.com/cppsource/nevercall.html Is there any way we could modify an object to assert that it can't happen in development? Like scoped_vtable_killer declared in the constructor and destructor which makes calling a virtual method on that object fatal? -scott On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow jor...@chromium.org wrote: I've spent a good deal of this week trying to track down what turned out to be a simple but fairly common problem: I forgot virtual dispatch only partially works in destructors. There have been several email threads about this, but it still bites us form time to time, so I thought it was worth another reminder. Details: I subclassed ChromeThread which subclasses base::Thread. base::Thread calls CleanUp on the thread right before termination. CleanUp is virtual. Both ChromeThread and my class override CleanUp(). base::Thread calls Stop() in its destructor to stop the thread (if it hasn't already been stopped). But by the time you hit destruction, the vtable is no longer available and thus the destructor of base::Thread (and anything it calls) does NOT have access to the vtable of ChromeThread (or my class). So, if you don't explicitly call Stop(), your subclass's CleanUp method will NOT be called. Thus the thread was going away without my CleanUp method ever being called. Obviously this affects more than just base::Thread. And this is also how you can hit errors with pure virtual methods being called. J --~--~-~--~~~---~--~~ 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: Virtual dispatch doesn't work (as you might expect) in destructors!
On Fri, Oct 30, 2009 at 3:54 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess sh...@chromium.org wrote: Just to be clear for those of us who are wobbly on C++, this is because during the constructor or destructor, your object is of the class in question, NOT of the class it will finally be, because in the constructor the subclass has not been constructed, yet, and in the destructor the subclass was already destructed. So calling to the subclass virtual implementation would be bad. Scott Meyers says: http://www.artima.com/cppsource/nevercall.html Is there any way we could modify an object to assert that it can't happen in development? Like scoped_vtable_killer declared in the constructor and destructor which makes calling a virtual method on that object fatal? Or is there any sort of built in compiler warning that we could turn on? I did a bit of searching and was really surprised that I couldn't find any mention of such a thing. It would have to be a really smart compiler, because you could call a function which calls another object's function which calls back to a virtual in your object. That's why I suggested a way to make vtable references fatal, so at least when doing development you could get a notification (and not check it in). -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: Which editor do you recommend on Mac OS X?
Carbon Emacs makes the Alt key work right, and copy/paste to the system pasteboard works like I expect w/in emacs. I find using emacs w/in Terminal.app to be annoying enough that I use emacsclient to throw edits out to Emacs.app. -scott On Tue, Nov 3, 2009 at 2:21 PM, Drew Wilson atwil...@chromium.org wrote: I've heard this suggested a few times (not just in this thread) - is there an advantage to running Carbon Emacs instead of plain-old-GNU-Emacs-in-a-terminal? -atw On Tue, Nov 3, 2009 at 1:14 PM, Scott Hess sh...@chromium.org wrote: +1. I found Aquamacs weird/annoying. Carbon Emacs seemed a lot better. [I come from a Linux background.] -scott On Tue, Nov 3, 2009 at 11:16 AM, Kenneth Russell k...@chromium.org wrote: There's a Carbon-based, non-Aquamacs Emacs available for Mac OS X. Recommended. http://www.emacswiki.org/emacs/EmacsForMacOS http://www.emacswiki.org/emacs/CarbonEmacsPackage -Ken On Tue, Nov 3, 2009 at 10:08 AM, Drew Wilson atwil...@chromium.org wrote: I've been using Aquamacs, although I don't like the fact that it has *so many* modes built-in and turned-on by default, and I also don't like the fact that it doesn't lend itself well to customization (it has its own set of initialization files it keeps hidden off). It's decent, though (but again, I've devolved over the years to using almost vanilla emacs bindings to allow moving to new platforms easier). I've also been known to use the built-in GNU emacs from a terminal shell (especially when working remotely/SSH-ing). I see no reason why you can't have the same experience that you do with your Linux box, although you'd have to find a way to drag the google3 elisp over. -atw On Tue, Nov 3, 2009 at 9:56 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? --~--~-~--~~~---~--~~ 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: revert now, ask questions later? WAS: Reverting a change, the fast way
+100. This is very similar to getting paged about a production problem. Sometimes you get sucked into wasting an hour on easy fixes which don't fix anything. That sets you up for stupid mistakes. So, you broke the build. Take it like a man/woman, revert your change, and land it again when you've got it right. It happens to everyone. The goal here isn't to save YOU ten minutes of time, the goal is to save 5 minutes for each of the couple dozen co-workers which will be impacted by the broken tree. Only ask for grace to fix the breakage if you're 100% certain you can fix it right the first time. -scott On Tue, Nov 3, 2009 at 3:52 PM, Nicolas Sylvain nsylv...@chromium.org wrote: +1 On Tue, Nov 3, 2009 at 3:38 PM, Avi Drissman a...@chromium.org wrote: I'm OK with that. Just make it clear that the sheriff does have authority. One time when I was sheriff I wanted to revert a broken patch. The author insisted on patching it over and over. He finally got it working about about seven patches and nearly three hours or so, when I was insisting on backing it out after the first 30m. Yes, this is exactly what we want to avoid. The 2-minute rule usually includes: Oops, I forgot to commit a file Let me disable the test I just added, it clearly does not work Oops, before committing I renamed a variable and forgot to change it at one place It also use to mean: Oops, I forgot an include. But this one has been biting us to much in the past, so I leave it at the discretion of the sheriff. I think people need to use their good judgement too. The length of a minute should be inversely proportional to the number of people trying to commit during this time of the day. Nicolas Avi On Tue, Nov 3, 2009 at 5:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: Large commit - update your .gclient files to avoid
On Thu, Nov 5, 2009 at 1:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. As long as we're on wishlists, it would be nice to have some dependencies be default-DENY rather than default-ALLOW. So rather than having to suppress things you often don't want, you have to enable things you sometimes do want. -scott [who has no patch lined up to implement 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: Preventing Incremental Backup of History/Thumbnails
Applying incorrect journal files would be bad. SQLite uses a sync cookie to do some tricks WRT keeping the cache warm. I'm somewhat surprised that the same thing isn't used to prevent applying journal files inappropriately. [I don't know this, and should not be spending time verifying it just now, but I'll star this for looking at later.] -scott On Mon, Nov 9, 2009 at 2:14 PM, Jens Alfke s...@google.com wrote: On Nov 6, 2009, at 10:09 AM, mrossetti wrote: 1) Exclude individual database files. Journal files would still be backed up. 2) Move the database files into a new, excluded directory. Both the database files and their journals would not be backed up. By 'journal' do you mean the temporary side-file that sqlite creates during a transaction? If so, option 1 is potentially quite dangerous. If a journal file is later restored from backup somehow, the next instance of sqlite that opens a transaction on the matching database will assume that a previous transaction died in midstream, and use the journal file to restore the original contents of the database. As the restoration is basically just a series of binary patches, if the database is out of sync with the journal file, the result will be a severely corrupted db. I have run into this before. (The same thing happens in the opposite scenario: where the db file gets restored from backup, but a journal file is still lying around.) The only safe thing to do is to apply the same exclusion rule to the journal as to the database itself. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: [chromium-dev] Re: Preventing Incremental Backup of History/Thumbnails
I've verified with SQLite that journal files do NOT get the sync cookie. We could consider adding it to our SQLite, I suppose. It looks like there is room in the journal header for things like that. Not sure how often it comes up, but if it does come up it would be pretty devastating. -scott On Mon, Nov 9, 2009 at 6:40 PM, Scott Hess sh...@chromium.org wrote: Applying incorrect journal files would be bad. SQLite uses a sync cookie to do some tricks WRT keeping the cache warm. I'm somewhat surprised that the same thing isn't used to prevent applying journal files inappropriately. [I don't know this, and should not be spending time verifying it just now, but I'll star this for looking at later.] -scott On Mon, Nov 9, 2009 at 2:14 PM, Jens Alfke s...@google.com wrote: On Nov 6, 2009, at 10:09 AM, mrossetti wrote: 1) Exclude individual database files. Journal files would still be backed up. 2) Move the database files into a new, excluded directory. Both the database files and their journals would not be backed up. By 'journal' do you mean the temporary side-file that sqlite creates during a transaction? If so, option 1 is potentially quite dangerous. If a journal file is later restored from backup somehow, the next instance of sqlite that opens a transaction on the matching database will assume that a previous transaction died in midstream, and use the journal file to restore the original contents of the database. As the restoration is basically just a series of binary patches, if the database is out of sync with the journal file, the result will be a severely corrupted db. I have run into this before. (The same thing happens in the opposite scenario: where the db file gets restored from backup, but a journal file is still lying around.) The only safe thing to do is to apply the same exclusion rule to the journal as to the database itself. —Jens --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Corrupt Profile
[Peter mentioned he hadn't seen my email - aha! Because it wasn't sent from the right account. Sorry for any dupes.] Sorry about dropping that, we're in the beta bomb run and I have many many emails which haven't been answered ... and since someone keeps helpfully adding new beta-blockers to my list, I doubt I'll get on it this week :-). While debugging the profile to see what's wrong is a good thing in and of itself, beyond potentially learning how things are broken, what is your expected end result? If your goal is to have a working profile with as much saved as possible, you probably should copy the default profile for safe-keeping, and start a profile of delete something, start Chrome, check behavior, rinse/lather/repeat until you find the offending file. Then restore from the default profile and delete the file which fixed things and see if that unblocks you. If you're lucky, it will just be the Extensions dir or Extensions Cookies file. -scott On Wed, Nov 11, 2009 at 1:35 AM, PhistucK phist...@chromium.org wrote: I have a corrupt profile. Scott Hess wanted to know about these kinds of things, so I e-mailed him more than a week ago, but he did not answer. Is it still interesting and if so, who should I contact? I am willing to share any information in order to correct the problem. The problem is that I cannot install extensions anymore. I am using the latest Dev version, 4.0.237.0. I downloaded an extension (for example, Vince's Clock) and it tries to save it as unconfirmed 95171.download. It does not matter whether I save it or change the name to x.crx, it will not load the extension installation window. Instead, it shows me the Windows cannot open the file 'open file with an unknown extension' dialog. The file it says it cannot open, is the original file name, not the .download one Trying the same procedure with Chrome and a different profile works. Thank you. ☆PhistucK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] SQLite compression in history database.
Long ago when developing fts1, I experimented with using zlib compression as part of the implementation. It fell by the wayside because it really didn't provide enough performance improvement (I needed an order of magnitude, it didn't provide it), and because of licensing issues (fts1/2/3 are part of core SQLite, which does not include zlib). Chromium already has zlib, and I don't think there's any particular reason not to hack our version of fts to support it. Looking at my October history file, I get the following (numbers are in megabytes): ls -lh History\ Index\ 2009-10 # -rw-r--r--@ 1 shess eng 66M Nov 24 09:38 History Index 2009-10 .../sqlite3 History\ Index\ 2009-10 select round(sum(length(c0url)+length(c1title)+length(c2body))/1024.0/1024.0,2) from pages_content; # 34.9 select round(sum(length(compress(c0url))+length(compress(c1title))+length(compress(c2body)))/1024.0/1024.0,2) from pages_content; # 12.29 select round(sum(length(block))/1024.0/1024.0,2) from pages_segments; # 24.6 select round(sum(length(compress(block)))/1024.0/1024.0,2) from pages_segments; # 14.3 pages_segments is the fts index. Since it is consulted very frequently, I'd be slightly nervous about compressing it. pages_content is the document data, which is hit after the index (or when doing a lookup by document id), so compressing it shouldn't have much performance impact. Does this seem like a win worth pursuing? -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Thoughts on // NOLINT?
On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting pkast...@google.com wrote: On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon j...@chromium.org wrote: In essence: return DoWork(foo) #if defined(OS_POSIX) DoWork(posix_specific) #endif ; // -- Lint complains about this guy I'd prefer this: #if defined(OS_POSIX) return DoWork(foo) DoWork(posix_specific); #else return DoWork(foo); #endif The same number of lines, but much easier to read. Or: bool ret = DoWork(foo); #if defined(OS_POSIX) ret = ret DoWork(posix_specific); #endif return ret; Breaking a single statement up with a macro is icky. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 10:43 AM, Glen Murphy g...@chromium.org wrote: As for the info bar/modal dialog: I've been thinking for a bit, and I'm not sure this is enough. We have plenty of data that shows users often leave browsers open for a very long time. The main risk is that someone sets the flag, starts their browser, trys out the new cool feature, and then leaves the browser window open...for a long time. The next time they start it they'll see the warning again, but the period of time in between (that they're more vulnerable) could be non-trivial. I think that the combo of factors involved here makes this enough of an edge that we can Not Worry About It. I think an infobar at startup is not annoying enough, and as Darin says, we often have other infobars to show then, which is problematic. I don't mind the idea of a blocking dialog on startup. We only avoid dialogs because they're annoying; in this case we *actually* want to annoy you. The dialog could also make the user confirm their choice, rather than being a notification. How annoying? Since we already know that people habitually mash the default button, the dialog could say Running with --no-sandbox is dangerous. Can I keep the sandbox enabled?, then OK is the good thing, and Cancel/No is the bad thing. [BTW, I hope it's obvious that we might not want to be as annoying if we disable the sandbox as part of an experimental feature. A little annoying, but since experimental features correlate with browsers crashing, we should be careful not to alienate developers who are testing the experimental feature...] [[And now I'm waiting for someone to suggest the --no-really-no-sandbox-i-like-being-insecure flag to suppress the dialog :-).]] -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Thread naming
On Thu, Dec 31, 2009 at 1:11 AM, Berend-Jan Wever skyli...@chromium.org wrote: It would be nice if we could name all threads, so you know what you're looking at. It would be nice if threads were required to be given a name as part of creation, perhaps with a central registry to make sure things are unique. If this amount of overhead is enough to prevent you from spinning up a new thread sometimes ... I guess that's a benefit. If it's not important enough to register, maybe it's not important enough to be a thread, and bad thread usage causes a lot of our bugs. -scott (from chromium.org this time) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] opening local files with chrome from command line, relative paths
On Sat, Jan 9, 2010 at 3:06 PM, Victor Khimenko k...@google.com wrote: P.S. There are interesting fact related to specifically colon and MacOS. Classic MacOS uses colon as delimeter and you can use slash in filename. when they used POSIX-compliat kernel they needed some way to resolve thus collision. The solution was simple and elegant: they swapped colon and slash - so if you'll create http: directory old MacOS 9 program will see http/ directory. Thus you can create file which looks as http://google.com; for unix-programs and for MacOS programs (even if it'll be two different files). Long long ago, we spent an evening trying to delete a file on an SGI machine which had been created with an embedded '/' character from an early Mac NFS client. The client could _create_ such files, but it couldn't delete them... eventually we found a command or system call or something to do a remove by inode and were golden. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote: Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 6:56 AM, Victor Khimenko k...@google.com wrote: On Thu, Jan 14, 2010 at 5:38 PM, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote: Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? It's different because user is hosed when he clicks CORRECT AND VALID file - at least the file which was correct and valid some time in the past. User DOES NOT click on the malicious http folder - he uses the same citibank link he always used. It the same as difference between NULL dereference and uninitialized variable - in first case problem is immediately obvious, in the the second one between error point and disaster there are millions of commands so it's not easy to see the connection. There is no clicking, here. It's when the user launches Chrome on the command-line with a particular file. Unless I misunderstand. For any programmatic system which wishes to launch Chrome with a command-line argument, we should expect them to be explicit (file:/...), and if they choose to pass us ambiguous input, there's only so much we can do. I would hope that programmatic systems aren't passing us relative command-line filenames, though, it's hard to have one program treat relative paths consistently, expecting two to address them with the same assumptions is madness. Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). Of course not - but if you'll open the file https://citibank.com it still can do a lot of stuff to your account. It's not the end of world, but it's not a trivial matter either. There are no separate domain for file named http:/citibank.com and for file named ../.ssh/identity :-) Of course there are other security measures which will hopefully save ../.ssh/identity file, but it does not mean we are free to ignore this threat. As I said, if convincing me to click on a local file can result in an attacker receiving arbitrary files from my system, then we are well and truly screwed. But I don't believe that is the case currently, so I don't think it would change anything if the file is http:/something.com rather than something.html. Yes, the user could be confused by the first URL (though Chrome would show file:///full/path/http:/something.com), but the attack surface is not changed. People load local HTML files all the time. If doing so could trivially expose sensitive local files like your ssh identity, then we should be talking about not allowing local files at all, not about what types of names we should allow. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
[BTW, don't take my argument as support for allowing relative paths on the command-line. It's such a low-volume use-case that I'd be perfectly fine requiring explicit fully-qualified URLs and be done with it. If it doesn't start with a protocol, we don't open it. 99.99% of the users who even would understand what we're talking about could trivially write a shell script or alias to handle it, if they care to.] On Thu, Jan 14, 2010 at 9:15 AM, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 6:56 AM, Victor Khimenko k...@google.com wrote: On Thu, Jan 14, 2010 at 5:38 PM, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko k...@google.com wrote: Consider this attack vector: URL file on Desktop. Chrome will be started from known directory, now we need to put malicious file there. Hmm. Easy: create archive with some valuable data AND file http:/www.google.com (as we've dicussed it's valid filename on Linux and MacOS). A lot of users will just unpack it on desktop and ignore some strange folder named http. Then they click on URL file and the data from computer is sent to some unknown direction. I'm not really sure where you're going, here. Why would this be any different than convincing the user to click on a .html file? It's different because user is hosed when he clicks CORRECT AND VALID file - at least the file which was correct and valid some time in the past. User DOES NOT click on the malicious http folder - he uses the same citibank link he always used. It the same as difference between NULL dereference and uninitialized variable - in first case problem is immediately obvious, in the the second one between error point and disaster there are millions of commands so it's not easy to see the connection. There is no clicking, here. It's when the user launches Chrome on the command-line with a particular file. Unless I misunderstand. For any programmatic system which wishes to launch Chrome with a command-line argument, we should expect them to be explicit (file:/...), and if they choose to pass us ambiguous input, there's only so much we can do. I would hope that programmatic systems aren't passing us relative command-line filenames, though, it's hard to have one program treat relative paths consistently, expecting two to address them with the same assumptions is madness. Chrome's various protections are based on where Chrome is getting the file from, not on the shape of the URL (if you open a file named https://citibank.com;, that file will NOT get the citibank.com secure cookie, etc). Of course not - but if you'll open the file https://citibank.com it still can do a lot of stuff to your account. It's not the end of world, but it's not a trivial matter either. There are no separate domain for file named http:/citibank.com and for file named ../.ssh/identity :-) Of course there are other security measures which will hopefully save ../.ssh/identity file, but it does not mean we are free to ignore this threat. As I said, if convincing me to click on a local file can result in an attacker receiving arbitrary files from my system, then we are well and truly screwed. But I don't believe that is the case currently, so I don't think it would change anything if the file is http:/something.com rather than something.html. Yes, the user could be confused by the first URL (though Chrome would show file:///full/path/http:/something.com), but the attack surface is not changed. People load local HTML files all the time. If doing so could trivially expose sensitive local files like your ssh identity, then we should be talking about not allowing local files at all, not about what types of names we should allow. -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
On Thu, Jan 14, 2010 at 1:16 PM, Peter Kasting pkast...@google.com wrote: On Thu, Jan 14, 2010 at 9:19 AM, Scott Hess sh...@google.com wrote: [BTW, don't take my argument as support for allowing relative paths on the command-line. It's such a low-volume use-case that I'd be perfectly fine requiring explicit fully-qualified URLs and be done with it. :( This lack-of-feature has bitten me numerous times in the past few months. I support the Firefox way. Your point needs support from non-awesome users. If you try to open a relative path and it doesn't work, you go Oh, right, relative path. The bone of contention in the thread is what should be done when you didn't mean to open a relative path. If all the Chromium developers all around the world needed this feature, that would still be a small number of people, and if they really needed it, enabling it only for non-release builds would probably cover most of those cases. [I'm just saying. As a Mac user, I must obey the party line that even though we run on the only real Unix, there is no command-line.] -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths
BTW, AFAICT on both Mac and Linux, chrome-cmd file.html opens file:///path/to/cwd/file.html. Mac works for opening relative http:/file.html. Since http: is not a valid filename for Windows, I'd say making them all consistent would make sense. On Thu, Jan 14, 2010 at 1:55 PM, Scott Hess sh...@google.com wrote: On Thu, Jan 14, 2010 at 1:16 PM, Peter Kasting pkast...@google.com wrote: On Thu, Jan 14, 2010 at 9:19 AM, Scott Hess sh...@google.com wrote: [BTW, don't take my argument as support for allowing relative paths on the command-line. It's such a low-volume use-case that I'd be perfectly fine requiring explicit fully-qualified URLs and be done with it. :( This lack-of-feature has bitten me numerous times in the past few months. I support the Firefox way. Your point needs support from non-awesome users. If you try to open a relative path and it doesn't work, you go Oh, right, relative path. The bone of contention in the thread is what should be done when you didn't mean to open a relative path. If all the Chromium developers all around the world needed this feature, that would still be a small number of people, and if they really needed it, enabling it only for non-release builds would probably cover most of those cases. [I'm just saying. As a Mac user, I must obey the party line that even though we run on the only real Unix, there is no command-line.] -scott -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
