[chromium-dev] buildbot failure in Chromium on XP Tests, revision 36626
Automatically closing tree for unit_tests on XP Tests http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16523 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests --= Automatically closing tree for unit_tests on XP Tests =-- Revision: 36626 Blame list: phajdan...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] [LTTF] Q1 Plan
Greetings, people of Chromium! Last quarter, the Layout Test Task Force done some pretty good work. I bragged about it in a separate email. Now it's time to grab the bull by the horns and kick it up a notch. Isn't idiomatic English great? This quarter, the LTTF is aiming right at the heart of the problem: eliminating the need to continually roll WebKit DEPS, baking in layers upon layers of regressions in the phyllo dough that is our test_expectations file. To do that, we must move all of our layout test infrastructure, from test_shell to test expectations to flakiness dashboard upstream. Based on a few hallway/online/cross-continental conversations, our plan of action consists of three efforts (drivers in parentheses): - Port test_shell into DumpRenderTree (DRT) upstream (Tokyo LTTF team + dglazkov + darin) - Take care of chromium dependencies: base, net, skia (src/skia, that is). How will they manifest themselves upstream to avoid breakage due to changes in chromium tree? (dglazkov, darin, tc) - Identify strategy for DRT and V8 coexistence: currently all of DRT is heavily JSC-dependent. We should either introduce script-independent abstractions or convert to NPAPI that we use downstream (dglazkov, darin, tc). - Figure out for inflight testing. How will we ensure that porting doesn't introduce new bugs? Need to come up with a way to have a workable DRT quickly, and a way to produce differential of layout test failures to quickly find porting bugs. - Upstream src/webkit/tools/test_shell to WebKitTools/DumpRenderTree/chromium. - Coordinate with harness upstreaming effort, so that both run-webkit-tests and the new DRT work well together while porting. - Determine how we will remove code downstream. We won't need DRT-specific code, but may still need test_shell as a minimum-capabilities embedder of WebKit. Or we could go with a MiniBrowser-style project (open-source sample for WebKit Apple port) upstream. - Drive effort to completion. *Completion is*: DRT is ready to run layout tests on build.webkit.org, downstream cleaned up and ready to stop running layout tests on build.chromium.org. - Upstream test infrastructure (watch detailed plan and assignments develop at http://dev.chromium.org/developers/design-documents/upstreaminglayouttests). Steps include: - Move run_webkit_tests.py to live upstream - While DRT is being upstreamed, configure to run upstreamed run_webkit_tests on the Chromium builders - Move test expectations upstream - Move ancilliary tools, like rebaseline.py and flakiness dashboard upstream - Modify run_webkit_tests to use the newly upstreamed DRT - Drive effort to completion. *Completion is*: build.webkit.org is running layout tests with no regressions from downstream, build.chromium.org no longer runs layout tests. - Continue fixing/deflakifying layout tests and improving the process for sustaining compatibility. - Fix chrome-specific failures that dramatically affect compatibility (bug triage -- which means *you*!) - Fix SVG/Skia bugs that cause layout test failures (Waterloo team) - Fix V8 bugs and develop ES5 features that affect layout tests (V8 team) - Make V8 bindings more tolerant to IDL/JSC changes. Watch the effort as a bug tree: https://bugs.webkit.org/showdependencytree.cgi?id=32630hide_resolved=0 (japhet, kkanetkar) - Improve gardening tools and process (dglazkov) - Eliminate layout test flakiness (jparent, ojan, dglazkov) - Drive effort to completion. *Completion is*: 10 sustained layout test failures or flakes, bindings-related regressions/breaks are limited to custom code only, new process for keeping up for layout test regressions is adopted by Webkit Gardeners. As you can see, it's a bit different from grab a test and fix it approach we took in Q4. We learn, right? :) Despite most tasks having a driver in one form or another, we always welcome your contributions. Every little bit counts. :DG -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Vista Tests, revision 36632
Automatically closing tree for unit_tests on Vista Tests http://build.chromium.org/buildbot/waterfall/builders/Vista%20Tests/builds/15332 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Vista%20Tests --= Automatically closing tree for unit_tests on Vista Tests =-- Revision: 36629, 36630, 36631, 36632 Blame list: craig.schlen...@chromium.org,j...@chromium.org,phajdan...@chromium.org,thoma...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium XP, revision 36641
Automatically closing tree for compile on Chromium XP http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/9782 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP --= Automatically closing tree for compile on Chromium XP =-- Revision: 36639, 36640, 36641 Blame list: a...@chromium.org,kuch...@chromium.org,willc...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium Builder (dbg), revision 36644
Automatically closing tree for compile on Chromium Builder (dbg) http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29 --= Automatically closing tree for compile on Chromium Builder (dbg) =-- Revision: 36644 Blame list: jor...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- 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 Chromium Builder (dbg), revision 36644
on it. Sorry. On Wed, Jan 20, 2010 at 10:52 AM, build...@chromium.org wrote: http://build.chromium.org/buildbot/waterfall/ Automatically closing tree for compile on Chromium Builder (dbg) http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729 Revision: 36644 Blame list: jor...@chromium.org Chromium Builder (dbg) Build 15729http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729 svnkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729/steps/shell_1/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729/steps/shell_2/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729/steps/gclient/logs/stdio compile failed stdiohttp://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729/steps/compile/logs/stdio Changed by: *jor...@chromium.org* Changed at: *Wed 20 Jan 2010 10:50:07* Branch: *src* Revision: *36644*http://src.chromium.org/viewvc/chrome?view=revrevision=36644 Changed files: - *chrome/app/generated_resources.grd* - *chrome/browser/cookies_tree_model.cc* - *chrome/browser/cookies_tree_model.h* - *chrome/browser/gtk/options/cookies_view.cc* - *chrome/browser/gtk/options/cookies_view.h* - *chrome/browser/in_process_webkit/dom_storage_context.cc* - *chrome/browser/in_process_webkit/dom_storage_context.h* - *chrome/browser/views/options/cookies_view.cc* - *chrome/browser/views/options/cookies_view.h* - *chrome/chrome_browser.gypi* - *chrome/chrome_tests.gypi* Comments: Adds local storage nodes to cookie tree model and cookies view. BUG=none TEST=The show cookie dialog box should have a new node local storage when appropriate. When selected, it should display details of local storage (name, size on disk, last modified) in the details frame. Landing for Marcus Original CL: http://codereview.chromium.org/523139/show Review URL: http://codereview.chromium.org/546081 Properties: -- 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: WebKitApi (test_shell) and DevTools, JS debugging
Hi, It seems I've already found an answer - JS debugger is viable under test_shell after a small change: Index: WebViewImpl.cpp === --- WebViewImpl.cpp (revision 53449) +++ WebViewImpl.cpp (working copy) @@ -234,7 +234,11 @@ 0)); m_page-backForwardList()-setClient (m_backForwardListClientImpl); -m_page-setGroupName(pageGroupName); + +char pageGroupNameCurr[100]; +static int i = 1; +sprintf(pageGroupNameCurr, default%d, i++); +m_page-setGroupName(pageGroupNameCurr); } WebViewImpl::~WebViewImpl() There is a short description: When hitting a breakpoint, WebKit pauses all active DOM elements in the current Page group. Chrome uses only one page group for all pages, that's why WebKit pauses all active DOM elements including these one that belong to DevTools page. Ideally, I think it would be better to provide an ability to set Page Group name through WebKit API and set custom Page group name for DevTools page. As far as one of WebKit API goals is to allow third-party developers to build their own apps on it, do you think it will be useful to extend WebKit API in this way? Regards, Vadim Ridosh On Jan 18, 7:16 pm, vridosh vrid...@gmail.com wrote: Hi, I'm going to start my project based on WebKit API and planning to use test_shell as a reference implementation. I also want to use DevTools to allow end-user to debug HTML and especially JavaScript. Could you please tell how viable is the JS debugger in test_shell/ WebKit API? As far as I understand, in case of breakpoint V8 debugger stops the script execution on the whole process. That problem could be easy reproduced while running Chrome in single-process mode (AFAIR, this mode is obsolete for modern Chromium browser) - trying to pause script execution pauses all JS code, including DevTools JS code too, which causes deadlock - script couldn't be resumed anymore. As far as I understand, that's why Debugger tab was not available in test_shell in early Chromium builds. But when I tried to use current test_shell build, I was able to pause JS execution on breakpoint and then resume JS again. From the other hand, while staying on JS breakpoint not all parts of DevTools debugger works well - f.e. I couldn't execute JS in console. Also, as I got, pausing JS in any custom place (I mean, left button just above watch expressions and call stack) not implemented yet it all. So, the main question is - is it possible at all to make DevTools JS debugger in test_shell to work correctly? I'd appreciate any suggestions. Regards, Vadim Ridosh -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[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
[chromium-dev] Moving mailing lists from @googlegroups.com to @chromium.org
This is a heads up that as part of moving all of our resources to chromium.org (and vanity!), I'll be switching our mailing lists to be under chromium.org today. I will send an email when it's done, but for now you may want to update your rules to be either googlegroups.com or chromium.orgso that no emails are mislabelled. Note that unfortunately there's no way to migrate the old messages. So I will subscribe the googlegroups.com lists to the chromium.org ones so that googlegroups has all the emails. Please bear with me through the move. -- 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
1) if there is a ':' in the URI, you split the URI into scheme and scheme-specific part. No. The first check is is this an absolute file path. That check is done with platform-specific logic: #if windows if the path matches letter:\ or \\... #else if the path starts with a slash #endif Then we load it as an absolute file. Otherwise we load it as a URL relative to file:///[pwd] --BDS -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on XP Tests, revision 36652
Automatically closing tree for unit_tests on XP Tests http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16535 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests --= Automatically closing tree for unit_tests on XP Tests =-- Revision: 36651, 36652 Blame list: jor...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- 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: Moving mailing lists from @googlegroups.com to @chromium.org
Just to explain to everyone the steps that I will follow. For each mailing list, I will: 1) create a corresponding list on chromium.org with the same members 2) subscribe the old list to the new list so that the archives can be searched in one place 4) disable posting to the old list (only group managers can post) 3) send an email to the old list telling everyone that it's now disabled and that they must now post to the new list On Wed, Jan 20, 2010 at 11:08 AM, John Abd-El-Malek j...@chromium.orgwrote: This is a heads up that as part of moving all of our resources to chromium.org (and vanity!), I'll be switching our mailing lists to be under chromium.org today. I will send an email when it's done, but for now you may want to update your rules to be either googlegroups.com or chromium.org so that no emails are mislabelled. Note that unfortunately there's no way to migrate the old messages. So I will subscribe the googlegroups.com lists to the chromium.org ones so that googlegroups has all the emails. Please bear with me through the move. -- 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 10:57 AM, Paweł Hajdan, Jr. phajdan...@chromium.org wrote: 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. Omaha doesn't support manual authentication for proxies, so if your squid proxy is requiring a username/password that could be the problem. A good way to debug is to capture the traffic with wireshark and see what requests the installer issued. -- 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] buildbot failure in Chromium on Modules XP (dbg), revision 36693
Automatically closing tree for net_unittests on Modules XP (dbg) http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/21889 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP%20%28dbg%29 --= Automatically closing tree for net_unittests on Modules XP (dbg) =-- Revision: 36692, 36693 Blame list: c...@chromium.org,e...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Webkit Builder (dbg), revision 36699
Automatically closing tree for compile on Webkit Builder (dbg) http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Builder%20%28dbg%29/builds/22831 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Builder%20%28dbg%29 --= Automatically closing tree for compile on Webkit Builder (dbg) =-- Revision: 36698, 36699 Blame list: dpra...@chromium.org,fin...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Linux Perf (1), revision 36702
Automatically closing tree for compile on Linux Perf (1) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf%20%281%29/builds/5173 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Perf%20%281%29 --= Automatically closing tree for compile on Linux Perf (1) =-- Revision: 36697, 36698, 36699, 36702 Blame list: c...@chromium.org,dpra...@chromium.org,fin...@chromium.org,kka...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Chromium-dev switched to @chromium.org
Hello, The chromium-dev mailing list has now been switched to chromium-...@chromium.org. Please update your filters and address book accordingly. Existing members have been subscribed, with the exception of users who don't permit managers to add them to a group. You can visit the new group at http://groups.google.com/a/chromium.org/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] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 36724
Automatically closing tree for compile on Linux Builder (ChromiumOS) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/2488 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29 --= Automatically closing tree for compile on Linux Builder (ChromiumOS) =-- Revision: 36663, 36664, 3, 36667, 36668, 36669, 36670, 36671, 36675, 36676, 36677, 36679, 36681, 36682, 36683, 36684, 36686, 36687, 36688, 36689, 36691, 36692, 36693, 36695, 36696, 36697, 36698, 36699, 36702, 36703, 36704, 36706, 36707, 36708, 36709, 36710, 36711, 36715, 36716, 36718, 36719, 36720, 36721, 36722, 36723, 36724 Blame list: a...@chromium.org,apatr...@chromium.org,c...@chromium.org,cmas...@google.com,c...@chromium.org,dpra...@chromium.org,est...@chromium.org,e...@chromium.org,fin...@chromium.org,hc...@chromium.org,jcam...@chromium.org,jhawk...@chromium.org,kka...@chromium.org,kuch...@chromium.org,micha...@chromium.org,mpcompl...@chromium.org,osh...@chromium.org,pinker...@chromium.org,s...@chromium.org,tha...@chromium.org,xiy...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- 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: Moving mailing lists from @googlegroups.com to @chromium.org
Note: I've converted chromium-bugs, chromium-checkins, chromium-dev, and chomium-os-checkins. I'll convert the rest tomorrow. It seems that there are some issues with groups and I've emailed the team before I convert any more lists. People who were not receiving email before might start receiving them. Everyone on chromium-dev also is marked for moderation without a reason. Trying to fix both of these issues. On Wed, Jan 20, 2010 at 1:14 PM, John Abd-El-Malek j...@chromium.org wrote: Just to explain to everyone the steps that I will follow. For each mailing list, I will: 1) create a corresponding list on chromium.org with the same members 2) subscribe the old list to the new list so that the archives can be searched in one place 4) disable posting to the old list (only group managers can post) 3) send an email to the old list telling everyone that it's now disabled and that they must now post to the new list On Wed, Jan 20, 2010 at 11:08 AM, John Abd-El-Malek j...@chromium.orgwrote: This is a heads up that as part of moving all of our resources to chromium.org (and vanity!), I'll be switching our mailing lists to be under chromium.org today. I will send an email when it's done, but for now you may want to update your rules to be either googlegroups.com or chromium.org so that no emails are mislabelled. Note that unfortunately there's no way to migrate the old messages. So I will subscribe the googlegroups.com lists to the chromium.org ones so that googlegroups has all the emails. Please bear with me through the move. -- 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
[chromium-dev] buildbot failure in Chromium on Webkit, revision 36741
Automatically closing tree for update on Webkit http://build.chromium.org/buildbot/waterfall/builders/Webkit/builds/17270 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit --= Automatically closing tree for update on Webkit =-- Revision: 36741 Blame list: dpra...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
