[chromium-dev] can't download chrome installer when behind a squid proxy
I have a local squid proxy and on Windows machines using it the Chrome installer never finishes (I can download the first, small .exe which then initializes and tries to download the main installer). When not using squid it works fine. When using other proxies like tinyproxy, it also works fine. But for other reasons I have to use squid. What's the best way to debug the issue? I can change the settings on the proxy, capture network traffic, etc. But on the other hand other .exes download fine, there's just a problem with downloading from Google. -- 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] can't download chrome installer when behind a squid proxy
On Wed, Jan 20, 2010 at 22:38, Eric Roman ero...@chromium.org wrote: Omaha doesn't support manual authentication for proxies, so if your squid proxy is requiring a username/password that could be the problem. Yes, I know about this problem (it's documented in the help message linked when the installer finishes unsuccessfully). However, the proxy is transparent... maybe that's causing some problems? A good way to debug is to capture the traffic with wireshark and see what requests the installer issued. The problematic one is http://cache.pack.google.com/edgedl/chrome/install/195.38/chrome_installer.exe Squid tells me in the logs that the request was successful, not cached, direct. But the Windows machine I tried this on does not receive the file. There are some previous requests that look like trying to get the most recent version number. It looks like they finish successfully. -- 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
Michał, Chris: could you comment on security aspects and give some recommendations? Ben, could you comment on the user interaction / usability aspect? We have few choices here, I'm not sure which one is preferred. On Mon, Jan 11, 2010 at 23:23, Benjamin Smedberg bsmedb...@gmail.com wrote: For what it's worth, the way Firefox solves this is: * Check if the file is an absolute file path ** on Windows, X:\... or \\... ** on Posix, /... * Otherwise, it's a URL relative to the current working directory ** So index.html resolves using the URL machinery to file:///c:/cwd/index.html ** while http://www.google.com resolves to itself This doesn't deal with the case firefox.exe www.google.com (which would try to resolve as a file), but we decided not to care about this case. We do have the explicit firefox.exe -url www.google.com which will perform URI fixup to guess the correct URL. --BDS -- 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] Re: opening local files with chrome from command line, relative paths
On Wed, Jan 13, 2010 at 23:01, Chris Evans cev...@chromium.org wrote: On Wed, Jan 13, 2010 at 8:36 AM, Evan Martin ev...@google.com wrote: Since the proposed vulnerability is that I have cd'ed into a specially crafted malicious directory then type out google-chrome some-particular-url, at which point I will end up at a file:// URL under the attacker's control, I am skeptical we should worry about this. Steal all your local files and send them off to some website. I recently made this a tiny bit harder (restrict directory listings). I'll do something much stronger sometime soon. Thanks for the responses. However, I'm not sure about the next steps. Did you mean it's a security risk, don't do it, or the risk is negligible, do it? How about requiring a --file switch before a relative file path is considered? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] displaying unparseable ftp directory listings as-is
Is there any security risks with passing raw ftp listings to the renderer in case we can't parse them? We already have a check in the code so that we will only make a data connection to the server we have the control connection with. If it's ok to do so, I'd also like to include some message encouraging the user to submit a bug report like hey, Chrome FTP listing parser is not compatible with this site. That would really help with compatibility. The new listing parser is doing quite well, but I think it's still not compatible enough to entirely replace the Mozilla code. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] opening local files with chrome from command line, relative paths
We have http://crbug.com/4436, and the problem is that if you launch chrome index.html (with index.html in the current directory) it will try to navigate to http://index.html/ instead. This behavior is useful for cases like chrome www.google.com, and generally I don't see a good solution to this issue other than WontFix. Other shell launchers are expected to pass a full path I think. explorer.exe behaves in a reverse way (www.google.com fails, index.html succeeds). In firefox both local relative paths and urls without http work. What should we do for Chrome? -- 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] Best way to test HTTP basic auth cross-platform?
On Sat, Dec 19, 2009 at 02:25, Drew Wilson atwil...@chromium.org wrote: Is there another way to do it? Perhaps ui_test should register its own NotificationObserver with the AutomationProvider framework? Or is that a bogus approach? I'd really suggest starting with a browser_test instead. It's much easier to write a test that way, and much easier to change things around, so you're more likely to find a correct and simple way. Then you can port it to ui_tests (which generally adds complexity, but isn't as hard) if you want a bigger test. Generally using NotificationObservers to wait for things is a good sign. :) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] DirectoryWatcher and listening for user script changes
I was thinking about many DirectoryWatcher problems, especially on Linux, and now noticed http://crbug.com/20832. User scripts are the only user of DirectoryWatcher. DirectoryWatcher has many quirks - on Windows it behaves in a weird way on XP so we can't test it reliably (and hits the disk on UI thread - http://crbug.com/6080), on Linux it's incomplete because inotify doesn't natively support watching directory trees. On Mac it's OK I think. I'd rather like to remove it, but here are some other options I was thinking about that would really improve the situation. First, can we make DirectoryWatcher support only watching *files* and not directories (and making it FileWatcher)? We have reliable support for that on all platforms. It would simplify Linux code quite a bit, and maybe even allow writing better tests. What do you think? The basic options here are: a) Sticking with DirectoryWatcher and somehow implementing missing features on Linux (http://crbug.com/8968). Doesn't sound realistic to me, the current code is complex enough. b) Changing to FileWatcher (this seems to be the best option for now, unless we're not sure we want to get rid of it completely) c) Removing DirectoryWatcher completely (may simplify the user scripts code in chrome/browser/extensions, but also risks stability a bit) -- 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] Best Practices when disabling tests?
On Mon, Dec 14, 2009 at 21:23, Andrew Scherkus scher...@chromium.org wrote: I wrote up this section under our Tree Sheriff page: http://dev.chromium.org/developers/tree-sheriffs#TOC-Disabling-tests Thanks! I expanded the section to also mention the FLAKY_ prefix (which is very helpful in keeping the tree green and monitoring the flakiness). -- 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] Best way to test HTTP basic auth cross-platform?
On Thu, Dec 17, 2009 at 03:22, Drew Wilson atwil...@chromium.org wrote: The closest thing I found to what I want is the LoginPromptTest ui_tests, but these seem only to work on Windows because the automation framework doesn't yet support NotificationType::AUTH_NEEDED on anything but windows: ERROR:/Volumes/source/chrome.git/src/chrome/browser/automation/automation_provider_observers.cc(192)] Not implemented reached in virtual void NavigationNotificationObserver::Observe(NotificationType, const NotificationSource, const NotificationDetails) I could just enable this test only on Windows, but I'd rather have it working on other platforms as I don't have a good windows dev system - anyone know how much work it would be for me to implement the missing functionality in the automation framework? It may be possible to just remove the #ifdef from the file. If it compiles, it should be working. I don't think there's any other way to test the http auth functionality without it. Just a note: you wrote the closest thing. If the LoginPromptTest automation kind of doesn't fit, please consider developing a browser test first (you need to do less plumbing), and then, as you identify automation needs, port it to the automation framework. It has worked for me in the past. -- 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] UI Jank Task Force Status Update
On Tue, Dec 8, 2009 at 00:19, Mark Mentovai m...@chromium.org wrote: Is this thought to be http://crbug.com/29240, or are there other problems with the signal handler? The change to fix that is out at http://codereview.chromium.org/460094. I'm not sure. The failures are not deterministic. If I see some new failure after that, I'll file a bug. -- 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: Chromium Tech Talks
Thanks so much! It's nice to learn some things about webkit. Some ideas for the next round of talks: - how sandboxing works on Linux and Mac - ChromeFrame internals (how it interacts with IE, ExternalTab magic etc) - performance tests - Valgrind and ThreadSanitizer - plugins in the multi-process architecture, especially the challenges of sync messages, nested loops etc. - how the omnibox works internally -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] [GTTF] running the views and chromeos trybots for more kinds of CLs
I hit at least few cases when I broke the views and/or chromeos buildbot with a CL which doesn't touch the views code directly (which would trigger submitting it to the views trybot). Today another change in a gypi file triggered a compile failure on views bots, while all other trybots have been so green. How about triggering sending the CL to views trybots when it touches any gyp-related file, or any code in chrome? This should help making our tree even more green. -- 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] UI Jank Task Force Status Update
On Mon, Dec 7, 2009 at 22:34, Glenn Wilson gwil...@chromium.org wrote: Evan Triaging Linux Jank bugs. Probably not many that are actionable right now, though. That's not exactly Jank issue, but on a lot of our bots we're getting leftover processes on Linux. It seems they don't respond properly to SIGTERM. This seems to have started after we added the handler for SIGTERM (previously chrome was using the default handler). So this causes quite a lot of flakiness, but is also kind-of janky. -- 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] buildbot failure in Chromium on Modules XP (dbg), revision 33846
Just FYI, I checked in a patch to disable the test isolation for net_unittests. The thing is, it exposed further problems with the tests. I will investigate that offline. Sorry for a day of increased flakiness. I hope it will pay off in the future with less debugging mysteries with Singletons etc. On Fri, Dec 4, 2009 at 21:48, build...@chromium.org wrote: http://build.chromium.org/buildbot/waterfall/ Automatically closing tree for net_unittests on Modules XP (dbg) http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100 Revision: 33846 Blame list: thoma...@chromium.org Modules XP (dbg) Build 20100http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100 svnkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100/steps/shell_1/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100/steps/shell_2/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100/steps/gclient/logs/stdio compile base stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100/steps/compile/logs/stdio compile net stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100/steps/compile_1/logs/stdio compile sandbox stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100/steps/compile_2/logs/stdio base_unittests 1 disabled 2 flaky stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100/steps/base_unittests/logs/stdio net_unittests did not complete crashed or hung stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/20100/steps/net_unittests/logs/stdio Changed by: *thoma...@chromium.org* Changed at: *Fri 04 Dec 2009 12:33:01* Branch: *src* Revision: *33846*http://src.chromium.org/viewvc/chrome?view=revrevision=33846 Changed files: - *chrome/tools/build/mac/dump_product_syms* Comments: The GYP fixes the other week put lib on the front of this file, update this script also. BUG=none TEST=none Review URL: http://codereview.chromium.org/464042 Properties: -- 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] Two warnings when installing an extension
Just compiled Chromium Linux from trunk and downloaded the sample buildbot extension. I got two warnings while doing this: - when downloading, that the file might be dangerous and hurt my computer - do I want to continue - and second, whether I want to install the extension It may be a better user experience if there was only one such dialog (probably the extension one). Provided it's always displayed when the user tries to install an extension, it should be ok. What do you think? -- 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] Two warnings when installing an extension
On Wed, Dec 2, 2009 at 19:24, Aaron Boodman a...@google.com wrote: The first prompt is not shown when you install from the gallery, so for 99% of cases users won't see it. Ah, sounds great. By the way, I'm really happy how extensions in Chrome work in general. Instant installation etc. And one can even see the resource consumption in the task manager. -- 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] Xcode, whitespace and you
Could you document that on some Mac wiki page on code.google.com/p/chromium? This way if anyone decides to use Xcode editor at any time will see this handy tip. On Mon, Nov 30, 2009 at 21:31, Dave MacLachlan dmacl...@chromium.orgwrote: If you don't ever use Xcode as an editor, don't ever want to use Xcode as an editor, or don't know what Xcode is, you can stop reading now. Hopefully I've got a few of you left ;-) I open sourced an Xcode Plugin that thomasvl and I have been working on for a while, and enhanced it by adding the ability for it to clean end of line whitespace and add missing end of file newlines when you save a file. I would say it is in beta right now, as I've been using it for a week with no real problems. You can get it here: http://google-toolbox-for-mac.googlecode.com/files/GTM%20Xcode%20Plugin.10.0.1.ziphttp://google-toolbox-for-mac.googlecode.com/files/GTM%20Xcode%20Plugin.10.0.0.zip Its install path is a little difficult, but it should be put into: /Library/Application Support/Developer/3.1/Xcode/Plug-ins for development on Leopard and /Library/Application Support/Developer/3.2/Xcode/Plug-ins for development on Snow Leopard Once it is in place, restart Xcode, and you should have a About GTM Xcode Plugin menu item under the Xcode menu. If you don't have this item, please check the location you installed it and try again. To turn on whitespace cleanup: 1) Go to XcodePreferences... and choose the Google panel. 2) Check the Correct Whitespace on Save checkbox, and you should be good to go. If you run into any problems, please log them at: http://code.google.com/p/google-toolbox-for-mac/issues/list If there are any other Xcode enhancements which would make your life easier you may want to log them at http://code.google.com/p/google-toolbox-for-mac/issues/list as well. I can't guarantee anything, but if it saves people a lot of time, we may be able to hack it in there. Cheers, Dave PS If you are already using the MacDevTools and have a MacDevTools plugin installed, you will want to remove it and replace it with this one. They won't work well together, and the GTM Xcode Plugin covers 95% of what the old one did + the whitespace cleanup. -- 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] Waiting for things in ResourceDispatcherHost
Currently we don't start the request in ResourceDispatcherHost until the user script is ready (or not needed). UserScriptListener handles that. We also wait for SafeBrowsing, Plugins, etc. We're going to wait for PrivacyBlacklists. I was thinking about refactoring RDH so that it would be easy to pause requests (or not start them) until something is ready. For some things we can just pause requests (like SafeBrowsing), for some we can't even start a request (like Privacy Blacklist, which can block sending the referrer, User Agent, cookies, etc or just cancel the entire request). How would you recommend doing that? I think I wouldn't switch all existing things to it immediately (it's a complex piece of code). I'd probably start with UserScriptListener just to try it, and then Privacy Blacklists. What do you think? -- 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] Flaky SessionHistoryTest.LocationReplace, fun with investigating it
On Wed, Nov 25, 2009 at 20:57, Tim Steele timste...@google.com wrote: It seems like the test should wait for the title to update, and not the navigation to finish. I'm pretty sure it's not a waiting problem. I followed what the test does manually, and I could still reproduce the issue. I also checked with debugger, where things are slowed down, and it was still there. The renderer just doesn't send the UpdateTitle message at all. Today I followed the code flow very carefully, just attached to the browser under test in a debugger, set breakpoints in title-related functions down to WebCore. It's quite possible that it's some part of WebCore logic that's involved (like not telling the glue code about the title). It's mysterious though why the test generally passes on the buildbot (but not on trybot). Would it be a good idea for the browser to query the renderer for title before it declares navigation as finished? Or maybe the renderer could do so internally? What do you think? -- 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] Flaky SessionHistoryTest.LocationReplace, fun with investigating it
On Wed, Nov 25, 2009 at 22:33, Tim Steele timste...@google.com wrote:
There are only a couple places where WebCore tells the client that the
title changed (looks like 3, search FrameLoader for
dispatchDidReceiveTitle). There are conditionals wrapping each such call
and also, in some cases, wrapping the methods that call the methods in those
3 cases. In one of *those *cases, in DocumentLoader::setTitle, I see
this code:
if (!trimmed.isEmpty() m_pageTitle != trimmed) {
frameLoader()-willChangeTitle(this);
m_pageTitle = trimmed;
frameLoader()-didChangeTitle(this);
}
My (possibly flawed) debugging shows that when the test fails, we're not
even touching that code path.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
[chromium-dev] Flaky SessionHistoryTest.LocationReplace, fun with investigating it
A little background: SessionHistoryTest.LocationReplace rarely fails on the buildbot (isn't even on the flakiness dashboard), but seems to be #1 flaky test on the trybot, where it fails almost every time (or so it seems to me). It also reproduces very consistently on my Windows VM, so we have a good test case. I'm trying to fix the flaky test. What the test does is quite simple: it navigates the browser to a page with a non-empty title, which then redirects (in onload handler) to a page with an empty title. It waits for the navigation to finish, and expects an empty title. However, when it flakes out, the old non-empty title remains. I verified that the test uses TabContents and NavigationController to get the tab title. I also tried using setTimeout(... , 0) in the onload handler and waiting for two navigations instead, just as an experiment. It didn't change the flaky behavior. Using about:ipc and manual testing I observed that when the test fails, the renderer doesn't send the UpdateTitle message to tell the browser that now it should display an empty title. It doesn't look like a waiting problem with the automation. I've done it manually, and the nonempty title was still there. I'm not very familiar with the renderer code. Everything seems fine on the first glance, and I don't really know where to look for things that may go wrong. One thing that may help me with the investigation is the expected sequence of events from the moment we navigate to the redirecting page. Any other hints are also welcome. -- 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] Flaky SessionHistoryTest.LocationReplace, fun with investigating it
On Wed, Nov 25, 2009 at 00:07, Evan Stade est...@google.com wrote: sounds like http://crbug.com/22560 Thanks for finding it. /me votes for removing the Mstone-X label from it, bumping priority to Pri-2, adding a FlakyTest label and details about SessionHistoryTest.LocationReplace, and finally closing the SessionReplace bug as a duplicate of 22560. I can do that if nobody objects. To summarize the flakiness of this test: on buildbot it didn't get to the flakiness dashboard, but on the trybot it seems to fail almost every 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] Singleton shenanigans in base/time_win.cc causing problems (not the first time)
On Fri, Nov 20, 2009 at 23:34, Darin Fisher da...@chromium.org wrote: We could define a function that must be called before you can use code in base/. You could add a call to this everywhere that we currently create the AtExitManager. Or, maybe we could combine those somehow. Thanks for the ideas! That inspired me to choose current solution ( http://codereview.chromium.org/431008) after experimenting with some other choices. I'm thinking about removing the other Singletons in time_win.cc. They're not so evil, but their presence might encourage creating more Singletons unnecessarily. And on Vista, we have better time calls, which don't have the rollover issue etc. -- 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] Singleton shenanigans in base/time_win.cc causing problems (not the first time)
On Mon, Nov 23, 2009 at 02:22, Marc-Antoine Ruel mar...@google.com wrote: It's really about the unit tests, not in chromium. I guess we could probably leak the singleton in the unit tests too on each reset. Pawel, what do you think? Note to all the static local makers: you create an implicit atexit() each time... Use a leaky singleton instead. That was my first though as well, but it won't fix the problem really. If a Singleton touches a MessageLoop, we're going to have bad problems in tests (because we create and re-instantiate it for different tests, and some tests don't have MessageLoop at all). And SystemMonitor does, and has to. SystemMonitor makes one assumption that we can't really where it is currently: that one MessageLoop is always running through its lifetime. I have a patch ready (have to submit it yet) that moves SystemMonitor to chrome/common, as well as HighResolutionTimerManager, and de-Singletonizes them. They have to be instantiated where currently SystemMonitor::Enable is called. I verified that we don't get the bad problems that we currently have with that. If it doesn't convince you... SystemMonitor was a LeakySingleton. And it still caused problems because of its assumption that the same MessageLoop exists through its lifetime. I think that moving it to a place where we can make that assumption valid is the proper fix. Another (slightly weird maybe) solution would be to have a per-thread SystemMonitor, lazily created. Then we could just use ObserverList, which doesn't use MessageLoop. But IMHO it is more complex than the proposed solution above, and may have its own problems. What do you think? -- 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] workflow for cross-platform development
On Sat, Nov 21, 2009 at 19:52, Chris Bentzel cbent...@google.com wrote: Have there been any thoughts about adding gcl patch and unpatch commands which will grab the file diffs as well as duplicate the CL metadata in src/.svn/gcl_info? It's not trivial to correctly apply a patch in svn (file moves, property changes, merge conflicts, etc). With git-cl, you can just say git cl rietveld-issue-number, and it will do what you want. -- 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] class has virtual method but non-virtual destructor
On Fri, Nov 20, 2009 at 21:05, Evan Martin e...@chromium.org wrote: Your analysis is correct. However, a virtual destructor is not needed in the case where you never delete through the Base*. It turns out for our codebase that is very common (due to lots of observer-like patterns), so we decided to not rely on this compiler warning. It's only caused horrible bugs once or twice! :) Is it worth to be more tricky at the expense of wasting time for debugging? I hate it when after investigating some crazy bug it turns out to be something that a compiler can detect. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Singleton shenanigans in base/time_win.cc causing problems (not the first time)
Do you have some idea how to get rid of the Singletons in base/time_win.cc? They don't play very well with base::SystemMonitor, MessageLoop, and test code. Here's the scenario we're hitting right now (in browser_tests): 1. HighResolutionTimerManager is created to enable high resolution timer unconditionally. An AtExit callback is created to destroy it. 2. The main MessageLoop is created. Its LazyInstance initializes a ThreadLocalPointer, which gets assigned the pointer to the MessageLoop. An AtExit callback is registered to reset the LazyInstance to the initial state. 3. BrowserMain enables monitoring SystemMonitor in HighResolutionTimerManager. 4. Which makes HighResolutionTimerManager register as a SystemMonitor observer. If everything seems OK so far, you're almost right. It's perfectly fine when browser runs, but has surprising special effects when test code runs. Here's what happens: 1. MessageLoop is destroyed. Its ThreadLocalPointer is set to NULL. 2. AtExit callbacks start to execute. 3. HighResolutionTimerManager is destroyed first. Its StopMonitoring method is called from dtor, which in turn touches MessageLoop::current(), which touches LazyInstance and makes it re-initialize itself, which registers AtExit callbacks which causes a DCHECK failure, because we're already processing AtExit callbacks. Don't worry too much if the explanation above is unclear (I'm afraid it is). The point is, it's not the first time that a nasty bug happens with SystemMonitor and the time_win.cc Singletons. Earlier it was different, so it's not so much important in what particular way it failed now. I'd really love to get rid of these Singletons. Do you have any ideas? We have two things here: 1) NowSingleton which keeps track of Windows time rollover. This might be harder to remove, but isn't causing too many problems. 2) HighResolutionTimerManager is causing problems. It was previously part of NowSingleton. I extracted the most evil part of it, and this is the current HRTM. I'm thinking about hardwiring it with the SystemMonitor or making it a Leaky Singleton maybe... -- 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] FYI ... you might find some issues missing in issue_tracker
Not sure if that's related, but bugdroid started to behave strangely. I see new comments for commits from before a week. On Wed, Nov 18, 2009 at 20:27, Dirk Pranke dpra...@chromium.org wrote: Hi all, Just a heads' up ... we've discovered a bug in Issue Tracker that has caused a few of our issues (along with a issues from other projects) to be partially deleted from the database. The team is aware of the problem and working on a solution, but it may not be fully patched until after Thanksgiving because they're in the midst of a release. So far I've only found two issues missing, so you probably won't notice this unless you're exceptionally anal, like I am :) -- Dirk -- 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] support for WATCHLISTS in git-cl
It turns out that WATCHLISTS aren't fully effective because git-cl doesn't support them. It doesn't look very hard to implement the support for git-cl because there is already a watchlists.py file, but then there are some questions: - should the watchlists.py file (from depot_tools) be copied to the git-cl repo or should git-cl try to locate it (upload.py is copied) - should watchlists.py be integrated into upload.py (probably not)? What do you think? -- 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] Linting chrome/ in pre-submit checks
On Tue, Nov 17, 2009 at 20:43, Peter Kasting pkast...@google.com wrote: On Tue, Nov 17, 2009 at 11:40 AM, Evan Martin ev...@google.com wrote: Since we're talking about style, I'll note that this pattern is no good (and I've seen it explicitly called out somewhere before). The problem is that your assertions are not helpful. You get expected 'foo', got 'bar' on line 80 but line 80 is just the body of a for loop. (a) I frequently write EXPECT_EQ(a, b) Test case in question is c; (b) Even when this is not true it costs me almost no time to track down the case in question in the debugger (if I need to; often the expected result is unique) You can also use SCOPED_TRACE (learned that from eroman). -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] [GTTF] running tests that fail most often early in the queue
I was just looking at the buildbot cycle stats at http://build.chromium.org/buildbot/waterfall/stats and realized that on many bots the most frequently failing tests are browser_tests and ui_tests. Then I checked how early they are run by each bot (the earlier we know about the failure, the earlier we can react). So, for example Chromium XP runs a lot of slow page cycler tests before browser_tests, and then another bunch of page cycler tests. page_cycler tests don't fail so frequently, and when they fail, it's frequently some evil flakiness. When browser_tests do fail however, it may indicate something more serious. A similar thing is with XP Tests: we're running mini_installer_tests (which take about 2 minutes), and then some other things which rarely fail, then UI tests (which fail frequently), and browser_tests at the end! I know that some of these cases are just flaky failures. But by knowing earlier about a failure, we'd have more time to decide what to do with it. -- 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: Waiting for privacy blacklists to load in ResourceDispatcherHost
On Thu, Nov 12, 2009 at 20:26, John Abd-El-Malek j...@chromium.org wrote: My question still stands: if this list is needed in order to process the first network request, why add extra complexity to RDH to make more things asynchronous, when either way any IO is basically blocked on the blacklist? You might as well load the list on the IO thread. Indeed, that would simplify a lot of things. However, we may recompile the blacklist when browser is running, for example when loading a new extension. In that case, we probably don't want to stall the IO thread. The difference is that when starting the browser, we don't have yet any blacklist. We should definitely wait for the blacklists to load, because it would be surprising for the user if the blacklist doesn't take effect for some time after starting the browser. When changing the blacklists when the browser is already running, it's more complicated. Nick, could you comment whether new network requests should be paused when a blacklist is changing? (for example due to now extension being loaded) Not waiting then would make things trivial. And anyway, waiting for blacklists after the browser started is even more surprising, as some request may already be started (it's not obvious what to do with them). -- 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: Waiting for privacy blacklists to load in ResourceDispatcherHost
On Thu, Nov 12, 2009 at 21:28, Peter Kasting pkast...@google.com wrote: On Thu, Nov 12, 2009 at 12:13 PM, John Abd-El-Malek j...@chromium.orgwrote: per our chat on irc, I think if a new privacy blacklist is added while running, it should be loaded on the file thread, and when it's available the IO thread should be updated. The user won't have expectations or know how already pending requests are scheduled, and won't be loading a blacklist and within a 100ms loading a page. Well, if somebody uses these to write an adblocker that auto-updates its blacklists at frequent intervals, the last clause might be false. But it seems like loading the new list on the file thread and then pinging the IO thread is still the right thing to do then. Just to clarify: a blacklist is an integral part of an extension, and must be declared in its manifest. Updating a blacklist means updating the extension. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Waiting for privacy blacklists to load in ResourceDispatcherHost
Initially I got an advice to use PauseRequest and ResourceHandler to wait with servicing requests until all privacy blacklists are loaded. However, there are problems with that. When you look at ResourceDispatcher code, we need a Blacklist::Match* even before creating URLRequest. I thought about separating the RDH::BeginRequest into two parts: the initial part, and the second part, which executes when we finally have a blacklist match. If we don't have it at the time BeginRequest is executed, we'd save all needed data and put it into a queue. When the blacklist is loaded, all queued requests will be started by the second part of split BeginRequest. To do that, I'd need to listen for BlacklistManager notifications in RDH (on IO thread). Does it seem OK to make RDH a NotificationObserver and use NotificationRegistrar inside? The BlacklistManager will publish the compiled blacklist on the IO thread (the CL I published doesn't yet have that fix). Or maybe I should do it some other way? I'm not really familiar with the code in browser/renderer_host. -- 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: Waiting for privacy blacklists to load in ResourceDispatcherHost
On Thu, Nov 12, 2009 at 01:00, John Abd-El-Malek j...@chromium.org wrote: On Wed, Nov 11, 2009 at 1:22 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: To do that, I'd need to listen for BlacklistManager notifications in RDH (on IO thread). Does it seem OK to make RDH a NotificationObserver and use NotificationRegistrar inside? The part about making RDH a NotificationObserver sounds fine. However, if you block all requests from even starting until BlackListManager is ready, you're basically delaying the IO thread until the data is loaded anyways, so it doesn't seem that making it happen asynchronously buys much. The problem is that for example a privacy blacklist may prevent a request for sending the referrer. Another thing they can block are cookies. That means that probably the only thing we can do before all blacklists are loaded is connecting to the host (which is still a win). Is it possible to do that using ResourceHandlers? And of course the performance of loading blacklists from disk is considered to be critical. They are stored in one binary file on disk, in a simple format. -- 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] Beginning with development
Note however that you can build specific projects. When working on base or net for example, you can build just base_unittests and net_unittests. When working on webkity things, you can sometimes compile just the test_shell, and not 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: Assertion failures on Mac OS are super slow
On Mon, Nov 9, 2009 at 5:03 PM, Dave MacLachlan dmacl...@google.com wrote: I haven't looked into it, but I'm assuming the reason it's so slow is because of the bad DSYM parsing in Leopard. It should be much faster in Snow Leopard, but that probably doesn't help you. That's probably right. I haven't seen this issue on Slow Leopard, and I was debugging a few crashes recently without problems. --~--~-~--~~~---~--~~ 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: Singleton, LazyInstance, and testability
On Wed, Nov 4, 2009 at 08:56, Aaron Boodman a...@chromium.org wrote: Why don't you pass an Extension instance? It's in a test. Mocking an Extension is not trivial as well. :( Or maybe... I didn't read all of the extensions unit tests, maybe it's not that hard. It seems like you are violating the contract of that notification by not doing so, and even if you solve this problem, other similar problems would be likely to happen again in the future. I see. Hmm... the test assumes that the only listener is BlacklistManager, because the idea of the unit test is to test it in isolation. In the browser_test I'm obviously not making that assumption, and it's using ExtensionsService with real Extensions etc. Please also note that the BlacklistManager unit test will only send EXTENSION_LOADED notification, without pairing EXTENSION_UNLOADED. This is going to cause problems anyway at some point if there are other, unexpected listeners. If the Extension was easily mocked, I would pass a real instance anyway. What do you think I should do (for the unit test)? And the PluginService and PluginList in current shape used in unit_tests is just flakiness waiting to happen. It would be nice to fix that even if it's not blocking the privacy blacklists patch. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Singleton, LazyInstance, and testability
So, the problem with Extensions has been solved (thanks to Aaron), but there's stil the original issue that may bite at any time (please see the first message for context): Is there a big difference between a Singleton and LazyInstance? I was thinking about making NPAPI::PluginList a Singleton instead... On Wed, Nov 4, 2009 at 09:18, Aaron Boodman a...@chromium.org wrote: I think in this case you can just pass an Extension instance. This is done all over the unit tests for extensions. See, eg extension_unittest.cc. Oh, indeed. Thanks, after looking at other tests it was easy. It was a bit annoying that I had to use #ifdefs for FilePath though. --~--~-~--~~~---~--~~ 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: Working on privacy blacklists, collision warning
On Thu, Oct 29, 2009 at 21:50, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: - make ExtensionsService a BlacklistPathProvider and write a test which loads an extension and verifies that BlacklistManager notices that (I'm working on it now) This is done. To clarify: you can't yet load an extension in the browser and see the effects of the blacklist. The test I wrote so far is using BlacklistManager manually. The full scenario will be available only after integrating BM with Profile and ChromeURLRequestContext. I'm now fixing some threading issues in BlacklistManager (switching to ChromeThread), and then will continue with the rest: - verify that blacklists are valid (the format is correct) when validating an extension (and update unit tests) - use BlacklistManager in ChromeURLRequestContext, pausing requests until the blacklist has loaded and write an integration test --~--~-~--~~~---~--~~ 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 using threads in the browser process
On Tue, Nov 3, 2009 at 06:50, John Abd-El-Malek j...@chromium.org wrote: *The solution* 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed if the target thread is known to outlive the current thread. The four static methods have the same signature as the ones from MessageLoop, with the addition of the first parameter to indicate the target thread. ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); 3: If your object must be destructed on a specific thread, use a trait from ChromeThread: class Foo : public base::RefCountedThreadSafeFoo, ChromeThread::DeleteOnIOThread Awesome! 4: I've removed all the special casing and always made the objects in the browser code behave in one way. If you're writing a unit test and need to use an object that goes to a file thread (where before it would proceed synchronously), you just need: ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current()); foo-StartAsyncTaskOnFileThread(); MessageLoop::current()-RunAllPending(); There are plenty of examples now in the tests. Are there any examples for asynchronous processing (with a real backend thread)? I think that chrome/browser/privacy_blacklist/blacklist_manager.cc uses some of the anti-patterns you described (it caches base::Thread* instead of MessageLoop*, but I understand it's equally bad). And it will benefit a lot from ChromeThread::DeleteOnIOThread. The good part is that BlacklistManager is not yet used in the browser. I will fix the issues before the final integration of BlacklistManager. --~--~-~--~~~---~--~~ 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: refactoring and git
On Tue, Nov 3, 2009 at 16:58, Evan Martin e...@chromium.org wrote: I'm not sure which news you're referring to. :) To the one that the files are supposed to by svn-copied by git, that there is a command to check for that, and that you offered to help in case of problems. :) --~--~-~--~~~---~--~~ 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?
On Tue, Nov 3, 2009 at 19:08, Drew Wilson atwil...@chromium.org wrote: 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. I have it working. For reference, the file can be downloaded from http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el Maybe I should try the non-aqua Emacs, hm... How about building? Is using xcodebuild slower than running the build from Xcode? My simple testing shows that there is no big difference. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Which editor do you recommend on Mac OS X?
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] Singleton, LazyInstance, and testability
I encountered another problem related to Singletons in unit tests. PluginService is a Singleton, and it listens to extensions notifications. In one of my tests when I was using the extensions notifications the PluginService crashed because I passed NULL as the Extension* - because the listener I was testing didn't even read that value, but PluginService did (it was unexpected). I tried to fix the issue by adding a shadow AtExitManager to the test which instantiated PluginService (resource_dispatcher_host_unittest.cc). And then another crash appeared on Windows: NPAPI::PluginList is a LazyInstance, which means that the shadow AtExitManager destroyed it, but it didn't re-instantiate itself the next time it was used. Is there a big difference between a Singleton and LazyInstance? I was thinking about making NPAPI::PluginList a Singleton instead... By the way, I have a more general fix in the queue (an unwanted Singleton detector). If you're interested, please star http://crbug.com/12710. It seems that the most recent gtest (1.4.0) has necessary support. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FYI: Linux interactive_ui_tests a bit hosed
I think that the right fix is to switch interactive_ui_tests to browser_tests launcher (jcampan did some great work to make the launcher more flexible, it may be quite simple to do the switch now - if there are no UI tests in interactive_ui_tests). I also suggest bumping the priority of http://crbug.com/25997 to P1 and possibly marking it with FlakyTest label. On Mon, Nov 2, 2009 at 09:37, John Abd-El-Malek j...@chromium.org wrote: This is related to bug 25997. The tests are inherently flakey because singeltons aren't released between runs, so cached MessageLoop pointers are bogus. Sometimes they're ok when the order of construction/destruction of MessageLoop pointers is the same. But if that changes, or other memory allocations change, the tests start failing. Just wanted to send a heads up since I spent a day debugging this last week, and now they're failing again. --~--~-~--~~~---~--~~ 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 much RAM needed to get past linking? (Linux)
If you have less than 1 GB of RAM, I wouldn't even try to link the biggest binaries. 2 GB of RAM should be sufficient, although with 4 and more it's better. And you will notice the change after switching to gold. On Mon, Nov 2, 2009 at 18:58, Adam Langley a...@chromium.org wrote: On Fri, Oct 30, 2009 at 9:10 AM, Akira ak...@yayakoshi.net wrote: I was building on Fedora 10 and was able to compile but the linking stage (see below) consumes more and more memory- the 500Mb of remaining memory, then another 1Gb of swap- before being killed. Are you using gold? http://code.google.com/p/chromium/wiki/LinuxFasterBuilds#Linking_using_gold If not, that's the single biggest win for linking size and speed. I know Evan builds on his laptop using gold, but I don't know the exact specs. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] compile fails on Ubuntu 9.04
I'm getting this compile error when compiling on Ubuntu 9.04 (scons): Compiling /home/ph/chromium/src/sconsbuild/Debug/obj/libxslt/libxslt/libxslt/xsltutils.o Generating version information Creating library /home/ph/chromium/src/sconsbuild/Debug/lib/libxslt.a Indexing /home/ph/chromium/src/sconsbuild/Debug/lib/libxslt.a Compiling /home/ph/chromium/src/sconsbuild/Debug/obj/base/linux_versioninfo/file_version_info_linux.o scons: *** [/home/ph/chromium/src/sconsbuild/Debug/obj/yasm/genmacro/source/patched-yasm/tools/genmacro/genmacro.o] Source `/home/ph/chromium/src/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.c' not found, needed by target `/home/ph/chromium/src/sconsbuild/Debug/obj/yasm/genmacro/source/patched-yasm/tools/genmacro/genmacro.o'. scons: building terminated because of errors. This is the first time I'm compiling Chrome on that system (it's inside a virtual machine). Do you have some idea how to fix the problem? I've run install-build-deps.sh. --~--~-~--~~~---~--~~ 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: refactoring and git
That's a good news. Can that info be put somewhere in the UsingGit wiki page? On Mon, Nov 2, 2009 at 23:56, Evan Martin e...@chromium.org wrote: On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson atwil...@chromium.org wrote: I'm doing some refactoring in the chromium worker code, and I got the following review feedback: small request: can the files that were branched from existing files be svn copy'd instead of copying manually and svn added? This will preserve history and will make it easier to see what changed in the review. Is there a way to do this with git? I do want to make my reviewers happy :) Git has an ...odd... way of thinking about renames. The pieces you need to know are: 1) Does git believe you did a rename? Consult git diff -M -C --stat origin... and see if it prints renames. 2) If no, ping me off-list and I'll help you out. 3) If yes, Rietveld should be able to display the diff properly. However, this code is relatively untested (we have to convert the Git renames into SVN-style renames -- SVN doesn't actually support true renames, oddly enough) so it could be wrong. In that case, also ping me off-list. :) --~--~-~--~~~---~--~~ 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: Working on privacy blacklists, collision warning
I landed the patch, and now the code in browser/privacy_blacklist should be quite stable (at least the interfaces). There's still a lot of work to do, but here's my plan for now: - make ExtensionsService a BlacklistPathProvider and write a test which loads an extension and verifies that BlacklistManager notices that (I'm working on it now) - verify that blacklists are valid (the format is correct) when validating an extension (and update unit tests) - use BlacklistManager in ChromeURLRequestContext, pausing requests until the blacklist has loaded and write an integration test On Mon, Oct 26, 2009 at 09:05, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Please don't make non-trivial changes to chrome/browser/privacy_blacklists if possible. I have a big change which I'll be soon (today) submitting for review. It will be needed to integrate privacy blacklists with extensions. --~--~-~--~~~---~--~~ 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: [Green Tree] Task Force Status Update 10/26
On Wed, Oct 28, 2009 at 16:35, Scott Violet s...@chromium.org wrote: I suspect this happens when the theme resources aren't correctly built. Perhaps we should have this check early on in ui tests so that we don't run any tests if this check fails. Yeah, I was even thinking about a build step, right after the compile (so we detect it early, on the builder - and seeing the patch that cause the problem would be easier). So there are two possibilities: - theme resources are not rebuilt correctly - .cc files depending on the resources are not rebuilt correctly Where the second one is harder to debug. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Working on privacy blacklists, collision warning
Please don't make non-trivial changes to chrome/browser/privacy_blacklists if possible. I have a big change which I'll be soon (today) submitting for review. It will be needed to integrate privacy blacklists with extensions. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] compile error on Snow Leopard
I get this when compiling unit_tests on Mac OS X 10.6 Snow Leopard: /Users/ph/chromium/src/chrome/browser/cocoa/bookmark_bar_controller_unittest.mm:689:0 /Users/ph/chromium/src/chrome/browser/cocoa/ bookmark_bar_controller_unittest.mm:689: warning: 'stringWithCString:' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:364) And warnings are treated as errors so it breaks the build. Mac OS X build is healthy on the buildbot, so it's either something on my machine, or the GCC in Snow Leopard has more warnings. Is there some easy workaround? I don't know what's the correct fix for 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] How to use PauseRequest
I'm going to use PauseRequest for privacy blacklists. It seems that I should create a new ResourceHandler, and resource handlers seem to wrap another resource handlers. Then I'd have to add code to use the new ResourceHandler in ResourceDispatcherHost. I'd need to write a ResourceHandler which would pause any requests until the BlacklistManager has loaded its blacklist (I can get a notification for that, this is the easy part). After receiving the notification, I'd un-pause all pending requests. What's a good way to do that (writing such ResourceHandler)? --~--~-~--~~~---~--~~ 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: weird Visual Studio link error, will clobber fix it?
That fixed it, thanks! On Fri, Oct 16, 2009 at 22:00, Marc-Antoine Ruel mar...@chromium.orgwrote: ... more hotfixes for you to install http://dev.chromium.org/developers/how-tos/build-instructions-windows On Fri, Oct 16, 2009 at 3:57 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I'm consistently getting this error when linking (fails 57 times when compiling the entire chrome.sln): 2shell32.lib(shguid.obj) : fatal error LNK1103: debugging information corrupt; recompile module I'm using Visual Studio 2005, fresh checkout. Should I just try clobber? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] weird Visual Studio link error, will clobber fix it?
I'm consistently getting this error when linking (fails 57 times when compiling the entire chrome.sln): 2shell32.lib(shguid.obj) : fatal error LNK1103: debugging information corrupt; recompile module I'm using Visual Studio 2005, fresh checkout. Should I just try clobber? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] bugtracker cleanup
Today I reviewed some old bugs which didn't get any attention and tried to correctly mark/assign/close them. Feel free to reassign a bug if I assigned it to you - I was generally looking for people familiar with the area so that they can decide what to do next (please not that the status of such bugs is unconfirmed and not assigned). A lot of bugs got marked with Area-Compat-* so the compatibility metric might be affected. I think I can continue the cleanup at least a little bit. However, if we could have a plan to deal with the bugs so that every bug gets proper attention and an owner, that would be great. --~--~-~--~~~---~--~~ 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: Please confirm the bug (some bitmaps aren/t displayed)
On Mon, Oct 12, 2009 at 20:53, Jeremy Orlow jor...@chromium.org wrote: I think the bigger issue is how/when Area-Misc bugs get triaged. Do they ever? If not, we should probably change that. I sometimes review old bugs and close those which no longer reproduce, and ask for more details in case they're needed (and add FeedbackRequested label). I plan to do another pass like this soon. However, indeed, it would be nice to better triage the bugs. I think we have a lot of forgotten ones in the tracker. --~--~-~--~~~---~--~~ 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 that unimpossible to add a progress bar of page loading with webkit?
On Fri, Oct 9, 2009 at 11:01, Jickae Davis jick...@gmail.com wrote: Well, I agree with PhistucK. I think a progress bar may help though it's not so accurate. By the way, if I want to add such a bar with chromium, how should I start? Is there a method that tells the size of the resources to be loaded and the size of the resources already loaded? If you're trying to debug some slow-loading pages, or slow-network issues, then about:net-internals page may be helpful. You can see outstanding requests there, as well as recently completed requests and which part of each request was most time-consuming etc. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] detecting tabs using a lot of CPU?
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] Re: detecting tabs using a lot of CPU?
On Wed, Oct 7, 2009 at 21:25, Jeremy Orlow jor...@chromium.org wrote: I could't imagine many users understanding a feature like this much less finding it particularly useful. That's right, an average user would be only confused. Just exposing this info (cpu-hungriness) to extensions seems interesting. What are the use cases? Well, I just didn't notice that the tab was using a lot of cpu (idle GMail tab). The system was responsive, as well as the browser itself and all tabs. But when you have other cpu-intensive tasks running in the background (and I had) such a tab drains the resources. The technical side (exposing the info to extensions) doesn't seem too hard. I'm thinking about implementing it. I'm not sure about the UI. For me it could be even something on the extension shelf (support for that already exists). Then it would be nice if I could kill the renderer process using too much resources, or even restart it. --~--~-~--~~~---~--~~ 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: SVN Stable Tree Path for 3.0.195.25
(adding people more familiar with the release process...) On Wed, Oct 7, 2009 at 20:16, Amit Kishnani akish...@adobe.com wrote: Hey Elliot, thanks for quick turnaround. the trunk (svn) : http://src.chromium.org/svn/trunk/src/chrome/VERSION is MAJOR=4 MINOR=0 BUILD=222 PATCH=1 but I am looking for stable channel - 3.0.195.125 release instead of dev channel, please let me know if there is svn repository link with that version stamp. Thanks! Amit. -Original Message- From: e...@google.com [mailto:e...@google.com] On Behalf Of Elliot Glaysher (Chromium) Sent: Wednesday, October 07, 2009 10:41 AM To: Amit Kishnani Cc: Chromium-dev Subject: Re: [chromium-dev] SVN Stable Tree Path for 3.0.195.25 The latest source is in trunk, not a specific release branch. -- Elliot On Tue, Oct 6, 2009 at 12:34 PM, Amit Kishnani akish...@adobe.com wrote: Hey Guys, what is difference between these releases 3.0.190.2 3.0.195.25 i can get to SVN source tree to read access for code tree 3.0.190.2 using the following svn repository url http://src.chromium.org/svn/releases/3.0.190.2/src/ i want to make sure i am getting the latest stable source tree , is there a better svn url to get latest 3.0.195.25. please advise. Thanks, Amit. --~--~-~--~~~---~--~~ 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 to deal with flaky unit tests
On Wed, Oct 7, 2009 at 02:02, Nicolas Sylvain nsylv...@chromium.org wrote: Once we start tagging the flaky tests, we will monitor the flakiness dashboard and make sure that a test that is no longer flaky has its FLAKY_ tag removed. It may be a good idea to expand the number of tests listed in the flakiness report from Top15 to Top20 or maybe even Top30... sometimes a test becomes only a bit less flaky, just enough to not appear in Top15. On the other hand, we have a lot of resource-related test failures (I don't know too much how Visual Studio's build system works - especially with gyp, but maybe someone will manage to investigate and fix that). This is not the fault of the test, just a bug in the build system. --~--~-~--~~~---~--~~ 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: flaky resource failures
On Fri, Sep 25, 2009 at 05:26, Thomas Van Lenten thoma...@chromium.orgwrote: On Thu, Sep 24, 2009 at 6:24 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: On Thu, Sep 24, 2009 at 12:24, Thomas Van Lenten thoma...@chromium.orgwrote: Brad landed support for depending on all the python files that go into grit, so that part would have worked. The not always rebuilding for .h files is the problem. Does it mean we're missing some deps in the gyp files? Shouldn't. The IDEs should be figuring out what .h files are included by each .cc/.m/.mm/.etc and rebuild as needed. The issue seems to occur only on Windows, which means Visual Studio. Isn't its dependency tracking known to be unreliable? I really don't know how it works (is there some docs which documents the quirks?). --~--~-~--~~~---~--~~ 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 failure in Chromium on Modules XP (dbg), revision 27248
Confirmed. It is flaky. I'm going to disable it when I have a while. Feel free to disable it earlier. On Fri, Sep 25, 2009 at 14:19, Eric Roman ero...@chromium.org wrote: Looks like FTPCacheURLCredentials is flaky; none of these changes touched that code... On Fri, Sep 25, 2009 at 2:14 PM, build...@chromium.org wrote: http://build.chromium.org/buildbot/waterfall/ Automatically closing tree for net_unittests on Modules XP (dbg) http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013 Revision: 27245, 27246, 27247, 27248 Blame list: ero...@chromium.org,ma...@chromium.org,m...@chromium.org, sh...@chromium.org Modules XP (dbg) Build 16013http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013 svnkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013/steps/shell_2/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013/steps/shell_3/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013/steps/gclient/logs/stdio compile base stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013/steps/compile/logs/stdio compile net stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013/steps/compile_2/logs/stdio compile sandbox stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013/steps/compile_3/logs/stdio base_unittests 2 disabled stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013/steps/base_unittests/logs/stdio net_unittests 8 disabled failed 1 stdiohttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013/steps/net_unittests/logs/stdio FTPCacheURLCredentialshttp://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013/steps/net_unittests/logs/FTPCacheURLCredentials Changed by: *ma...@chromium.org* Changed at: *Fri 25 Sep 2009 14:03:57* Branch: *src* Revision: *27245* Changed files: - *chrome/test/testing_profile.cc* Comments: Coverity: initialize created_theme_provider_ in the other constructor. CID=6160 BUG=none TEST=none Review URL: http://codereview.chromium.org/252002 Changed by: *ero...@chromium.org* Changed at: *Fri 25 Sep 2009 14:04:37* Branch: *src* Revision: *27246* Changed files: - *net/data/proxy_resolver_v8_unittest/pac_library_unittest.js* Comments: Add an additional test for dnsDomainIs() to verify that it doesn't simply match any substring. This is working correctly, but since it was failing in WinHTTP we should have a regression test. BUG=18511 Review URL: http://codereview.chromium.org/245008 Changed by: *...@chromium.org* Changed at: *Fri 25 Sep 2009 14:04:37* Branch: *src* Revision: *27247* Changed files: - *chrome/browser/gtk/browser_window_gtk.cc* - *chrome/browser/gtk/browser_window_gtk.h* - *chrome/browser/gtk/browser_titlebar.cc* Comments: Linux: work around browser windows that get stuck maximized by the WM. BUG=22807 TEST=none Review URL: http://codereview.chromium.org/218040 Changed by: *sh...@chromium.org* Changed at: *Fri 25 Sep 2009 14:05:27* Branch: *src* Revision: *27248* Changed files: - *chrome/browser/cocoa/autocomplete_text_field_cell.mm* Comments: [Mac] Fix depressed baseline in Omnibox. A previous change converted AutocompleteTextFieldCell to rely more on -drawingRectForBounds: rather than tweaking the baseline in an ad-hoc fashion in many places. This adds a place I missed. http://crbug.com/23096 TEST=Browse http://crbug.com/23096%0ATEST=Browse to www.google.com. When putting focus in the page the url should stay at the same spot as when focus is in the Omnibox. Review URL: http://codereview.chromium.org/242010 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] flaky resource failures
We still have problems with resources, examples: [FATAL:tab_renderer.cc(132)] Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. [FATAL:image_operations.cc(373)] Check failed: rgb.width() == alpha.width(). [FATAL:resource_bundle_win.cc(155)] Check failed: false. unable to find resource: 1495 [FATAL:resource_bundle_win.cc(152)] Check failed: false. unable to find resource: 1500 And of course these are intermittent. :( Can we rebuild the resources always, on Windows? I know it's going to increase the compile time. How much? --~--~-~--~~~---~--~~ 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: flaky resource failures
You can't clobber when it's flaky. I think I can extract the build ID from the flakiness report... On Thu, Sep 24, 2009 at 12:19, Tony Chang t...@chromium.org wrote: Which build was this? I checked in a change that changes how grit generates IDs. This type of change requires a clobber since I don't think we depend on all the grit .py files. I think these changes are rare enough that we can just clobber as needed. On Thu, Sep 24, 2009 at 12:03 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: We still have problems with resources, examples: [FATAL:tab_renderer.cc(132)] Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. [FATAL:image_operations.cc(373)] Check failed: rgb.width() == alpha.width(). [FATAL:resource_bundle_win.cc(155)] Check failed: false. unable to find resource: 1495 [FATAL:resource_bundle_win.cc(152)] Check failed: false. unable to find resource: 1500 And of course these are intermittent. :( Can we rebuild the resources always, on Windows? I know it's going to increase the compile time. How much? --~--~-~--~~~---~--~~ 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: flaky resource failures
On Thu, Sep 24, 2009 at 12:24, Thomas Van Lenten thoma...@chromium.orgwrote: Brad landed support for depending on all the python files that go into grit, so that part would have worked. The not always rebuilding for .h files is the problem. Does it mean we're missing some deps in the gyp files? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] debugging the browser started by UI tests
What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Webkit merges and tree closures
On Tue, Sep 22, 2009 at 17:40, Nicolas Sylvain nsylv...@chromium.orgwrote: 3 PM : two failing ui tests are disabled by the webkit sheriff I was looking at the UI tests and it wasn't immediately obvious that a webkit update might break them. Can we run all the UI tests on the webkit canary bot? If that takes too long, we can selectively exclude the slow tests, based on http://build.chromium.org/buildbot/slowness-report/ By the way, the layout test failures... can we catch them on the webkit canary bot(s)? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Dashboard to show which UI/unit/etc (non-webkit) tests are slowest
The slowness dashboard is ready at http://build.chromium.org/buildbot/slowness-report/ There are some problems with it (like garbage in test names), and it could possibly display more data (like median and stddev), but it's generally usable. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome Library for tweaking Windows Network Settings
You can mock the HostResolver to make it fail to resolve anything (possibly except localhost). For examples, see HostResolver's unit tests and possibly other places where it is used. You can also make it fail to resolve specific hosts, which should also be handy. On Tue, Sep 15, 2009 at 13:54, TJ Shah tejass...@chromium.org wrote: Hi, I am trying to automate few test cases that requires me to simulate certain scenarios like 'Network is down' or 'Sync server not reachable' etc.. I am not sure about the Chrome Library that I can use to play with Windows Network Settings. I am using InProcBrowser Test. Pointers to library or examples will be helpful... -- Thanks, Tejas --~--~-~--~~~---~--~~ 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] parasite is awesome
Looks like a good candidate for LinuxDebugging wiki page. On Wed, Sep 16, 2009 at 17:04, Evan Martin e...@chromium.org wrote: http://chipx86.github.com/gtkparasite/ We had looked into using parasite back in the early days, but I forgot about it due to 32/64-bit stuff. But now that we've grown up it's trivial to build. If you're within the Google network you can scp bunny.sfo:/usr/lib/gtk-2.0/modules/libgtkparasite.so /tmp sudo cp /tmp/libgtkparasite.so /usr/lib/gtk-2.0/modules/libgtkparasite.so and then GTK_MODULES=gtkparasite ./out/Debug/chrome And it'll just work. Pretty awesome! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] parasite is awesome
On Wed, Sep 16, 2009 at 17:22, Ian Fette i...@chromium.org wrote: Out of curiosity, could this be integrated in our testing framework to have less-flaky UI tests (at least for some subset of the functionality currently tested with UI tests)? I don't have idea how to use it for that purpose. I can certainly imagine a parasite which would make the tests more flaky though... ;-) The problem with UI tests is that the flakiness isn't really so much tied to the UI part. They are just big tests, and the main problem is waiting properly for events, and ensuring that the test is deterministic (Valgrind, Purify). Maybe the Parasite would be useful for things like dragging tabs, etc. - I'm not familiar enough with the tool to tell. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Avoiding DevToolsSanityTest bustages
DevToolsSanityTest flips frequently between enabled and disabled. It seems to be mostly caused by changes in WebKit. I see two nice ways to prevent that: - run the tests upstream on webkit.org bots (probably hard) - run the tests on our webkit canary bot (should be doable) What do you 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: Chromium core principles and multiplatform development?
For me it was obvious, but if people are surprised by this, then improving the documentation is probably a good idea. Just curious... the change has been submitted to trybots before landing, hasn't it? On Thu, Sep 10, 2009 at 10:03, Dan Kegel d...@kegel.com wrote: An external contributor was recently surprised that a change tested on linux was reverted because it broke the build on windows. (His mental model was that linux developers don't have to worry about other platforms, that's what windows developers are for.) He said that none of the doc at dev.chromium.org covered this, so I had a look. http://dev.chromium.org/developers/core-principles lists four core categories: Speed, Security, Stability, and Simplicity. Under Stability, it says We try to write as many automated tests as we can, to make sure that the product is still functioning as intended. We close the tree when the tests fail. We revert changes that break them. That seems to cover it, but it is a bit buried, and it doesn't really announce our commitment to full support of all three platforms. Anyone think we need to add some text that emphasizes that developers need to worry about more than just their own platform? --~--~-~--~~~---~--~~ 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 core principles and multiplatform development?
On Thu, Sep 10, 2009 at 10:16, Dan Kegel d...@kegel.com wrote: In this case, the code may have been submitted by a committer without using the trybots (tsk, tsk). We don't currently mention the trybots on dev.chromium.org. Is it time to? Submitting without trybots and breaking the compile? Doesn't look good to me. I think we should mention that all committers should use the trybots (they have access to them). --~--~-~--~~~---~--~~ 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 to use automation to do form submission?
I think you can execute javascript with automation (see
chrome/test/automation/tab_proxy.h). It is possible to submit forms using
javascript.
If you want to add a new automation request, see
chrome/test/automation_messages{,_internal}.h and add a new message there.
Then add a new call to TabProxy to send that message, and handle the message
in chrome/browser/automation/automation_provider.cc. Generally I think that
if you follow existing examples, this shouldn't be so hard. If you're going
to add more questions about this, please remember to be specific.
On Thu, Sep 10, 2009 at 13:28, hap 497 hap...@gmail.com wrote:
Hi,
From looking at tab_proxy.cc, there is a way to load the browser with
a specified URL:
TabProxy::NavigateToURL(const GURL url);
But Is there anyway to do a form submission to the browser (Http post
with form submission data)?
If there is no existing API for that purpose, how can I write my own
routine to achieve that?
I have looked at
chrome/test/automation/automation_messages_internal.h, I don't see
which message can be used for form submission.
Thank you for any help.
--~--~-~--~~~---~--~~
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: Announcing view-net-internal:
I like it! Like every feature which allows one to take a look under the hood. --~--~-~--~~~---~--~~ 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: Wanted: anonymous FTP servers running rare software
On Thu, Sep 10, 2009 at 15:54, Chris Evans cev...@chromium.org wrote: Sounds like a moderate amount of work. IMHO, it would be acceptable from a security standpoint to: 1) Fix any bugs turned up by fuzzing. Even then, I'd need some way to verify the validity of the fixes. Mozilla has some test data at http://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/converters/parse-ftp/but I'm not sure if it's complete, and it would be nice to test with real servers anyway. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Just got a backtrace from flaky RenderViewTest
So, RenderViewTest crashes very often. Now, thanks to maruel, we have a stack trace: [--] 16 tests from RenderViewTest [ RUN ] RenderViewTest.OnLoadAlternateHTMLText Backtrace: GetStackFrames [0x00FF6085+306229] _sbrk [0x00A7E5EE+70254] _sbrk [0x00A7E63E+70334] _sbrk [0x00A7E763+70627] _sbrk [0x00AB052E+274862] _sbrk [0x00A7EA20+71328] _sbrk [0x00A7EE50+72400] _sbrk [0x00A7F747+74695] (No symbol) [0x00431868] MallocExtension::SetMemoryReleaseRate [0x00924756+2127654] MallocExtension::SetMemoryReleaseRate [0x00925699+2131561] MallocExtension::SetMemoryReleaseRate [0x0091FCB5+2108549] MallocExtension::SetMemoryReleaseRate [0x00925E93+2133603] MallocExtension::SetMemoryReleaseRate [0x00925FFC+2133964] MallocExtension::SetMemoryReleaseRate [0x008CF119+1777897] MallocExtension::SetMemoryReleaseRate [0x008CF34E+1778462] (No symbol) [0x005D66E9] RegisterWaitForInputIdle [0x7C817067+73] Does anyone have some ideas why is it failing? --~--~-~--~~~---~--~~ 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: Are we going to support active FTP?
The bug is about a firewall forbidding the connection. Why the trick won't work? If I can't connect to the PASV port, I'd try PORT, even on successful PASV response. On Wed, Sep 9, 2009 at 12:52, Michal Zalewski lcam...@gmail.com wrote: I can't think of any. It would be nice to have active support. I'm not sure how easy it is to auto-detect which one we should use (since all the FTP clients I've ever used have forced me to specify manually). It should be fairly easy. Send the PASV command--if the server sends back a failure result code, fall back on active FTP and send a PORT command. Are we trying to solve the problem of the server having no passive FTP support (how common would that be?), or of the server's firewall / NAT device not having FTP traffic inspection helpers? If the latter, which I suspect might be marginally more common, just probing for PASV and falling over to active mode then is not going to do the trick. /mz --~--~-~--~~~---~--~~ 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 to run chromium with 'automation' enabled?
You can send automation messages directly, but AutomationProxy seems much more better for that to me. Of course if you don't have AutomationProvider on the browser side, then it's not going to work either way. On Fri, Sep 4, 2009 at 10:46, hap 497 hap...@gmail.com wrote: Can you please tell me how you remote control an instance of chromium without using Automation Proxy? Thank you. On Fri, Sep 4, 2009 at 2:15 AM, Simon Stewartsimon.m.stew...@gmail.com wrote: I thought that the AutomationProxy wasn't available in released versions of Chrome A look at the symbols exported by the chrome.dll suggests that this is the case. Simon On Thu, Sep 3, 2009 at 11:07 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Then probably you should just use AutomationProxy (directly, without UI test framework). Adapting tests would be harder - just build a small driver program to launch the browser in a similar way UI test does, and uses the AutomationProxy to send it NavigateToURL message. You may also want to take a look how page_cycler tests work. They just tell the browser to load a set of URLs. On Thu, Sep 3, 2009 at 13:25, hap 497 hap...@gmail.com wrote: Thank you. My goal is to remote control (e.g. load an url) a running instance of browser. That is why I am trying to run this AutomationProxyTest NavigateToURL to an running instance of browser. That is why I ask how can I run the 'TEST_F(AutomationProxyTest, NavigateToURL) ' Test case in automation_proxy_uitest.cc using the browser I start in XCode? On Thu, Sep 3, 2009 at 8:29 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: You need AutomationProxy for that. See the line server_.reset(CreateAutomationProxy(command_execution_timeout_ms_)); Please keep the discussion on the list. And I'll repeat my question: what is your goal? I might guess that you are trying to re-use the browser between test runs. It may be a bad example, but in that case there is a much better (and easier!) way to do that. On Wed, Sep 2, 2009 at 19:18, hap 497 hap...@gmail.com wrote: Thank you. I am doing this in XCode on MacOSX. I have commented out * LaunchBrowserAndServer() in UITest::Setup(); * CloseBrowserAndServer() in UITest::TearDown(); And then I start 'chrome' executable in my chrome xcode project. But how can I run the 'TEST_F(AutomationProxyTest, NavigateToURL) ' Test case in automation_proxy_uitest.cc using the browser I start in XCode? Thank you for your help again. On Wed, Sep 2, 2009 at 12:48 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I think you're on a good track then. Just see how the UI test launches the browser, and to the same manually. Then rip out the launching and shutdown of the browser out of ui_test.cc, and rewire that with the test case you want to run. I can explain in more detail if needed. But... what are you ultimately trying to accomplish? The automation is a tricky thing, and maybe I'll be able to recommend a better way when I see your goal. On Wed, Sep 2, 2009 at 12:45, hap 497 hap...@gmail.com wrote: Currently, I run the 'ui_tests --gtest_filter=Automation*'. This way, the test creates and tears down chromium for each test case. What I would like is 1. Launch an instance of chromium (with automation enable) 2. disable 'creates/tears down of chromium in chromium ui test 3. Execute 1 test case against that instance of chromium Thank you. On Wed, Sep 2, 2009 at 10:06 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Could you provide some more details? You can find some examples in chrome/test/ui/ui_test.cc (LaunchBrowserHelper). On Wed, Sep 2, 2009 at 09:40, hap 497 hap...@gmail.com wrote: Hi, Can you please tell me how can I run chromium with 'automation' enabled? Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: how to induce flakiness, episode 1326: misusing IN_PROC_BROWSER_TEST
After a talk with jcampan I think that the plan is to convert all the interactive_ui_tests to browser_tests and make the test launcher reusable. On Wed, Sep 2, 2009 at 12:27, Scott Violet s...@chromium.org wrote: If we can't mix the two types, then separate targets is going to be the only way to go. -Scott On Wed, Sep 2, 2009 at 10:47 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Nick, thanks for clear response. Actually, sync_integration_tests don't mix tests (that's good), but they don't use correct launcher (that's bad and will induce flakiness). See chrome/test/browser/browser_test_launcher_* files, and also how browser_tests binary is built in chrome.gyp. sync_integration_tests should use the same launcher. Maybe you can just include them in browser_tests? There is an easy way to add Win-specific tests to them. Here's my best try to clarify issues with interactive_ui_tests. They also need to use correct launcher for browser_tests to properly isolate them. However, they also contain UI tests. I'm not sure if it's possible to mix the two when using the browser_tests launcher, and if it won't make debugging harder (on Linux the launcher forks a process, and debugging launcher - forked UI test binary - browser process is going to be hard). I'm looking for some advice, generally from people who wrote the browser_tests launcher and maintain interactive_ui_tests. On Wed, Sep 2, 2009 at 10:24, Nick Carter n...@chromium.org wrote: sync_integration_tests should be only in proc browser tests. If it includes other types of tests, that's a mistake and they should be moved to the unit tests target. Could you share some details of what you've found, and what it would take to make these tests as robust as browser_tests? As background, the sync integration tests run against a live sync server, possibly a test server running the same code as the Google production servers, using real Google accounts. Currently the tests expect an external force (probably the python script we have) to provide it wish an sync server URL, user account, and password combo that is in a clean state. As a result, we run the tests one at a time currently. So carried state bugs in memory between individual tests are not presently risky. Eventually, I'd like to see a more normal setup with gtest driving execution of multiple tests, calling out to some external provider to get the sync server/account/password info, instead of having it passed in. Probably, the provider would reset/restart the server instance through some backdoor. The dependence on an external server is why we put these tests in their own executable; they should all be in-proc browser tests. - nick On Wed, Sep 2, 2009 at 9:44 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: So, here are the choices I currently see: - let each binary only use one kind of tests (probably both UI) - split each binary to only one kind of tests binaries (probably too much test binaries anyway) What do you think? I can help with the switch, just need a decision what kind of tests/split would be better. On Mon, Aug 31, 2009 at 11:44, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I don't quite know how to solve the problem. When IN_PROC_BROWSER_TEST is used, a launcher that will isolate the test cases should be used (like running them in forked processes or reloading a dll). However, currently only browser_tests binary does that. Other users, sync_integration_tests and interactive_ui_tests, don't. This is a fantastic recipe for flakiness. In-process browser test carries a lot of state, all the singletons, etc. It does cause problems if not cleaned up properly, and I removed that kind of problem from unit_tests (and introduced ALLOW_IN_PROC_BROWSER_TEST to prevent the problem from growing). The problem is, that the mentioned binaries mix UI tests with browser tests. So it's not trivially possible to use browser_tests launcher for them (or maybe it is?). What do you 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: how to run chromium with 'automation' enabled?
You need AutomationProxy for that. See the line server_.reset(CreateAutomationProxy(command_execution_timeout_ms_)); Please keep the discussion on the list. And I'll repeat my question: what is your goal? I might guess that you are trying to re-use the browser between test runs. It may be a bad example, but in that case there is a much better (and easier!) way to do that. On Wed, Sep 2, 2009 at 19:18, hap 497 hap...@gmail.com wrote: Thank you. I am doing this in XCode on MacOSX. I have commented out * LaunchBrowserAndServer() in UITest::Setup(); * CloseBrowserAndServer() in UITest::TearDown(); And then I start 'chrome' executable in my chrome xcode project. But how can I run the 'TEST_F(AutomationProxyTest, NavigateToURL) ' Test case in automation_proxy_uitest.cc using the browser I start in XCode? Thank you for your help again. On Wed, Sep 2, 2009 at 12:48 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I think you're on a good track then. Just see how the UI test launches the browser, and to the same manually. Then rip out the launching and shutdown of the browser out of ui_test.cc, and rewire that with the test case you want to run. I can explain in more detail if needed. But... what are you ultimately trying to accomplish? The automation is a tricky thing, and maybe I'll be able to recommend a better way when I see your goal. On Wed, Sep 2, 2009 at 12:45, hap 497 hap...@gmail.com wrote: Currently, I run the 'ui_tests --gtest_filter=Automation*'. This way, the test creates and tears down chromium for each test case. What I would like is 1. Launch an instance of chromium (with automation enable) 2. disable 'creates/tears down of chromium in chromium ui test 3. Execute 1 test case against that instance of chromium Thank you. On Wed, Sep 2, 2009 at 10:06 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Could you provide some more details? You can find some examples in chrome/test/ui/ui_test.cc (LaunchBrowserHelper). On Wed, Sep 2, 2009 at 09:40, hap 497 hap...@gmail.com wrote: Hi, Can you please tell me how can I run chromium with 'automation' enabled? Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: how to run chromium with 'automation' enabled?
Then probably you should just use AutomationProxy (directly, without UI test framework). Adapting tests would be harder - just build a small driver program to launch the browser in a similar way UI test does, and uses the AutomationProxy to send it NavigateToURL message. You may also want to take a look how page_cycler tests work. They just tell the browser to load a set of URLs. On Thu, Sep 3, 2009 at 13:25, hap 497 hap...@gmail.com wrote: Thank you. My goal is to remote control (e.g. load an url) a running instance of browser. That is why I am trying to run this AutomationProxyTest NavigateToURL to an running instance of browser. That is why I ask how can I run the 'TEST_F(AutomationProxyTest, NavigateToURL) ' Test case in automation_proxy_uitest.cc using the browser I start in XCode? On Thu, Sep 3, 2009 at 8:29 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: You need AutomationProxy for that. See the line server_.reset(CreateAutomationProxy(command_execution_timeout_ms_)); Please keep the discussion on the list. And I'll repeat my question: what is your goal? I might guess that you are trying to re-use the browser between test runs. It may be a bad example, but in that case there is a much better (and easier!) way to do that. On Wed, Sep 2, 2009 at 19:18, hap 497 hap...@gmail.com wrote: Thank you. I am doing this in XCode on MacOSX. I have commented out * LaunchBrowserAndServer() in UITest::Setup(); * CloseBrowserAndServer() in UITest::TearDown(); And then I start 'chrome' executable in my chrome xcode project. But how can I run the 'TEST_F(AutomationProxyTest, NavigateToURL) ' Test case in automation_proxy_uitest.cc using the browser I start in XCode? Thank you for your help again. On Wed, Sep 2, 2009 at 12:48 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I think you're on a good track then. Just see how the UI test launches the browser, and to the same manually. Then rip out the launching and shutdown of the browser out of ui_test.cc, and rewire that with the test case you want to run. I can explain in more detail if needed. But... what are you ultimately trying to accomplish? The automation is a tricky thing, and maybe I'll be able to recommend a better way when I see your goal. On Wed, Sep 2, 2009 at 12:45, hap 497 hap...@gmail.com wrote: Currently, I run the 'ui_tests --gtest_filter=Automation*'. This way, the test creates and tears down chromium for each test case. What I would like is 1. Launch an instance of chromium (with automation enable) 2. disable 'creates/tears down of chromium in chromium ui test 3. Execute 1 test case against that instance of chromium Thank you. On Wed, Sep 2, 2009 at 10:06 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Could you provide some more details? You can find some examples in chrome/test/ui/ui_test.cc (LaunchBrowserHelper). On Wed, Sep 2, 2009 at 09:40, hap 497 hap...@gmail.com wrote: Hi, Can you please tell me how can I run chromium with 'automation' enabled? Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] detect problems with resources right away
The flakiness with resources has hugely decreased since I landed my infamous hook, but it's still there. I'm not sure what really happens, so I'm thinking about a special build step (before UI tests etc), which would verify that all the expected resources are present in the bundle and then fail. That is more easily recognizable than a flaky test failure, and clearly indicates a bug in the build system (and hopefully the right commit). The question is - how to enumerate all claimed resources? Is looking at all .grd files sufficient? --~--~-~--~~~---~--~~ 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: detect problems with resources right away
Seems good. Nice job! I hope it will eradicate this kind of flakiness. On Thu, Sep 3, 2009 at 17:37, Bradley Nelson bradnel...@google.com wrote: Hi Pawel, I'm in the process of landing a change which will add grit_info.py, which will let you list all of the inputs and outputs from a .grd file. Initially I'll be using the inputs to fix some of the dependencies. Does this cover your concerns? http://codereview.chromium.org/197007/show -BradN On Thu, Sep 3, 2009 at 5:30 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: The flakiness with resources has hugely decreased since I landed my infamous hook, but it's still there. I'm not sure what really happens, so I'm thinking about a special build step (before UI tests etc), which would verify that all the expected resources are present in the bundle and then fail. That is more easily recognizable than a flaky test failure, and clearly indicates a bug in the build system (and hopefully the right commit). The question is - how to enumerate all claimed resources? Is looking at all .grd files sufficient? --~--~-~--~~~---~--~~ 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 to induce flakiness, episode 1326: misusing IN_PROC_BROWSER_TEST
So, here are the choices I currently see: - let each binary only use one kind of tests (probably both UI) - split each binary to only one kind of tests binaries (probably too much test binaries anyway) What do you think? I can help with the switch, just need a decision what kind of tests/split would be better. On Mon, Aug 31, 2009 at 11:44, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: I don't quite know how to solve the problem. When IN_PROC_BROWSER_TEST is used, a launcher that will isolate the test cases should be used (like running them in forked processes or reloading a dll). However, currently only browser_tests binary does that. Other users, sync_integration_tests and interactive_ui_tests, don't. This is a fantastic recipe for flakiness. In-process browser test carries a lot of state, all the singletons, etc. It does cause problems if not cleaned up properly, and I removed that kind of problem from unit_tests (and introduced ALLOW_IN_PROC_BROWSER_TEST to prevent the problem from growing). The problem is, that the mentioned binaries mix UI tests with browser tests. So it's not trivially possible to use browser_tests launcher for them (or maybe it is?). What do you 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] please use FlakyTest label and file flakiness bugs
If you disable a flaky test, please file a bug if needed, and assign a FlakyTest label (I'm automatically CC-ed). This way I can easily search for it. Sometimes a flakiness pattern is more clearly visible then, and it helps. Thanks! --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] RWX sections in the binary
Chromium gives this notice when compiling on Gentoo: QA Notice: The following files contain writable and executable sections Files with such sections will not work properly (or at all!) on some architectures/operating systems. A bug should be filed at http://bugs.gentoo.org/ to make sure the issue is fixed. For more information, see http://hardened.gentoo.org/gnu-stack.xml Please include the following list of files in your report: Note: Bugs should be filed for the respective maintainers of the package in question and not harde...@g.o. RWX --- --- opt/chromium/chrome Are the writable and executable sections required for Chromium? I can provide more specific information about this warning and Gentoo policy if needed. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Creating a SkBitmap filled with one color
How do I create a SkBitmap of arbitrary size, filled with color of my choice (on Linux)? I'd need that for Linux extension shelf, and the Windows code for that seems not easily portable to Linux. --~--~-~--~~~---~--~~ 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: Subversion tags for stable/beta/dev?
Seconded. Tags would make my work on packaging for Gentoo much easier. On Wed, Aug 26, 2009 at 15:51, Aaron Boodman a...@chromium.org wrote: Checking up on this. I don't see the tags in src.chromium.org yet. Can we get this going for the next dev release? - a On Tue, Aug 11, 2009 at 1:30 PM, Aaron Boodmana...@chromium.org wrote: Hooray, thanks Mark. - a On Tue, Aug 11, 2009 at 1:22 PM, Mark Larson (Google)m...@chromium.org wrote: Yes, I think we can add something so each channel has a persistent URL. I'll discuss with Aaron offline. On Sat, Aug 8, 2009 at 00:17, Darin Fisher da...@chromium.org wrote: On Fri, Aug 7, 2009 at 11:59 PM, Aaron Boodman a...@chromium.org wrote: Ok, sorry I got defensive. Short answer is we don't know if it can handle the load. I will add a bug to myself to investigate. Oh, I didn't think you were overly defensive... Do you have any opinion on adding the tags? I guess the cost would be that when we do new releases the release manager would have to update the tag. It sounds like a reasonable request to me. -Darin - a On Fri, Aug 7, 2009 at 11:45 PM, Darin Fisherda...@chromium.org wrote: I totally agree. Reducing the cost of maintaining docs is very nice indeed ;-) -Darin On Fri, Aug 7, 2009 at 11:36 PM, Aaron Boodman a...@chromium.org wrote: We can put a cache in front of it if needed. Actually I'd like to put something dumb and simple in front of it anyway, so we could have shorter URLs that aren't tied to viewvc. But I think having the docs be checked in and not having a separate deploy step is worth some extra complexity on the frontend. In Gears the docs being out of date, or out of sync with the various versions was an annoying problem. - a On Fri, Aug 7, 2009 at 9:55 PM, Darin Fisherda...@chromium.org wrote: This is pretty cool, but my experience with ViewVC is that it is kind of slow. Do we know if it can handle the additional load this will generate? -Darin On Fri, Aug 7, 2009 at 3:23 PM, Aaron Boodman a...@chromium.org wrote: Hi all, I was wondering if the release managers could add a tag in Subversion for each of the stable, beta, and dev release channels. I want a ViewVC URL that I can give people that will always refer to the version of the code that is on stable (or whatever) at that moment. The reason I want to do this is because the extensions possee is checking our docs into source control, so that they can be viewed live from viewvc. They're still in progress, but you can see them starting to come together here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/index.html The cool thing about this approach is that when we branch releases, the docs from trunk will be branched too. So the docs for a certain release area always with the code for that release. If we had the aforementioned tags, the canonical URL for, eg, the stable extension docs could just be: http://src.chromium.org/viewvc/chrome/branches/stable/src/chrome/common/extensions/docs/index.html - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Creating a SkBitmap filled with one color
Thanks for all the answers, especially the first one from erg. I'm going to use Skia, because another method (SetBackground in RWHV) requires that. On Wed, Aug 26, 2009 at 16:33, Tony Chang t...@chromium.org wrote: There's an example of how to do this with skia in src/app/resource_bundle.cc around line 146. That said, you should use cairo to paint in GTK. On Wed, Aug 26, 2009 at 4:27 PM, Dean McNamee de...@chromium.org wrote: To answer the technical (non-political) part of this question. Create a SkBitmap which backs to some pixels. Create a SkCanvas on top of it. Call drawPaint or more directly drawColor. On Wed, Aug 26, 2009 at 4:17 PM, Nico Weber tha...@chromium.org wrote: When I talked with Aaron, he said porting the shelf to OS X isn't something I should tackle unless I'm _really_ running out of things to do, since they're not even sure they're going to keep it. Has this changed, or is the situation different on linux for some reason? Nico On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: How do I create a SkBitmap of arbitrary size, filled with color of my choice (on Linux)? I'd need that for Linux extension shelf, and the Windows code for that seems not easily portable to Linux. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] forbidding IN_PROC_BROWSER_TESTS in unit_tests
I'm in the middle of debugging a problem which is caused by singletons. It's a very bad category of problems, because the results are initially very mysterious, until you discover that it's a singleton which carries state from one test to another. Browser tests carry a lot of state. The entire browser is started. So browser_tests launcher makes sure that the test cases are well isolated (for example it forks the process on Linux). However, I caught at least one case when IN_PROC_BROWSER_TESTS is used in unit_tests binary. It works so far, but after adding more strict checks in NotificationRegistrar (long story, I can explain if you wish) it breaks. I'm now preparing to move the file where it belongs: to browser_tests. However, it would be nice to have a flag which would enable IN_PROC_BROWSER_TEST only for browser_tests to prevent similar misuse. Like -DENABLE_IN_PROC_BROWSER_TEST or similar. What do you 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: forbidding IN_PROC_BROWSER_TESTS in unit_tests
On Tue, Aug 25, 2009 at 16:08, Evan Stade est...@chromium.org wrote: uh, for which binaries are in proc browser tests allowed? I know there is one in interactive_ui_tests and it was causing problems (which caused me to go and use the code to not use statics). BrowserFocusUITests was the one. For now they're allowed for all binaries, but that's bad and I'm going to change that. Also, and I am to blame for this one, view_id_util_unittest.cc is an in-proc browser test running on unit_tests right now. It's now being changed on the trunk. --~--~-~--~~~---~--~~ 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: forbidding IN_PROC_BROWSER_TESTS in unit_tests
I think it should only be allowed in tests that use a launcher which will properly isolate test cases. Currently interactive_ui_tests use in-proc tests. To make transition easier, I'm going to allow in-proc in them, but try to get rid of it finally (or make the launcher safer). On Tue, Aug 25, 2009 at 16:36, Evan Stade est...@chromium.org wrote: On Tue, Aug 25, 2009 at 4:15 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: On Tue, Aug 25, 2009 at 16:08, Evan Stade est...@chromium.org wrote: uh, for which binaries are in proc browser tests allowed? I know there is one in interactive_ui_tests and it was causing problems (which caused me to go and use the code to not use statics). BrowserFocusUITests was the one. For now they're allowed for all binaries, but that's bad and I'm going to change that. right, by allowed I mean should be allowed Also, and I am to blame for this one, view_id_util_unittest.cc is an in-proc browser test running on unit_tests right now. It's now being changed on the trunk. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: PSA: do not include X_messages.h in other headers
Cool! Thanks so much. I'm going to write a presubmit check for that. On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek j...@chromium.org wrote: Including files like render_messages.h and automation_messages.h from other header files is unnecessary and slows down the build (adds about ~100K lines of headers to each cc file). Last time I removed all these occurrences, it improved the build time by 15%. Looks like a few more crept in now, so I'm removing them. Please be careful not to reintroduce this, and look out for this in code reviews (yes, it would be great to have an automated way of catching this, patches welcome). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
On Thu, Aug 20, 2009 at 16:02, Peter Kasting pkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.orgwrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? You can use iosfwd and implement the operator in the .cc file. I actually recommend doing it that way. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
