[chromium-dev] Re: flaky resource failures
On Thu, Sep 24, 2009 at 6:24 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: 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. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode flag is set. If the Kiosk mode is set ( iexplorer.exe -k http://www.google.com ) it renders it as IE Renderer. It renders it fine in a Chrome Frame if its not in Kiosk mode. That must be a bug :) For IE, kiosk mode has a context menu, but people usually apply the registry tweak to remove context menu from IE if they need to. For Chromium, it would be nice if stuff like this would be an extension, an extension should allow us to show/hide various parts of the UI. In the meantime, I quickly compiled a custom Chromium so that my CEO and VP could see the benefits of using Chrome instead of IE on some of our web products. Stuff that would be cool and would be very lightweight to include for kiosk mode would be: - No Status Bar- Full Screen (with no exit, only alt+f4 should work) - No Context Menus (should be an option) - Disable downloading of files. - No tabs - No opening files - many more I would rather that be an extension (but there are currently no way to actually block users to remove extensions, maybe blocking users entering a url would suffice) but not possible currently. -Mohamed On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi a...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher da...@chromium.org wrote: Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. Chrome Frame can/will offer control over the context menu. This is exactly the kind of customization Chrome Frame can offer. Too bad we don't have Linux, Mac versions yet, but we are open source now so patches welcome :) -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.org wrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.orgwrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.orgwrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
You can create a content script that will disable the shortcut keys of the browser and the right clicks, on all of the pages.About browsing to other pages (and so, downloading), you can apply a rule within a content script to always navigate to the home page of what you need, when going to any other URL. That would solve most of the issues you have in that list. ☆PhistucK On Fri, Sep 25, 2009 at 15:30, Mohamed Mansour m...@chromium.org wrote: I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode flag is set. If the Kiosk mode is set ( iexplorer.exe -k http://www.google.com ) it renders it as IE Renderer. It renders it fine in a Chrome Frame if its not in Kiosk mode. That must be a bug :) For IE, kiosk mode has a context menu, but people usually apply the registry tweak to remove context menu from IE if they need to. For Chromium, it would be nice if stuff like this would be an extension, an extension should allow us to show/hide various parts of the UI. In the meantime, I quickly compiled a custom Chromium so that my CEO and VP could see the benefits of using Chrome instead of IE on some of our web products. Stuff that would be cool and would be very lightweight to include for kiosk mode would be: - No Status Bar- Full Screen (with no exit, only alt+f4 should work) - No Context Menus (should be an option) - Disable downloading of files. - No tabs - No opening files - many more I would rather that be an extension (but there are currently no way to actually block users to remove extensions, maybe blocking users entering a url would suffice) but not possible currently. -Mohamed On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi a...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher da...@chromium.orgwrote: Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. Chrome Frame can/will offer control over the context menu. This is exactly the kind of customization Chrome Frame can offer. Too bad we don't have Linux, Mac versions yet, but we are open source now so patches welcome :) -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.org wrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.orgwrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.orgwrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
What are the major issues?Full screen with no escape hatch and no status bubble? Chrome developers already said the are willing to take care of those\accept patches for those. The rest are taken care of with disabling keyboard shortcuts, or am I wrong? ☆PhistucK On Fri, Sep 25, 2009 at 15:44, Mohamed Mansour m...@chromium.org wrote: The minor issues, yes, the major issues, no. -Mohamed On Fri, Sep 25, 2009 at 8:40 AM, PhistucK phist...@gmail.com wrote: You can create a content script that will disable the shortcut keys of the browser and the right clicks, on all of the pages.About browsing to other pages (and so, downloading), you can apply a rule within a content script to always navigate to the home page of what you need, when going to any other URL. That would solve most of the issues you have in that list. ☆PhistucK On Fri, Sep 25, 2009 at 15:30, Mohamed Mansour m...@chromium.org wrote: I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode flag is set. If the Kiosk mode is set ( iexplorer.exe -k http://www.google.com ) it renders it as IE Renderer. It renders it fine in a Chrome Frame if its not in Kiosk mode. That must be a bug :) For IE, kiosk mode has a context menu, but people usually apply the registry tweak to remove context menu from IE if they need to. For Chromium, it would be nice if stuff like this would be an extension, an extension should allow us to show/hide various parts of the UI. In the meantime, I quickly compiled a custom Chromium so that my CEO and VP could see the benefits of using Chrome instead of IE on some of our web products. Stuff that would be cool and would be very lightweight to include for kiosk mode would be: - No Status Bar- Full Screen (with no exit, only alt+f4 should work) - No Context Menus (should be an option) - Disable downloading of files. - No tabs - No opening files - many more I would rather that be an extension (but there are currently no way to actually block users to remove extensions, maybe blocking users entering a url would suffice) but not possible currently. -Mohamed On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi a...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher da...@chromium.orgwrote: Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. Chrome Frame can/will offer control over the context menu. This is exactly the kind of customization Chrome Frame can offer. Too bad we don't have Linux, Mac versions yet, but we are open source now so patches welcome :) -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.orgwrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.orgwrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.orgwrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly
[chromium-dev] Re: Build time doubled since May - what gives?
Perhaps the sync library?That was a large thing that was added recently... ☆PhistucK On Fri, Sep 25, 2009 at 05:35, Lei Zhang thes...@chromium.org wrote: This is very recent. The Windows try server build times have gone way up this week. I thought it was just because of Incredibuild misbehaving on the try servers, but it looks like you're experiencing similar problems without IB. I think this is only affects Windows - the Mac and Linux trybot compile times haven't increased significantly. On Thu, Sep 24, 2009 at 7:06 PM, Ben Goodger (Google) b...@chromium.org wrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ 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: Build time doubled since May - what gives?
http://code.google.com/p/chromium/issues/detail?id=21266 This is a real problem, I just haven't looked into this one in particular. Sometimes I just feel like renaming the dll... M-A On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour m...@chromium.org wrote: Hey Ben, same here ... I see this additional message today (havn't seen it before) 59LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or not built by the last incremental link; performing full link Changing one file used to take me 5 minutes to build. But now it takes me ~10-15 minutes. -Mohamed On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) b...@chromium.org wrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ 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: Build time doubled since May - what gives?
Oh and a lot of warnings appeared recently. It is surprising how much warnings slow down the build, probably due to stdout serialization. http://code.google.com/p/chromium/issues/detail?id=23039 M-A On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel mar...@chromium.org wrote: http://code.google.com/p/chromium/issues/detail?id=21266 This is a real problem, I just haven't looked into this one in particular. Sometimes I just feel like renaming the dll... M-A On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour m...@chromium.org wrote: Hey Ben, same here ... I see this additional message today (havn't seen it before) 59LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or not built by the last incremental link; performing full link Changing one file used to take me 5 minutes to build. But now it takes me ~10-15 minutes. -Mohamed On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) b...@chromium.org wrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ 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: Skipping reference_build ?
It's too late for git but not for svn and tarballs. Please move them to DEPS. M-A On Thu, Sep 24, 2009 at 6:26 PM, Evan Martin e...@chromium.org wrote: We have already scolded Alex about this, but it's too late now. Repeat PSA: plz to not be dumping large Windows binaries into the tree. We have DEPS for a reason. On Thu, Sep 24, 2009 at 3:20 PM, Michael michael.monr...@gmail.com wrote: The src/chrome_frame/tools/test/reference_build directory takes ages to svn up, is there a way to skip it? I don't think I really need all those .dll and .exe files on Linux 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] Re: Question about UI and classic views
On Thu, Sep 24, 2009 at 3:11 AM, Darin Fisher da...@chromium.org wrote: Do websites provide users with previous versions after overhauling their UX? Some do (gmail seems to), but most do not. You just get to surf the latest. Hopefully, the website changes for the better. That's our burden to bear. And other browsers are just a double-click away :-). One difference between the NTP and a random website is that users think of the NTP as their content (see for example the wording in the complaint from Mike's sister at the start of this thread). Web sites that show user-generated (or in this case, user-arranged) content tend to get more complaints about large visual changes than more passive or static sites (example: see all of the uproar whenever Facebook changes their UI). Personally, I like the latest version of the NTP, but I would be wary of lumping it in with websites in general when we're trying to understand user expectations. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
Something as simple as this:http://codereview.chromium.org/244003 http://codereview.chromium.org/244003Not necessarily clean, but this thread is whether we would want to implement Kiosk mode in Chromium. That will help many companies to use Chromium as their solution for hosting their web products. -Mohamed On Fri, Sep 25, 2009 at 8:47 AM, PhistucK phist...@gmail.com wrote: What are the major issues?Full screen with no escape hatch and no status bubble? Chrome developers already said the are willing to take care of those\accept patches for those. The rest are taken care of with disabling keyboard shortcuts, or am I wrong? ☆PhistucK On Fri, Sep 25, 2009 at 15:44, Mohamed Mansour m...@chromium.org wrote: The minor issues, yes, the major issues, no. -Mohamed On Fri, Sep 25, 2009 at 8:40 AM, PhistucK phist...@gmail.com wrote: You can create a content script that will disable the shortcut keys of the browser and the right clicks, on all of the pages.About browsing to other pages (and so, downloading), you can apply a rule within a content script to always navigate to the home page of what you need, when going to any other URL. That would solve most of the issues you have in that list. ☆PhistucK On Fri, Sep 25, 2009 at 15:30, Mohamed Mansour m...@chromium.org wrote: I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode flag is set. If the Kiosk mode is set ( iexplorer.exe -k http://www.google.com ) it renders it as IE Renderer. It renders it fine in a Chrome Frame if its not in Kiosk mode. That must be a bug :) For IE, kiosk mode has a context menu, but people usually apply the registry tweak to remove context menu from IE if they need to. For Chromium, it would be nice if stuff like this would be an extension, an extension should allow us to show/hide various parts of the UI. In the meantime, I quickly compiled a custom Chromium so that my CEO and VP could see the benefits of using Chrome instead of IE on some of our web products. Stuff that would be cool and would be very lightweight to include for kiosk mode would be: - No Status Bar- Full Screen (with no exit, only alt+f4 should work) - No Context Menus (should be an option) - Disable downloading of files. - No tabs - No opening files - many more I would rather that be an extension (but there are currently no way to actually block users to remove extensions, maybe blocking users entering a url would suffice) but not possible currently. -Mohamed On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi a...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher da...@chromium.orgwrote: Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. Chrome Frame can/will offer control over the context menu. This is exactly the kind of customization Chrome Frame can offer. Too bad we don't have Linux, Mac versions yet, but we are open source now so patches welcome :) -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.orgwrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.orgwrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.org wrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in
[chromium-dev] Re: Question about UI and classic views
The other part of this might just be messaging. It's not uncommon for websites to have a link to let users try out the new experience before it launches. And once it does launch, they always seem to include a Check out our new look and cool new features... blurb. So it's sudden switch, but messaged/introduced. At times, we seem to forget the impact of our silent updates. They are great for bug/security fixes, but when we do roll out something like NNTP, it can lead to a 'WTF' moment. For future changes like this, it might make sense to put in messaging for the upgrade so the users get lead through the transition instead of their routine suddenly changing on them. TVL On Fri, Sep 25, 2009 at 10:07 AM, Amanda Walker ama...@chromium.org wrote: On Thu, Sep 24, 2009 at 3:11 AM, Darin Fisher da...@chromium.org wrote: Do websites provide users with previous versions after overhauling their UX? Some do (gmail seems to), but most do not. You just get to surf the latest. Hopefully, the website changes for the better. That's our burden to bear. And other browsers are just a double-click away :-). One difference between the NTP and a random website is that users think of the NTP as their content (see for example the wording in the complaint from Mike's sister at the start of this thread). Web sites that show user-generated (or in this case, user-arranged) content tend to get more complaints about large visual changes than more passive or static sites (example: see all of the uproar whenever Facebook changes their UI). Personally, I like the latest version of the NTP, but I would be wary of lumping it in with websites in general when we're trying to understand user expectations. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Debugging CachedResource memory leak in test_shell
On Thu, Sep 24, 2009 at 5:14 PM, Michael Nordman micha...@google.comwrote: I think there may be more than one code path to CachedResource removal. 1. See DocLoader. It has a DocumentResourceMap that contains cached resources that have been loaded for its Document. The collection gets poked at in the ~DocLoader to clean things up. 2. During CacheResource validation. See CachedResource.clearResourceToRevalidate and deleteIfPossible. Thanks Mike, I've identified the problem :-) The Cache object is a singleton that never gets deleted, so any CachedResource objects in the Cache will be leaked (inCache returns true in deleteIfPossible) by both test_shell and chromium when the renderer exits. It's possible to force deletion of everything in the cache by calling: WebCore::cache()-setDisabled(true); Would it be useful to do this when test_shell and the renderer process exits or is it better to just let these objects leak? Thanks, Marshall On Thu, Sep 24, 2009 at 1:35 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi All, I'm trying to debug the leak of CachedResource objects in test_shell. Every time I browse to a page that contains an image or CSS file a new CachedResource object is created in Cache.cpp createResource(). However, none of these objects are ever freed. Does anyone happen to know where/how the CachedResource objects should be freed so that I can figure out why they're getting lost? Thanks, Marshall --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
Sorry for not being clear. What I meant was that you could create your own kiosk shell and embed Chrome Frame as ActiveX control to render the pages you want in it. That way you could customize different features up to your own satisfaction. On Fri, Sep 25, 2009 at 5:30 AM, Mohamed Mansour m...@chromium.org wrote: I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode flag is set. If the Kiosk mode is set ( iexplorer.exe -k http://www.google.com ) it renders it as IE Renderer. It renders it fine in a Chrome Frame if its not in Kiosk mode. That must be a bug :) For IE, kiosk mode has a context menu, but people usually apply the registry tweak to remove context menu from IE if they need to. For Chromium, it would be nice if stuff like this would be an extension, an extension should allow us to show/hide various parts of the UI. In the meantime, I quickly compiled a custom Chromium so that my CEO and VP could see the benefits of using Chrome instead of IE on some of our web products. Stuff that would be cool and would be very lightweight to include for kiosk mode would be: - No Status Bar- Full Screen (with no exit, only alt+f4 should work) - No Context Menus (should be an option) - Disable downloading of files. - No tabs - No opening files - many more I would rather that be an extension (but there are currently no way to actually block users to remove extensions, maybe blocking users entering a url would suffice) but not possible currently. -Mohamed On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi a...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher da...@chromium.orgwrote: Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. Chrome Frame can/will offer control over the context menu. This is exactly the kind of customization Chrome Frame can offer. Too bad we don't have Linux, Mac versions yet, but we are open source now so patches welcome :) -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.org wrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.orgwrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.orgwrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
Well, Mohamed's patch is *way* simpler and portable. On Fri, Sep 25, 2009 at 12:40 PM, Amit Joshi a...@chromium.org wrote: Sorry for not being clear. What I meant was that you could create your own kiosk shell and embed Chrome Frame as ActiveX control to render the pages you want in it. That way you could customize different features up to your own satisfaction. On Fri, Sep 25, 2009 at 5:30 AM, Mohamed Mansour m...@chromium.org wrote: I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode flag is set. If the Kiosk mode is set ( iexplorer.exe -k http://www.google.com ) it renders it as IE Renderer. It renders it fine in a Chrome Frame if its not in Kiosk mode. That must be a bug :) For IE, kiosk mode has a context menu, but people usually apply the registry tweak to remove context menu from IE if they need to. For Chromium, it would be nice if stuff like this would be an extension, an extension should allow us to show/hide various parts of the UI. In the meantime, I quickly compiled a custom Chromium so that my CEO and VP could see the benefits of using Chrome instead of IE on some of our web products. Stuff that would be cool and would be very lightweight to include for kiosk mode would be: - No Status Bar - Full Screen (with no exit, only alt+f4 should work) - No Context Menus (should be an option) - Disable downloading of files. - No tabs - No opening files - many more I would rather that be an extension (but there are currently no way to actually block users to remove extensions, maybe blocking users entering a url would suffice) but not possible currently. -Mohamed On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi a...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher da...@chromium.org wrote: Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. Chrome Frame can/will offer control over the context menu. This is exactly the kind of customization Chrome Frame can offer. Too bad we don't have Linux, Mac versions yet, but we are open source now so patches welcome :) -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.org wrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.org wrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.org wrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
On Fri, Sep 25, 2009 at 5:30 AM, Mohamed Mansour m...@chromium.org wrote: I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode flag is set. If the Kiosk mode is set ( iexplorer.exe -k http://www.google.com ) it renders it as IE Renderer. It renders it fine in a Chrome Frame if its not in Kiosk mode. That must be a bug :) wait, did you do '... -k cf:http://www.google.com'? (Or does the Google home page use Chrome Frame?) (Not that I'm saying this is the right route. It sounds like a command line flag for Chrome might be the best way to go!) For IE, kiosk mode has a context menu, but people usually apply the registry tweak to remove context menu from IE if they need to. For Chromium, it would be nice if stuff like this would be an extension, an extension should allow us to show/hide various parts of the UI. In the meantime, I quickly compiled a custom Chromium so that my CEO and VP could see the benefits of using Chrome instead of IE on some of our web products. Stuff that would be cool and would be very lightweight to include for kiosk mode would be: - No Status Bar- Full Screen (with no exit, only alt+f4 should work) - No Context Menus (should be an option) - Disable downloading of files. - No tabs - No opening files - many more I would rather that be an extension (but there are currently no way to actually block users to remove extensions, maybe blocking users entering a url would suffice) but not possible currently. -Mohamed On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi a...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher da...@chromium.orgwrote: Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. Chrome Frame can/will offer control over the context menu. This is exactly the kind of customization Chrome Frame can offer. Too bad we don't have Linux, Mac versions yet, but we are open source now so patches welcome :) -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.org wrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.orgwrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.orgwrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Linux Builder (Views dbg), revision 27196
Automatically closing tree for compile on Linux Builder (Views dbg) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28Views%20dbg%29/builds/1202 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28Views%20dbg%29 --= Automatically closing tree for compile on Linux Builder (Views dbg) =-- Revision: 27196 Blame list: pkast...@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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Tue, Sep 22, 2009 at 9:06 PM, Dimitri Glazkov dglaz...@google.comwrote: This all means that we have to be a bit more diligent. We shouldn't be paying these unnecessary costs. So, from now on, I propose a fairly simple set of new rules: 1) if you write a Chromium patch for WebKit, you must provide URLs of successful trybot runs with your submission. Chromium WebKit reviewers will not r+ your patch otherwise. If you can't provide the trybot URLs for some reason, please explain in detail why this patch could still land. 2) if the two-sided patch you authored broke the canary and this happened with no coordination with the WebKit gardener, you assume WebKit gardening responsibility for the next 24 hours. Hopefully, these amendments to our existing ways will bring a bit more peace and stability to the Chromium land. What do you think? I think they're a good start, but they are symptoms of a larger problem. Move fast and clean up messes when they happen worked great when we had one big mess a week. These days, we have multiple ones per day. And as good as the try bots and canaries are (kudos to M-A for setting up the try bots in the first place, and everyone who helps keep the ever-growing herd of bots running), they don't catch everything. They don't catch build time regressions because someone forgot svn:ignores when refactoring where projects get generated, or accidentally checks something into the wrong directory (not to pick on anyone in particular, these are just recent examples). I'd add a 3rd principle: 3) If you change how chromium is built, however innocuous your change seems (gyp changes, new libraries, etc.), take extra care and use more reviewers than usual (preferably including someone intimately acquainted with the bots, such as maruel, thomasvl, markmentovai, nsylvain, etc.). If you're reviewing such a change, don't just look at the diffs, try out the patch and flag anything that seems out of the ordinary. Build breakage means more than just doesn't compile; it can also mean overcompiles (which kills bot performance) or requires a clobber unnecessarily. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about UI and classic views
On Fri, Sep 25, 2009 at 7:07 AM, Amanda Walker ama...@chromium.org wrote: On Thu, Sep 24, 2009 at 3:11 AM, Darin Fisher da...@chromium.org wrote: Do websites provide users with previous versions after overhauling their UX? Some do (gmail seems to), but most do not. You just get to surf the latest. Hopefully, the website changes for the better. That's our burden to bear. And other browsers are just a double-click away :-). One difference between the NTP and a random website is that users think of the NTP as their content (see for example the wording in the complaint from Mike's sister at the start of this thread). Web sites that show user-generated (or in this case, user-arranged) content tend to get more complaints about large visual changes than more passive or static sites (example: see all of the uproar whenever Facebook changes their UI). Personally, I like the latest version of the NTP, but I would be wary of lumping it in with websites in general when we're trying to understand user expectations. --Amanda My comment applied to the entire browser. We silently update it just like websites are silently updated. -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about UI and classic views
On Fri, Sep 25, 2009 at 7:16 AM, Thomas Van Lenten thoma...@chromium.orgwrote: At times, we seem to forget the impact of our silent updates. They are great for bug/security fixes, but when we do roll out something like NNTP, it can lead to a 'WTF' moment. For future changes like this, it might make sense to put in messaging for the upgrade so the users get lead through the transition instead of their routine suddenly changing on them. All software, and all browsers, change their UI and capabilities as they release new versions. Look at how Firefox 1.0, 2.0, 3.0, and 3.5 all had different main window themes (and not just cosmetically; they moved pieces around and changed the UX). It's not like there was a --use_2_0_theme switch when 3.0 released. Users complain about anything that changes. This is why user complaints should be an input, but not a hugely-weighted one. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromeOS), revision 27199
Automatically closing tree for compile on Linux Builder (ChromeOS) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromeOS%29/builds/3542 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromeOS%29 --= Automatically closing tree for compile on Linux Builder (ChromeOS) =-- Revision: 27199 Blame list: t...@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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Fri, Sep 25, 2009 at 10:01 AM, Amanda Walker ama...@chromium.org wrote: On Tue, Sep 22, 2009 at 9:06 PM, Dimitri Glazkov dglaz...@google.comwrote: This all means that we have to be a bit more diligent. We shouldn't be paying these unnecessary costs. So, from now on, I propose a fairly simple set of new rules: 1) if you write a Chromium patch for WebKit, you must provide URLs of successful trybot runs with your submission. Chromium WebKit reviewers will not r+ your patch otherwise. If you can't provide the trybot URLs for some reason, please explain in detail why this patch could still land. 2) if the two-sided patch you authored broke the canary and this happened with no coordination with the WebKit gardener, you assume WebKit gardening responsibility for the next 24 hours. Hopefully, these amendments to our existing ways will bring a bit more peace and stability to the Chromium land. What do you think? I think they're a good start, but they are symptoms of a larger problem. Move fast and clean up messes when they happen worked great when we had one big mess a week. These days, we have multiple ones per day. And as good as the try bots and canaries are (kudos to M-A for setting up the try bots in the first place, and everyone who helps keep the ever-growing herd of bots running), they don't catch everything. They don't catch build time regressions because someone forgot svn:ignores when refactoring where projects get generated, or accidentally checks something into the wrong directory (not to pick on anyone in particular, these are just recent examples). I'd add a 3rd principle: 3) If you change how chromium is built, however innocuous your change seems (gyp changes, new libraries, etc.), take extra care and use more reviewers than usual (preferably including someone intimately acquainted with the bots, such as maruel, thomasvl, markmentovai, nsylvain, etc.). If you're reviewing such a change, don't just look at the diffs, try out the patch and flag anything that seems out of the ordinary. Build breakage means more than just doesn't compile; it can also mean overcompiles (which kills bot performance) or requires a clobber unnecessarily. I had to land a 2 sided patch yesterday. It blew up an important unit test in a very creative way, and we're still trying to figure out how to clean it up nicely. In the mean time, we have a dev channel release blocker. There has to be a better way... Here's a crazy idea: 4) Create a WebKit.next branch. Have full build bot coverage on it. All integrations would go through it. Other than that, only 2 sided patches would land on it. Whenever everything passes, we'd merge in with the main branch. We'd try very hard never to let it get more than a day or so out of sync. This would make 2 sided merges (which are often the reason for rushing a DEPS roll--don't want to keep the canary red for too long, otherwise it's very hard to sort things out) much less haphazard. We could even have it roll the DEPS automatically every time a new webkit.org patch lands, and thus eliminate our need for dedicated canaries. Yeah, it's crazybut I kind of like it. And yeah, when the WebKit API lands things should be better in terms of others breaking us, but this addresses 2 sided patches...which are not going away any time soon. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about UI and classic views
At times, we seem to forget the impact of our silent updates. They are great for bug/security fixes, but when we do roll out something like NNTP, it can lead to a 'WTF' moment. For future changes like this, it might make sense to put in messaging for the upgrade so the users get lead through the transition instead of their routine suddenly changing on them. All software, and all browsers, change their UI and capabilities as they release new versions. Look at how Firefox 1.0, 2.0, 3.0, and 3.5 all had different main window themes (and not just cosmetically; they moved pieces around and changed the UX). It's not like there was a --use_2_0_theme switch when 3.0 released. Users complain about anything that changes. This is why user complaints should be an input, but not a hugely-weighted one. FWIW, Firefox uses can choose not to update to a new version if they don't like the new UI though ( and some people mention this explicitly as a reason for not updating: http://blog.mozilla.com/metrics/2009/08/21/why-people-dont-upgrade-their-browser-part-i/ ). --~--~-~--~~~---~--~~ 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: Question about UI and classic views
On Fri, Sep 25, 2009 at 10:22 AM, Nico Weber tha...@chromium.org wrote: At times, we seem to forget the impact of our silent updates. They are great for bug/security fixes, but when we do roll out something like NNTP, it can lead to a 'WTF' moment. For future changes like this, it might make sense to put in messaging for the upgrade so the users get lead through the transition instead of their routine suddenly changing on them. All software, and all browsers, change their UI and capabilities as they release new versions. Look at how Firefox 1.0, 2.0, 3.0, and 3.5 all had different main window themes (and not just cosmetically; they moved pieces around and changed the UX). It's not like there was a --use_2_0_theme switch when 3.0 released. Users complain about anything that changes. This is why user complaints should be an input, but not a hugely-weighted one. FWIW, Firefox uses can choose not to update to a new version if they don't like the new UI though ( and some people mention this explicitly as a reason for not updating: http://blog.mozilla.com/metrics/2009/08/21/why-people-dont-upgrade-their-browser-part-i/ ). It's also not something Mozilla supports. Eventually, they stop offering security updates for old versions. -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about UI and classic views
On Fri, Sep 25, 2009 at 1:11 PM, Peter Kasting pkast...@google.com wrote: All software, and all browsers, change their UI and capabilities as they release new versions. Look at how Firefox 1.0, 2.0, 3.0, and 3.5 all had different main window themes (and not just cosmetically; they moved pieces around and changed the UX). It's not like there was a --use_2_0_theme switch when 3.0 released. Sure. But it's not like users came in one day and their copy of 2.0 had changed into 3.0. Autoupdate (which is a good thing overall, don't get me wrong) is different from a user-initiated upgrade in this respect. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about UI and classic views
On Fri, Sep 25, 2009 at 10:24 AM, Darin Fisher da...@chromium.org wrote: On Fri, Sep 25, 2009 at 10:22 AM, Nico Weber tha...@chromium.org wrote: At times, we seem to forget the impact of our silent updates. They are great for bug/security fixes, but when we do roll out something like NNTP, it can lead to a 'WTF' moment. For future changes like this, it might make sense to put in messaging for the upgrade so the users get lead through the transition instead of their routine suddenly changing on them. All software, and all browsers, change their UI and capabilities as they release new versions. Look at how Firefox 1.0, 2.0, 3.0, and 3.5 all had different main window themes (and not just cosmetically; they moved pieces around and changed the UX). It's not like there was a --use_2_0_theme switch when 3.0 released. Users complain about anything that changes. This is why user complaints should be an input, but not a hugely-weighted one. FWIW, Firefox uses can choose not to update to a new version if they don't like the new UI though ( and some people mention this explicitly as a reason for not updating: http://blog.mozilla.com/metrics/2009/08/21/why-people-dont-upgrade-their-browser-part-i/ ). It's also not something Mozilla supports. Eventually, they stop offering security updates for old versions. Sure, and I guess most people update eventually, but they can go through their five stages of grief at their own speed. With autoupdate, they get the new UI while they might still be in the Denial or Anger stages :-) --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
Hi Jeremy, ChromeFrame doesn't seem to work if you pass the URL in command line for Internet Explorer. A simple example is visiting this page directly (assuming you installed ChromeFrame) 1. Open Internet Explorer 2. Visit this http://haptisense.com/ 3. You will see the correct After Browser which is Chrome and Original Browser which is IE. Now do this: 1. cd C:\Program Files\Internet Explorer 2. Type: iexplorer.exe http://haptisense.com 3. You will see the correct Original Browser but the After Browser is still IE (you can notice the Chrome renderer isn't replaced because there is IE right click and rendering is obviously IE) Same thing happens to iexplorer.exe -k http://haptisense.com The patch I submitted, does what I wanted to do for demo purposes, I contribute to Chrome because I love everything about this browser, and seeing the usage of IE in my day job is quite annoying (since our GIS web apps are plotting horribly slow in comparison to Chrome if given a lot of data). I could submit a cleaner patch (which does it right) that introduces Kiosk mode for Chrome. Are there any *objections*? -Mohamed On Fri, Sep 25, 2009 at 12:51 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Sep 25, 2009 at 5:30 AM, Mohamed Mansour m...@chromium.org wrote: I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode flag is set. If the Kiosk mode is set ( iexplorer.exe -k http://www.google.com ) it renders it as IE Renderer. It renders it fine in a Chrome Frame if its not in Kiosk mode. That must be a bug :) wait, did you do '... -k cf:http://www.google.com'? (Or does the Google home page use Chrome Frame?) (Not that I'm saying this is the right route. It sounds like a command line flag for Chrome might be the best way to go!) For IE, kiosk mode has a context menu, but people usually apply the registry tweak to remove context menu from IE if they need to. For Chromium, it would be nice if stuff like this would be an extension, an extension should allow us to show/hide various parts of the UI. In the meantime, I quickly compiled a custom Chromium so that my CEO and VP could see the benefits of using Chrome instead of IE on some of our web products. Stuff that would be cool and would be very lightweight to include for kiosk mode would be: - No Status Bar- Full Screen (with no exit, only alt+f4 should work) - No Context Menus (should be an option) - Disable downloading of files. - No tabs - No opening files - many more I would rather that be an extension (but there are currently no way to actually block users to remove extensions, maybe blocking users entering a url would suffice) but not possible currently. -Mohamed On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi a...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher da...@chromium.orgwrote: Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. Chrome Frame can/will offer control over the context menu. This is exactly the kind of customization Chrome Frame can offer. Too bad we don't have Linux, Mac versions yet, but we are open source now so patches welcome :) -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.org wrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.orgwrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.orgwrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version,
[chromium-dev] Re: Kiosk Mode for Chrome
On Fri, Sep 25, 2009 at 10:43 AM, Mohamed Mansour m...@chromium.org wrote: I could submit a cleaner patch (which does it right) that introduces Kiosk mode for Chrome. Are there any objections? None from me. :) Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
No objections. I think it's a good idea, you're not the only one who wants this, and it seems like it can be done very cleanly. On Fri, Sep 25, 2009 at 10:47 AM, Adam Barth aba...@chromium.org wrote: On Fri, Sep 25, 2009 at 10:43 AM, Mohamed Mansour m...@chromium.org wrote: I could submit a cleaner patch (which does it right) that introduces Kiosk mode for Chrome. Are there any objections? None from me. :) Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Build time doubled since May - what gives?
I'll volunteer to fix any build issues created as a result of sync. Building the protobuf compiler (protoc.exe) emits a bunch of warnings -- the bulk are signed/unsigned warnings. I'll put together a change to suppress those. - nick On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Oh and a lot of warnings appeared recently. It is surprising how much warnings slow down the build, probably due to stdout serialization. http://code.google.com/p/chromium/issues/detail?id=23039 M-A On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel mar...@chromium.org wrote: http://code.google.com/p/chromium/issues/detail?id=21266 This is a real problem, I just haven't looked into this one in particular. Sometimes I just feel like renaming the dll... M-A On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour m...@chromium.org wrote: Hey Ben, same here ... I see this additional message today (havn't seen it before) 59LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or not built by the last incremental link; performing full link Changing one file used to take me 5 minutes to build. But now it takes me ~10-15 minutes. -Mohamed On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) b...@chromium.org wrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ 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: Build time doubled since May - what gives?
I would be surprised if it were just the addition of code. Bear in mind the May 7 minute figure includes all of WebKit, and I don't think that's doubled in size since then? So it seems like it must be something more related to the build system itself. I don't think it's incremental linking, since my build was a clean build. -Ben On Fri, Sep 25, 2009 at 11:09 AM, Nick Carter n...@chromium.org wrote: I'll volunteer to fix any build issues created as a result of sync. Building the protobuf compiler (protoc.exe) emits a bunch of warnings -- the bulk are signed/unsigned warnings. I'll put together a change to suppress those. - nick On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel mar...@chromium.org wrote: Oh and a lot of warnings appeared recently. It is surprising how much warnings slow down the build, probably due to stdout serialization. http://code.google.com/p/chromium/issues/detail?id=23039 M-A On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel mar...@chromium.org wrote: http://code.google.com/p/chromium/issues/detail?id=21266 This is a real problem, I just haven't looked into this one in particular. Sometimes I just feel like renaming the dll... M-A On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour m...@chromium.org wrote: Hey Ben, same here ... I see this additional message today (havn't seen it before) 59LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or not built by the last incremental link; performing full link Changing one file used to take me 5 minutes to build. But now it takes me ~10-15 minutes. -Mohamed On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) b...@chromium.org wrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ 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: Build time doubled since May - what gives?
On Fri, Sep 25, 2009 at 11:09 AM, Nick Carter n...@chromium.org wrote: I'll volunteer to fix any build issues created as a result of sync. Building the protobuf compiler (protoc.exe) emits a bunch of warnings -- the bulk are signed/unsigned warnings. I'll put together a change to suppress those. It would be nice if we could fix those instead of just suppressing them. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Build time doubled since May - what gives?
A lot of the projects link half-of-the-world when not necessary. I'm working on that right now. M-A On Fri, Sep 25, 2009 at 2:12 PM, Ben Goodger (Google) b...@chromium.org wrote: I would be surprised if it were just the addition of code. Bear in mind the May 7 minute figure includes all of WebKit, and I don't think that's doubled in size since then? So it seems like it must be something more related to the build system itself. I don't think it's incremental linking, since my build was a clean build. -Ben On Fri, Sep 25, 2009 at 11:09 AM, Nick Carter n...@chromium.org wrote: I'll volunteer to fix any build issues created as a result of sync. Building the protobuf compiler (protoc.exe) emits a bunch of warnings -- the bulk are signed/unsigned warnings. I'll put together a change to suppress those. - nick On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel mar...@chromium.org wrote: Oh and a lot of warnings appeared recently. It is surprising how much warnings slow down the build, probably due to stdout serialization. http://code.google.com/p/chromium/issues/detail?id=23039 M-A On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel mar...@chromium.org wrote: http://code.google.com/p/chromium/issues/detail?id=21266 This is a real problem, I just haven't looked into this one in particular. Sometimes I just feel like renaming the dll... M-A On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour m...@chromium.org wrote: Hey Ben, same here ... I see this additional message today (havn't seen it before) 59LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or not built by the last incremental link; performing full link Changing one file used to take me 5 minutes to build. But now it takes me ~10-15 minutes. -Mohamed On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) b...@chromium.org wrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ 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: Debugging CachedResource memory leak in test_shell
On Fri, Sep 25, 2009 at 10:42 AM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Thu, Sep 24, 2009 at 5:14 PM, Michael Nordman micha...@google.comwrote: I think there may be more than one code path to CachedResource removal. 1. See DocLoader. It has a DocumentResourceMap that contains cached resources that have been loaded for its Document. The collection gets poked at in the ~DocLoader to clean things up. 2. During CacheResource validation. See CachedResource.clearResourceToRevalidate and deleteIfPossible. Thanks Mike, I've identified the problem :-) The Cache object is a singleton that never gets deleted, so any CachedResource objects in the Cache will be leaked (inCache returns true in deleteIfPossible) by both test_shell and chromium when the renderer exits. It's possible to force deletion of everything in the cache by calling: WebCore::cache()-setDisabled(true); Would it be useful to do this when test_shell and the renderer process exits or is it better to just let these objects leak? I've created a bug to track this: http://crbug.com/23081 Thanks, Marshall On Thu, Sep 24, 2009 at 1:35 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi All, I'm trying to debug the leak of CachedResource objects in test_shell. Every time I browse to a page that contains an image or CSS file a new CachedResource object is created in Cache.cpp createResource(). However, none of these objects are ever freed. Does anyone happen to know where/how the CachedResource objects should be freed so that I can figure out why they're getting lost? Thanks, Marshall --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] gclient hang
Your next gclient sync will probably hang. The easiest way to fix it is to: rm -rf src/third_party/WebKit/WebKit/chromium or rd /q /s src\third_party\WebKit\WebKit\chromium before syncing. Sorry for the trouble, M-A --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gclient hang
To get mine to work, I had to rm -rf src/third_party/WebKit/WebKit just doing chromium wasn't enough to stop the hangs. On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Your next gclient sync will probably hang. The easiest way to fix it is to: rm -rf src/third_party/WebKit/WebKit/chromium or rd /q /s src\third_party\WebKit\WebKit\chromium before syncing. Sorry for the trouble, M-A -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gclient hang
Yep, I specified one directory too deep. On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton pinker...@chromium.org wrote: To get mine to work, I had to rm -rf src/third_party/WebKit/WebKit just doing chromium wasn't enough to stop the hangs. On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Your next gclient sync will probably hang. The easiest way to fix it is to: rm -rf src/third_party/WebKit/WebKit/chromium or rd /q /s src\third_party\WebKit\WebKit\chromium before syncing. Sorry for the trouble, M-A -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I'm concerned that the page actions style Omnibox icon is not sufficient notification for users that this capability exists. I'll add this to the list of features for UI team to create mocks for. On Thu, Sep 24, 2009 at 12:51 PM, b...@chromium.org wrote: I've shared a document with you: [HTML5] registerProtocolHandler API http://docs.google.com/Doc?docid=0AVgZ1iILHLkdZGQ0bjd6cTVfMGdqZmpiNGZrhl=eninvite=CI6z8vgG It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above. This is a design document for the worked needed to resolve http://crbug.com/11359 beyond the webkit implementation. Please feel free to comment inline or in this thread. I look forward to your critics and suggestions. --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 11:33 AM, Brian Rakowski br...@chromium.org wrote: I'm concerned that the page actions style Omnibox icon is not sufficient notification for users that this capability exists. I'll add this to the list of features for UI team to create mocks for. I agree, I think I'd prefer an infobar for this. (/cue Glen hating on infobars) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
If you click no on an info bar, then how would you later change your mind? I really liked the proposal because it'd just always be there. Much like the RSS feed UI. It seems like we can either just keep adding infobars or make an investment in training users what these icons mean. On Fri, Sep 25, 2009 at 11:36 AM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 11:33 AM, Brian Rakowski br...@chromium.orgwrote: I'm concerned that the page actions style Omnibox icon is not sufficient notification for users that this capability exists. I'll add this to the list of features for UI team to create mocks for. I agree, I think I'd prefer an infobar for this. (/cue Glen hating on infobars) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gclient hang
For those that use third_party/WebKit as a full WebKit checkout, you'll need to add the following line to your .gclient: src/third_party/WebKit/WebKit/chromium: None, Andrew On Fri, Sep 25, 2009 at 11:51 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Yep, I specified one directory too deep. On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton pinker...@chromium.org wrote: To get mine to work, I had to rm -rf src/third_party/WebKit/WebKit just doing chromium wasn't enough to stop the hangs. On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Your next gclient sync will probably hang. The easiest way to fix it is to: rm -rf src/third_party/WebKit/WebKit/chromium or rd /q /s src\third_party\WebKit\WebKit\chromium before syncing. Sorry for the trouble, M-A -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gclient hang
I updated http://sites.google.com/a/chromium.org/dev/developers/contributing-to-webkit On Fri, Sep 25, 2009 at 12:14 PM, Andrew Scherkus scher...@chromium.orgwrote: For those that use third_party/WebKit as a full WebKit checkout, you'll need to add the following line to your .gclient: src/third_party/WebKit/WebKit/chromium: None, Andrew On Fri, Sep 25, 2009 at 11:51 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Yep, I specified one directory too deep. On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton pinker...@chromium.org wrote: To get mine to work, I had to rm -rf src/third_party/WebKit/WebKit just doing chromium wasn't enough to stop the hangs. On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Your next gclient sync will probably hang. The easiest way to fix it is to: rm -rf src/third_party/WebKit/WebKit/chromium or rd /q /s src\third_party\WebKit\WebKit\chromium before syncing. Sorry for the trouble, M-A -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.orgwrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.comwrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.orgwrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.orgwrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.orgwrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.comwrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.orgwrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
We should only allow this UI to be invoked from a user gesture. -Ben On Fri, Sep 25, 2009 at 12:41 PM, Jeremy Orlow jor...@chromium.org wrote: What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.org wrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gclient hang
It also appears you can no longer use a symlink to point /src/third_party/WebKit at a different checkout. I think relative paths are to blame but I haven't fully debugged the issue yet. On Fri, Sep 25, 2009 at 12:20 PM, Jeremy Orlow jor...@chromium.org wrote: I updated http://sites.google.com/a/chromium.org/dev/developers/contributing-to-webkit On Fri, Sep 25, 2009 at 12:14 PM, Andrew Scherkus scher...@chromium.orgwrote: For those that use third_party/WebKit as a full WebKit checkout, you'll need to add the following line to your .gclient: src/third_party/WebKit/WebKit/chromium: None, Andrew On Fri, Sep 25, 2009 at 11:51 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Yep, I specified one directory too deep. On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton pinker...@chromium.org wrote: To get mine to work, I had to rm -rf src/third_party/WebKit/WebKit just doing chromium wasn't enough to stop the hangs. On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Your next gclient sync will probably hang. The easiest way to fix it is to: rm -rf src/third_party/WebKit/WebKit/chromium or rd /q /s src\third_party\WebKit\WebKit\chromium before syncing. Sorry for the trouble, M-A -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. How does Gmail trigger this today? Do they have a button in the Settings you have to click? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gclient hang
No, symlinks would not work since upstream gyp files still depend on downstream gyps (skia, icu, etc). Working on it. On Fri, Sep 25, 2009 at 12:45 PM, Andrew Scherkus scher...@chromium.orgwrote: It also appears you can no longer use a symlink to point /src/third_party/WebKit at a different checkout. I think relative paths are to blame but I haven't fully debugged the issue yet. On Fri, Sep 25, 2009 at 12:20 PM, Jeremy Orlow jor...@chromium.orgwrote: I updated http://sites.google.com/a/chromium.org/dev/developers/contributing-to-webkit On Fri, Sep 25, 2009 at 12:14 PM, Andrew Scherkus scher...@chromium.orgwrote: For those that use third_party/WebKit as a full WebKit checkout, you'll need to add the following line to your .gclient: src/third_party/WebKit/WebKit/chromium: None, Andrew On Fri, Sep 25, 2009 at 11:51 AM, Marc-Antoine Ruel mar...@chromium.org wrote: Yep, I specified one directory too deep. On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton pinker...@chromium.org wrote: To get mine to work, I had to rm -rf src/third_party/WebKit/WebKit just doing chromium wasn't enough to stop the hangs. On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Your next gclient sync will probably hang. The easiest way to fix it is to: rm -rf src/third_party/WebKit/WebKit/chromium or rd /q /s src\third_party\WebKit\WebKit\chromium before syncing. Sorry for the trouble, M-A -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Skipping reference_build ?
Sounds like we need a presubmit check. On Fri, Sep 25, 2009 at 6:38 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: It's too late for git but not for svn and tarballs. Please move them to DEPS. M-A On Thu, Sep 24, 2009 at 6:26 PM, Evan Martin e...@chromium.org wrote: We have already scolded Alex about this, but it's too late now. Repeat PSA: plz to not be dumping large Windows binaries into the tree. We have DEPS for a reason. On Thu, Sep 24, 2009 at 3:20 PM, Michael michael.monr...@gmail.com wrote: The src/chrome_frame/tools/test/reference_build directory takes ages to svn up, is there a way to skip it? I don't think I really need all those .dll and .exe files on Linux 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] Re: gclient hang
On Fri, Sep 25, 2009 at 11:51 PM, Yaar Schnitman y...@chromium.org wrote: No, symlinks would not work since upstream gyp files still depend on downstream gyps (skia, icu, etc). Working on it. As a workaround it's possible to mount directories instead of symlinking them. $ mkdir /chrome/src/third_party/WebKit $ sudo mount --bind /upstream/WebKit /chrome/src/third_party/WebKit On Fri, Sep 25, 2009 at 12:45 PM, Andrew Scherkus scher...@chromium.org wrote: It also appears you can no longer use a symlink to point /src/third_party/WebKit at a different checkout. I think relative paths are to blame but I haven't fully debugged the issue yet. On Fri, Sep 25, 2009 at 12:20 PM, Jeremy Orlow jor...@chromium.org wrote: I updated http://sites.google.com/a/chromium.org/dev/developers/contributing-to-webkit On Fri, Sep 25, 2009 at 12:14 PM, Andrew Scherkus scher...@chromium.org wrote: For those that use third_party/WebKit as a full WebKit checkout, you'll need to add the following line to your .gclient: src/third_party/WebKit/WebKit/chromium: None, Andrew On Fri, Sep 25, 2009 at 11:51 AM, Marc-Antoine Ruel mar...@chromium.org wrote: Yep, I specified one directory too deep. On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton pinker...@chromium.org wrote: To get mine to work, I had to rm -rf src/third_party/WebKit/WebKit just doing chromium wasn't enough to stop the hangs. On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Your next gclient sync will probably hang. The easiest way to fix it is to: rm -rf src/third_party/WebKit/WebKit/chromium or rd /q /s src\third_party\WebKit\WebKit\chromium before syncing. Sorry for the trouble, M-A -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] buildbot failure in Chromium on Modules XP (dbg), revision 27248
Automatically closing tree for net_unittests on Modules XP (dbg) http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP%20%28dbg%29 --= Automatically closing tree for net_unittests on Modules XP (dbg) =-- Revision: 27245, 27246, 27247, 27248 Blame list: ero...@chromium.org,ma...@chromium.org,m...@chromium.org,sh...@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 Modules XP (dbg), revision 27248
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] 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] buildbot failure in Chromium on XP Tests (dbg)(1), revision 27249
Automatically closing tree for unit_tests on XP Tests (dbg)(1) http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests%20%28dbg%29%281%29/builds/12686 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests%20%28dbg%29%281%29 --= Automatically closing tree for unit_tests on XP Tests (dbg)(1) =-- Revision: 27249 Blame list: aba...@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 Vista Tests (dbg)(1), revision 27259
Automatically closing tree for unit_tests on Vista Tests (dbg)(1) http://build.chromium.org/buildbot/waterfall/builders/Vista%20Tests%20%28dbg%29%281%29/builds/12964 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Vista%20Tests%20%28dbg%29%281%29 --= Automatically closing tree for unit_tests on Vista Tests (dbg)(1) =-- Revision: 27259 Blame list: dglaz...@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: Build time doubled since May - what gives?
I'm fixing the RegisteredEventListener one.-Darin On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Oh and a lot of warnings appeared recently. It is surprising how much warnings slow down the build, probably due to stdout serialization. http://code.google.com/p/chromium/issues/detail?id=23039 M-A On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel mar...@chromium.org wrote: http://code.google.com/p/chromium/issues/detail?id=21266 This is a real problem, I just haven't looked into this one in particular. Sometimes I just feel like renaming the dll... M-A On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour m...@chromium.org wrote: Hey Ben, same here ... I see this additional message today (havn't seen it before) 59LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or not built by the last incremental link; performing full link Changing one file used to take me 5 minutes to build. But now it takes me ~10-15 minutes. -Mohamed On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) b...@chromium.org wrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ 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: Build time doubled since May - what gives?
http://trac.webkit.org/changeset/48776 On Fri, Sep 25, 2009 at 3:57 PM, Darin Fisher da...@chromium.org wrote: I'm fixing the RegisteredEventListener one.-Darin On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Oh and a lot of warnings appeared recently. It is surprising how much warnings slow down the build, probably due to stdout serialization. http://code.google.com/p/chromium/issues/detail?id=23039 M-A On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel mar...@chromium.org wrote: http://code.google.com/p/chromium/issues/detail?id=21266 This is a real problem, I just haven't looked into this one in particular. Sometimes I just feel like renaming the dll... M-A On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour m...@chromium.org wrote: Hey Ben, same here ... I see this additional message today (havn't seen it before) 59LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or not built by the last incremental link; performing full link Changing one file used to take me 5 minutes to build. But now it takes me ~10-15 minutes. -Mohamed On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) b...@chromium.org wrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] SVN hangs updating third_party/WebKit
At first I thought it was a fluke but now it just happened again. Is anyone else seeing this? I do a gclient sync and it takes forever, showing this output and looks hung: running 'svn update E:\code\src\third_party\WebKit --revision 27219' in 'E:\code' I wait and wait and wait and wait and nothing happens. I tried FileMon and couldn't see any files being accessed. Re-running gclient sync just hangs again in the same spot. The only workaround I know is to delete that folder and try again. That was fine for the first time this happens, but is getting more exponentially more frustrating with each time I have to do that. :s Anyone seen this? -F --~--~-~--~~~---~--~~ 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 hangs updating third_party/WebKit
http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba I had the impression that removing that folder once is enough, though I didn't try it more than once yet. On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson fin...@chromium.org wrote: At first I thought it was a fluke but now it just happened again. Is anyone else seeing this? I do a gclient sync and it takes forever, showing this output and looks hung: running 'svn update E:\code\src\third_party\WebKit --revision 27219' in 'E:\code' I wait and wait and wait and wait and nothing happens. I tried FileMon and couldn't see any files being accessed. Re-running gclient sync just hangs again in the same spot. The only workaround I know is to delete that folder and try again. That was fine for the first time this happens, but is getting more exponentially more frustrating with each time I have to do that. :s Anyone seen this? -F --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
First of all, thanks for putting together this proposal, great to see progress on this! A few comments: - UI: I prefer the infobar, as per the arguments above. I don't think this will happen frequently enough to be annoying. - UI: Should there be user UI to manage this that doesn't require knowing a magic about:protocols url? - API: Is there an API to unregister from a protocol? - API: How does the page know it's registered? We should probably have a separate API for this, so sites can display a more prominent call to action when they're not registered. - Misc: Should there be some way for native apps to register as protocol handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does the OS provide this? Cheers, -Nick On Fri, Sep 25, 2009 at 12:45 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. How does Gmail trigger this today? Do they have a button in the Settings you have to click? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: SVN hangs updating third_party/WebKit
For windows (vista 64bit?), if you hit gclient hangs in general while sync'ing: Run this command (from an Administrator command prompt): netsh interface tcp set global autotuninglevel=disabled Hopefully, it will be fixed for you as it seems to be for me. Reference: http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspxhttp://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx On Fri, Sep 25, 2009 at 5:22 PM, Nico Weber tha...@chromium.org wrote: http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba I had the impression that removing that folder once is enough, though I didn't try it more than once yet. On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson fin...@chromium.org wrote: At first I thought it was a fluke but now it just happened again. Is anyone else seeing this? I do a gclient sync and it takes forever, showing this output and looks hung: running 'svn update E:\code\src\third_party\WebKit --revision 27219' in 'E:\code' I wait and wait and wait and wait and nothing happens. I tried FileMon and couldn't see any files being accessed. Re-running gclient sync just hangs again in the same spot. The only workaround I know is to delete that folder and try again. That was fine for the first time this happens, but is getting more exponentially more frustrating with each time I have to do that. :s Anyone seen this? -F --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] new values for failures in test_expectations.txt
Hi all, If you don't run layout_tests or ever need to modify test_expecations.txt, you can ignore this ... As discussed earlier this week, we've added the ability to indicate whether or not a test is expected to produce incorrect text output (either a bad render tree or bad simplified text output), incorrect images, or both. The keywords in test expectations are 'TEXT', 'IMAGE', and 'IMAGE+TEXT', respectively. Specifying a test expectation as 'FAIL' will continue to indicate any one of the above three choices might be happening. However, we intended to migrate all FAILs to one of the three choices. Once that is complete, we'll flip 'FAIL' to mean 'IMAGE+TEXT', and remove the 'IMAGE+TEXT' option. I expect this'll probably happen in the next week or two. Thanks, and let me know if you see any problems! -- Dirk --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 5:30 PM, Nick Baum nickb...@chromium.org wrote: First of all, thanks for putting together this proposal, great to see progress on this! A few comments: - UI: I prefer the infobar, as per the arguments above. I don't think this will happen frequently enough to be annoying. - UI: Should there be user UI to manage this that doesn't require knowing a magic about:protocols url? - API: Is there an API to unregister from a protocol? - API: How does the page know it's registered? We should probably have a separate API for this, so sites can display a more prominent call to action when they're not registered. I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. - Misc: Should there be some way for native apps to register as protocol handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does the OS provide this? Cheers, -Nick On Fri, Sep 25, 2009 at 12:45 PM, Peter Kasting pkast...@google.comwrote: On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. How does Gmail trigger this today? Do they have a button in the Settings you have to click? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: new values for failures in test_expectations.txt
On Fri, Sep 25, 2009 at 9:12 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, If you don't run layout_tests or ever need to modify test_expecations.txt, you can ignore this ... As a reminder, every build sheriff needs to be able to modify this. M-A As discussed earlier this week, we've added the ability to indicate whether or not a test is expected to produce incorrect text output (either a bad render tree or bad simplified text output), incorrect images, or both. The keywords in test expectations are 'TEXT', 'IMAGE', and 'IMAGE+TEXT', respectively. Specifying a test expectation as 'FAIL' will continue to indicate any one of the above three choices might be happening. However, we intended to migrate all FAILs to one of the three choices. Once that is complete, we'll flip 'FAIL' to mean 'IMAGE+TEXT', and remove the 'IMAGE+TEXT' option. I expect this'll probably happen in the next week or two. Thanks, and let me know if you see any problems! -- Dirk --~--~-~--~~~---~--~~ 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 27312
Automatically closing tree for unit_tests on XP Tests http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests --= Automatically closing tree for unit_tests on XP Tests =-- Revision: 27309, 27310, 27312 Blame list: dpra...@google.com,m...@chromium.org,thes...@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 XP Tests, revision 27312
Looks like a grid change wasn't picked up, should go away after clobbering.
On Fri, Sep 25, 2009 at 6:33 PM, build...@chromium.org wrote:
http://build.chromium.org/buildbot/waterfall/
Automatically closing tree for unit_tests on XP Tests
http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568
Revision: 27309, 27310, 27312
Blame list: dpra...@google.com,m...@chromium.org,thes...@chromium.org
XP Tests
Build
12568http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568
svnkill
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/shell/logs/stdio
update
scripts
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/shell_2/logs/stdio
taskkill
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/shell_3/logs/stdio
update
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/gclient/logs/stdio
extract
build
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/extract%20build/logs/stdio
Start
Crash Handler
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/Start%20Crash%20Handler/logs/stdio
ipc_tests
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/ipc_tests/logs/stdio
installer_util_unittests
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/installer_util_unittests/logs/stdio
mini_installer_test
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/mini_installer_test/logs/stdio
unit_tests
16 disabled
failed 1
stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/unit_tests/logs/stdio
Testhttp://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568/steps/unit_tests/logs/Test
Changed by: *thes...@chromium.org*
Changed at: *Fri 25 Sep 2009 18:08:17*
Branch: *src*
Revision: *27309*
Changed files:
- *tools/valgrind/memcheck/suppressions.txt*
Comments:
Widen a valgrind suppression yet again.
BUG=22932
TEST=none
TBR=stuartmorgan
Review URL: http://codereview.chromium.org/243015
Changed by: *dpra...@google.com*
Changed at: *Fri 25 Sep 2009 18:08:59*
Branch: *src*
Revision: *27310*
Changed files:
- *webkit/tools/layout_tests/test_expectations.txt*
Comments:
Fix comments in test expectations. Also, the description in my previous
change to this file was wrong, the new values for expectations are
'TEXT', 'IMAGE', and 'IMAGE+TEXT' ('BOTH' is not a valid value).
R=ojan
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/245019
Changed by: *...@chromium.org*
Changed at: *Fri 25 Sep 2009 18:13:07*
Branch: *src*
Revision: *27312*
Changed files:
- *chrome/app/generated_resources.grd*
- *chrome/browser/views/download_item_view.cc*
- *chrome/browser/download/download_shelf.cc*
- *chrome/browser/download/download_shelf.h*
Comments:
Remove the context menu item 'Remove from shelf' from download shelf
BUG=23078
TEST=No more menu item on download item
Review URL: http://codereview.chromium.org/246004
--~--~-~--~~~---~--~~
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 isn't shutting down cleanly
+1 On Wed, Sep 23, 2009 at 5:52 AM, progame prog...@chromium.org wrote: sounds like this issue http://crbug.com/20451 On Sep 22, 8:39 pm, Daniel Cowx daniel.c...@gmail.com wrote: Can someone please provide a bit of insight into how to solve the following problem: 1. Open Chromium Options Show saved passwords 2. Click the Remove All button Now, *before* you click Yes or No, close the main browser window (e.g. by clicking the X in the upper right corner). When you do this, all windows disappear, but the main browser process remains running. It looks like this is due to a nested invocation of MessageLoop::Run() (via chrome\browser\views\confirm_message_box_dialog.cc) and the fact that Quit is only exiting the most recent invocation. How can we cleanly quit the application in this case? Cheers, Daniel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] how to trigger a non-success status for URLRequest in unittests?
Hi, I want my unittest to result in my URLRequest getting a non-success status. How do I do that? When I use http://localhost/foo; as my URL, I get a non-success status with os_error = -102 when testing on Vista64, but I don't know if this will guarantee me a non-success status all the time on all platforms. Is there a more definitive technique to do what I want? Thanks, Jenn --~--~-~--~~~---~--~~ 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 trigger a non-success status for URLRequest in unittests?
Perhaps you could use an invalid scheme on the URL? (Just guessing; I'm not familiar with this code.) On Fri, Sep 25, 2009 at 7:02 PM, Jenn Braithwaite (胡慧鋒) je...@google.com wrote: Hi, I want my unittest to result in my URLRequest getting a non-success status. How do I do that? When I use http://localhost/foo; as my URL, I get a non-success status with os_error = -102 when testing on Vista64, but I don't know if this will guarantee me a non-success status all the time on all platforms. Is there a more definitive technique to do what I want? Thanks, Jenn --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ 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 trigger a non-success status for URLRequest in unittests?
I'm not familiar with the code either, but if people are fine making URLRequest::status() virtual, you can use gmock and be done. I have a hunch there might be some push back :) If you're really interested in deterministic results, the longer way looks like you'd call RegisterRequestInterceptor() with a special URLRequestJob subclass that would modify a URLRequest instance to your liking. In fact url_request_test_job.h might be what you're looking for. Andrew On Fri, Sep 25, 2009 at 7:02 PM, Jenn Braithwaite (胡慧鋒) je...@google.comwrote: Hi, I want my unittest to result in my URLRequest getting a non-success status. How do I do that? When I use http://localhost/foo; as my URL, I get a non-success status with os_error = -102 when testing on Vista64, but I don't know if this will guarantee me a non-success status all the time on all platforms. Is there a more definitive technique to do what I want? Thanks, Jenn --~--~-~--~~~---~--~~ 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 hangs updating third_party/WebKit
Yes, I am on Vista 64 bit. I'll try this next time I hit this. Thanks for the pointer. On Fri, Sep 25, 2009 at 17:39, David Levin le...@google.com wrote: For windows (vista 64bit?), if you hit gclient hangs in general while sync'ing: Run this command (from an Administrator command prompt): netsh interface tcp set global autotuninglevel=disabled Hopefully, it will be fixed for you as it seems to be for me. Reference: http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx On Fri, Sep 25, 2009 at 5:22 PM, Nico Weber tha...@chromium.org wrote: http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba I had the impression that removing that folder once is enough, though I didn't try it more than once yet. On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson fin...@chromium.org wrote: At first I thought it was a fluke but now it just happened again. Is anyone else seeing this? I do a gclient sync and it takes forever, showing this output and looks hung: running 'svn update E:\code\src\third_party\WebKit --revision 27219' in 'E:\code' I wait and wait and wait and wait and nothing happens. I tried FileMon and couldn't see any files being accessed. Re-running gclient sync just hangs again in the same spot. The only workaround I know is to delete that folder and try again. That was fine for the first time this happens, but is getting more exponentially more frustrating with each time I have to do that. :s Anyone seen this? -F --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
BTW I should note what I mean by Uber Page Info Window. For some time, we've talked about improving the page info window in Chrome. Right now it shows only the security information for a SSL page. In the future we'd like to extend this to show other information. The idea is there'd be a few tabs showing things like: - general page info in addition to security info - web capabilities/permissions used by the page, along with the ability to control these, including the effect of any active blacklist - media attached to the page, which a convenient way to download - eventually an additional surface for extensions to add tabs/features based on content-script scanning of the page The idea anyway is for any web capability there'd be a toggle in here. We also envisage some kind of app/extension page where one can visit the properties/capabilities for an individual installed app/extension too. Anyway any time the notion of site-specific capability control comes up, the response from the UX team tends to be uber page info window. It's on our list, we just have been busy with other stuff. I mocked this some years ago in Firefox as a bottom bar http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window but I am not advocating that approach necessarily. -Ben On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) b...@chromium.org wrote: On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ 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 (Views dbg), revision 27319
Automatically closing tree for compile on Linux Builder (Views dbg) http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28Views%20dbg%29/builds/1278 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28Views%20dbg%29 --= Automatically closing tree for compile on Linux Builder (Views dbg) =-- Revision: 27319 Blame list: 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] Re: SVN hangs updating third_party/WebKit
Thanks! That worked for me on Windows 7 64bit! -Mohamed On Fri, Sep 25, 2009 at 8:39 PM, David Levin le...@google.com wrote: For windows (vista 64bit?), if you hit gclient hangs in general while sync'ing: Run this command (from an Administrator command prompt): netsh interface tcp set global autotuninglevel=disabled Hopefully, it will be fixed for you as it seems to be for me. Reference: http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx On Fri, Sep 25, 2009 at 5:22 PM, Nico Weber tha...@chromium.org wrote: http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba I had the impression that removing that folder once is enough, though I didn't try it more than once yet. On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson fin...@chromium.org wrote: At first I thought it was a fluke but now it just happened again. Is anyone else seeing this? I do a gclient sync and it takes forever, showing this output and looks hung: running 'svn update E:\code\src\third_party\WebKit --revision 27219' in 'E:\code' I wait and wait and wait and wait and nothing happens. I tried FileMon and couldn't see any files being accessed. Re-running gclient sync just hangs again in the same spot. The only workaround I know is to delete that folder and try again. That was fine for the first time this happens, but is getting more exponentially more frustrating with each time I have to do that. :s Anyone seen this? -F --~--~-~--~~~---~--~~ 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 hangs updating third_party/WebKit
Could we document this in the dev wiki? I forgot to run this when I installed my new machine :( On Fri, Sep 25, 2009 at 8:52 PM, Mohamed Mansour m...@chromium.org wrote: Thanks! That worked for me on Windows 7 64bit! -Mohamed On Fri, Sep 25, 2009 at 8:39 PM, David Levin le...@google.com wrote: For windows (vista 64bit?), if you hit gclient hangs in general while sync'ing: Run this command (from an Administrator command prompt): netsh interface tcp set global autotuninglevel=disabled Hopefully, it will be fixed for you as it seems to be for me. Reference: http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx On Fri, Sep 25, 2009 at 5:22 PM, Nico Weber tha...@chromium.org wrote: http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba I had the impression that removing that folder once is enough, though I didn't try it more than once yet. On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson fin...@chromium.org wrote: At first I thought it was a fluke but now it just happened again. Is anyone else seeing this? I do a gclient sync and it takes forever, showing this output and looks hung: running 'svn update E:\code\src\third_party\WebKit --revision 27219' in 'E:\code' I wait and wait and wait and wait and nothing happens. I tried FileMon and couldn't see any files being accessed. Re-running gclient sync just hangs again in the same spot. The only workaround I know is to delete that folder and try again. That was fine for the first time this happens, but is getting more exponentially more frustrating with each time I have to do that. :s Anyone seen this? -F --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
Thanks for taking on this feature! Some comments: ChromeClientChromium will implement the runJavaScriptRegisterProtocolHandler method in the ChromeClientImpl class in webkit/glue/chrome_client_impl.h. Are you sure you need to add this method to ChromeClientChromium? That interface is only to be used when the method doesn't exist on ChromeClient. Only supporting a whitelist of schemes sounds best to me. What does Firefox allow? Before you venture too far into the implementation, I'd like to see what the proposed WebKit API changes will be. This would be a good thing to add to your design doc. Thanks, -Darin On Thu, Sep 24, 2009 at 12:51 PM, b...@chromium.org wrote: I've shared a document with you: [HTML5] registerProtocolHandler API http://docs.google.com/Doc?docid=0AVgZ1iILHLkdZGQ0bjd6cTVfMGdqZmpiNGZrhl=eninvite=CI6z8vgG It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above. This is a design document for the worked needed to resolve http://crbug.com/11359 beyond the webkit implementation. Please feel free to comment inline or in this thread. I look forward to your critics and suggestions. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
