[chromium-dev] Re: Memory usage in chrome
FWIW, I strongly believe we should move the default to --memory-model=high. This is what pretty much every other app in the world does, and we mostly penalize ourselves when the OS aggressively swaps us out for a dumb reason (which yes, Windows does do). We have a lot of complaints of I came back the next hour/day/whatever and everything was unresponsive. I don't think our current tradeoff is the right one. I know Mike wants to be a good citizen and feels like if the OS swapped you out it really needed that RAM, but in my own observations of my machine the OS swaps for retarded reasons and I gain nothing but headaches. 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: about gtest's main in chromium
yep, for base_unittests, that's true. But what I want to know is how chromium uses GTest. An important problem is how it runs all the GTest projects. Take the simplest GTest project printing_unittests as an example, I know it's run via GTest's main in run_all_unittests.cc. But I don't know how it invokes the main. I checked the project properties of printing_unittests, and didn't find a link to gtestmain.lib as I always do while writing GTest tests. 2009/6/23 Adam Langley a...@chromium.org On Mon, Jun 22, 2009 at 7:55 PM, Jickae Davisjick...@gmail.com wrote: But I find something weird in the chromiun's GTest projects, they neither write a main nor link a gtest_main.lib. How do they start GTest? Well, you can always set a breakpoint at main and see where you end up. For base_unittests, it's base/run_all_unittests.cc for example. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] layout test can't run
I run it on Microsoft Windows XP Professional with SP2, not Vista. nbsp; The flag is --nocheck-sys-deps, right? I don't want to use that flag really. The reason is what you've mentioned, many of the layout tests may fail with that flag. That deviates from my goal. I want to use the layout test to test my codes in webkit/port/glue. nbsp; But what depressing is I just can't start it. What Windows are you on? Vista cannot run some of the layout tests.燑div There is a flag you can pass to run_webkit_tests to get it to ignore the system dependencies check. I don't remember the name off the top of my head. To find it run:爎un_webkit_tests.sh --help燑/div The flag will let you run the tests on Vista, but many of them will fail. Ojan 2009/6/22 Rosail Davis sitan2...@sina.com 營've changed the .gclient, and downloaded the layout tests.But I can't run it, it just always give me a msg back: 燑/p ### ## Layout test system dependencies check failed. ## Some layout tests may fail due to unexpected theme. ## ## To fix, go to Display Properties - Appearance, and select: ## + Windows and buttons: Windows XP style ## + Color scheme: Default (blue) ## + Font size: Normal ### 燑/p I've done these 3 instructions,爃ad all fonts installed already, and still get the msg, why? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] HTML5 Web Socket design doc
Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Thanks, ukai --~--~-~--~~~---~--~~ 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: about gtest's main in chromium
printing_unittests depends on gtestmain.lib. See src/printing/printing.gyp. On Wed, Jun 24, 2009 at 12:46 AM, Jickae Davisjick...@gmail.com wrote: yep, for base_unittests, that's true. But what I want to know is how chromium uses GTest. An important problem is how it runs all the GTest projects. Take the simplest GTest project printing_unittests as an example, I know it's run via GTest's main in run_all_unittests.cc. But I don't know how it invokes the main. I checked the project properties of printing_unittests, and didn't find a link to gtestmain.lib as I always do while writing GTest tests. 2009/6/23 Adam Langley a...@chromium.org On Mon, Jun 22, 2009 at 7:55 PM, Jickae Davisjick...@gmail.com wrote: But I find something weird in the chromiun's GTest projects, they neither write a main nor link a gtest_main.lib. How do they start GTest? Well, you can always set a breakpoint at main and see where you end up. For base_unittests, it's base/run_all_unittests.cc for example. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: layout test can't run
This phenomenon is reproducible in my environment, too. It's probably because localized Windows may have some different metrics on window appearance. Try the following workaround: 1. Open Display Properties dialog. 2. Go to Design tab and press Details button. 3. For each item which has a configurable Font property, change the font to Tahoma, and the size to 8. 4. Press OK and close all the dialogs. If the layout test still doesn't work, you may want to look at src/webkit/tools/test_shell/test_shell_platform_delegate_win.cc, which includes the actual check code. Thanks, Yuta 2009/6/23 Rosail Davis sitan2...@sina.com I've changed the .gclient, and downloaded the layout tests.But I can't run it, it just always give me a msg back: ### ## Layout test system dependencies check failed. ## Some layout tests may fail due to unexpected theme. ## ## To fix, go to Display Properties - Appearance, and select: ## + Windows and buttons: Windows XP style ## + Color scheme: Default (blue) ## + Font size: Normal ### I've done these 3 instructions, had all fonts installed already, and still get the msg, why? --~--~-~--~~~---~--~~ 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 do I deploy an NPAPI plugin over the internet from HTML ?
I have an NPAPI plugin (that I originally wrote for Firefox) which I
want to download to Chrome over the internet using an embedded object
(using either EMBED or OBJECT, I don't mind which).
My plugin works fine under Chrome once I've manually copied the files
to a location that Chrome knows about using either of the following
manual methods:
1) Using the Mozilla-defined plugin-finder system where you:
* Copy the plugin files to a directory on the local system
* Add registry entries to HKLM\SOFTWARE\MozillaPlugins
to point to your plugin
or
2) Copy the plugin files to the plugins subdirectory of Chrome
The problem that I have is getting the plugin downloaded over the
internet and installed into a location that Chrome knows about.
IE has a mechanism for downloading an ActiveX Control (wrapped in
a .CAB file) via an OBJECT tag, and Firefox has a mechanism for
downloading an NPAPI Plugin (wrapped in an .XPI file) via an EMBED
tag.
Although Chrome supports NPAPI plugins, the thing that I am missing is
how to automatically deploy it over the internet using an EMBED tag.
That is, I want to avoid putting text on my web page saying something
like If you are using the Chrome browser, click here to install the
plugin CAB and get the user to manually click on that link to
install.
I am using the dev-channel release of Chrome version 3.0.189.0.
I have the --enable-extensions flag appended to my Chrome.exe command
line.
I packaged my plugin files plus a manifest.json file into a .crx file
using the method described in
http://dev.chromium.org/developers/design-documents/extensions/packaging
and use an EMBED tag in my HTML to invoke it. However, when I invoke
the HTML, Chrome does not download and install the extension and
plugin. It simply states No plugin available to display this
content.
My plugin is in the plugins subdirectory relative to my
manifest.json file at the point that I use Chrome.exe to produce
the .CRX file.
The EMBED tag I am using is as follows:
embed id=MY_PLUGIN type=application/my-plugin
width=640 height=480
pluginspage=http://mysite.com/test/npapi/chrome/
myplugin.crx
My manifest.json file contains:
{
name: My plugin - NPAPI Plugin,
description: My plugin - NPAPI Plugin,
version: 1.0.0.0,
format_version: 1,
id: 0100250D31938CE363354F8282F68C24EBF5B542,
plugins: [ { path: plugins/npmyplugin.dll, public:
false } ]
}
However, Chrome isn't downloading my CRX file and installing the
extension and plugin.
What am I doing wrong ?
--~--~-~--~~~---~--~~
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: Memory usage in chrome
+1. Most people are not doing compiles, we're trying to say that people live in the web and in their browser, and that their browser is the primary application. For me at least, that is true. The browser is the app I use the most -- the only other app I use regularly is an ssh client, which can usually fit in memory or get swapped back in much quicker than Chrome. 2009/6/23 Peter Kasting pkast...@chromium.org FWIW, I strongly believe we should move the default to --memory-model=high. This is what pretty much every other app in the world does, and we mostly penalize ourselves when the OS aggressively swaps us out for a dumb reason (which yes, Windows does do). We have a lot of complaints of I came back the next hour/day/whatever and everything was unresponsive. I don't think our current tradeoff is the right one. I know Mike wants to be a good citizen and feels like if the OS swapped you out it really needed that RAM, but in my own observations of my machine the OS swaps for retarded reasons and I gain nothing but headaches. 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: Memory usage in chrome
Could we stat at memory-model=hight and then change our memory model mid-flight if there are any large, non-chrome, memory hungry processes? -- Elliot On Wed, Jun 24, 2009 at 9:39 AM, Ian Fettei...@chromium.org wrote: +1. Most people are not doing compiles, we're trying to say that people live in the web and in their browser, and that their browser is the primary application. For me at least, that is true. The browser is the app I use the most -- the only other app I use regularly is an ssh client, which can usually fit in memory or get swapped back in much quicker than Chrome. 2009/6/23 Peter Kasting pkast...@chromium.org FWIW, I strongly believe we should move the default to --memory-model=high. This is what pretty much every other app in the world does, and we mostly penalize ourselves when the OS aggressively swaps us out for a dumb reason (which yes, Windows does do). We have a lot of complaints of I came back the next hour/day/whatever and everything was unresponsive. I don't think our current tradeoff is the right one. I know Mike wants to be a good citizen and feels like if the OS swapped you out it really needed that RAM, but in my own observations of my machine the OS swaps for retarded reasons and I gain nothing but headaches. 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: Memory usage in chrome
On Wed, Jun 24, 2009 at 9:39 AM, Ian Fette i...@chromium.org wrote: +1. Most people are not doing compiles, we're trying to say that people live in the web and in their browser, and that their browser is the primary application. For me at least, that is true. The browser is the app I use the most -- the only other app I use regularly is an ssh client, which can usually fit in memory or get swapped back in much quicker than Chrome. This doesn't make sense as a use case, because if there is nothing else eating your memory, then the memory doesn't have to swap in. It's already there! :-) For users with plenty of RAM like you, memory-model=medium should work just fine. The only people that might be effected by this is people that do have something else competing for the memory (like a compile, or they are on a low-memory box and outlook is eating it). I do worry that virus scanners could churn through memory causing similar effects, but again, we measured for this and so far have been unable to detect any difference. At this point we could change to memory-model=high, despite having no real-world data that this is a problem. Chrome would be perceived to use 25% more memory, and the folks on this thread that have compiles going might feel a better experience. If we don't care about a 25% jump in memory use then we should switch the default even though data suggests it won't help. One more possibility: maybe there is a bug we haven't yet identified. Mike 2009/6/23 Peter Kasting pkast...@chromium.org FWIW, I strongly believe we should move the default to --memory-model=high. This is what pretty much every other app in the world does, and we mostly penalize ourselves when the OS aggressively swaps us out for a dumb reason (which yes, Windows does do). We have a lot of complaints of I came back the next hour/day/whatever and everything was unresponsive. I don't think our current tradeoff is the right one. I know Mike wants to be a good citizen and feels like if the OS swapped you out it really needed that RAM, but in my own observations of my machine the OS swaps for retarded reasons and I gain nothing but headaches. 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: Memory usage in chrome
I am willing to volunteer to be a test case if you need one, tell me what to do so you will be able to monitor.Before I added that switch, it was pretty horrible. Though I am building stuff with Java, XSLT, JavaScript that process a lot of files (HTMLs) and viewing and refreshing a lot of pages (in Chrome, mostly, but sometimes in other browsers for cross browser support), plus Eclipse and Outlook, if it matters. ☆PhistucK On Wed, Jun 24, 2009 at 19:46, Mike Belshe mbel...@google.com wrote: On Wed, Jun 24, 2009 at 9:39 AM, Ian Fette i...@chromium.org wrote: +1. Most people are not doing compiles, we're trying to say that people live in the web and in their browser, and that their browser is the primary application. For me at least, that is true. The browser is the app I use the most -- the only other app I use regularly is an ssh client, which can usually fit in memory or get swapped back in much quicker than Chrome. This doesn't make sense as a use case, because if there is nothing else eating your memory, then the memory doesn't have to swap in. It's already there! :-) For users with plenty of RAM like you, memory-model=medium should work just fine. The only people that might be effected by this is people that do have something else competing for the memory (like a compile, or they are on a low-memory box and outlook is eating it). I do worry that virus scanners could churn through memory causing similar effects, but again, we measured for this and so far have been unable to detect any difference. At this point we could change to memory-model=high, despite having no real-world data that this is a problem. Chrome would be perceived to use 25% more memory, and the folks on this thread that have compiles going might feel a better experience. If we don't care about a 25% jump in memory use then we should switch the default even though data suggests it won't help. One more possibility: maybe there is a bug we haven't yet identified. Mike 2009/6/23 Peter Kasting pkast...@chromium.org FWIW, I strongly believe we should move the default to --memory-model=high. This is what pretty much every other app in the world does, and we mostly penalize ourselves when the OS aggressively swaps us out for a dumb reason (which yes, Windows does do). We have a lot of complaints of I came back the next hour/day/whatever and everything was unresponsive. I don't think our current tradeoff is the right one. I know Mike wants to be a good citizen and feels like if the OS swapped you out it really needed that RAM, but in my own observations of my machine the OS swaps for retarded reasons and I gain nothing but headaches. 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: layout test can't run
2009/6/24 Rosail Davis sitan2...@sina.com: I don't want to use that flag really. The reason is what you've mentioned, many of the layout tests may fail with that flag. That deviates from my goal. I want to use the layout test to test my codes in webkit/port/glue. It seems the first step, then, will be debugging why you get the error message. I suggest setting a breakpoint near where it's printed and tracing through the code. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How do I deploy an NPAPI plugin over the internet from HTML ?
On Wed, Jun 24, 2009 at 4:42 AM, Non-Stick kevin.ra...@ntlworld.comwrote:: embed id=MY_PLUGIN type=application/my-plugin width=640 height=480 pluginspage=http://mysite.com/test/npapi/chrome/ myplugin.crx ..snip.. What am I doing wrong ? You can't embed Chrome extensions (.crx files). You can only embed NPAPI plugins. These are two different beasts. CRX files must be manually installed by the user - embed won't download them for you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Using custom builds of chromium in a commercial setting
Not sure about the theme part, Glen is the right person to answer that (cc-ed). As for keeping track of the work, your best best is to star issue 19 to get notified about when something related to that bug is checked in. We try to always include BUG=n in our checkins and then bug n will be updated automatically. You could also subscribe to the chromium-checkins group to monitor each checkin that get submitted, but that seems like overkill for what you want to do. -F On Tue, Jun 23, 2009 at 13:36, Ciaran ciar...@gmail.com wrote: As a follow up, thanks for the help. This approach works perfectly, I've found where in the code I could 'subvert' the app mechanism to allow the executable to automatically open a url on startup without passing it in the on the command line. To modify the 'theme' of the executable, I've been replacing the resources in the theme package, but this seems a little un-clean, is there a better/recommended approach than just replacing the existing files? Also as part of this wrk I stumbled upon the no-doubt infamous Issue 19 ( http://code.google.com/p/chromium/issues/detail?id=19) which I see has been chosen as a GSoC project, is there anywhere I can subscribe to in order to ascertain how far through the implementation of that piece of work peeps are, or is the GSoC process a bit of a black-box affair ? -cj On Sat, Jun 20, 2009 at 5:54 PM, Ciaran ciar...@gmail.com wrote: This sounds perfect, ideally I'd bundle a chrome exe which is pretty much locked into a particular url (or set of urls) Thanks folks I'll take a closer look :) -cj. On Sat, Jun 20, 2009 at 5:22 PM, Finnur Thorarinsson fin...@chromium.org wrote: There might be a wiki page somewhere, but to start with, the Page menu has a Create application shortcuts menu item, which helps you create shortcuts for running web sites as applications. You can also use a command line flag, such as chrome.exe --app=http://your_url/ You can use that as a starting point for digging into this feature. On Sat, Jun 20, 2009 at 02:37, Ciaran ciar...@gmail.com wrote: On Fri, Jun 19, 2009 at 6:47 PM, Evan Martin e...@chromium.org wrote: I am not a lawyer, but that is the intent. (In some sense Google Chrome is just a commercial consumer of the code base as well. As I understand it, contributors retain copyright on their contributions, so it's not even the case that Google owns all the code that mentions Google in the copyright. See http://code.google.com/legal/individual-cla-v1.0.html ) BTW, Chromium in the App Mode is more or less an SSB. Thanks for your response :) Can you elaborate further on how I would put chromium into 'App mode' ? Is there a page on the wiki or anything ? -Cj On Thu, Jun 18, 2009 at 3:45 AM, JavaJunkyciar...@gmail.com wrote: Hi folks, I'm currently investigating the possibility of using SSBs (Site Specific Browsers, another example is mozilla's Prism) to ship alongside a commercial web application, the application does not depend on the SSB in any way just makes it more acceptable to corporations who are opposed to updating to more recent web browsers. I've spent some time perusing the mailing list, and looking at the T's and C's that I can locate on the chromium website ( http://code.google.com/chromium/terms.html ). As far as I can tell the primary license and all 3rd party licenses are 'commecially friendly' and as long as the build of chromium doesn't mention Google or any of the associated trademarks then there should be no problem shipping a customised build of chromium on a cd alongside a commercial product. Can anyone confirm whether or not this is the case ? Many thanks - cj. --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
I only skimmed, but it looks well thought out. One question though: is this going to be functional for non-Chromium browsers? Given that your design doc mentions v8 and hooks into Chromium's network stack, but no mention of JavaScriptCore or WebKit's resource loading code, I'm worried that the answer is no. I strongly recommend that your design doc include details for full integration into normal WebKit and that you offer to write the necessary code. If it's Chromium only, you'll definitely get more push back on the design and people will be less willing to review. Probably to the extent that it would have been easier to just write the code to begin with. J On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote: Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Thanks, ukai --~--~-~--~~~---~--~~ 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: Using custom builds of chromium in a commercial setting
Not sure about the theme part, Glen is the right person to answer that (cc-ed). There's some basic documentation here: http://dev.chromium.org/developers/design-documents/themes More soon. As for keeping track of the work, your best best is to star issue 19 to get notified about when something related to that bug is checked in. We try to always include BUG=n in our checkins and then bug n will be updated automatically. You could also subscribe to the chromium-checkins group to monitor each checkin that get submitted, but that seems like overkill for what you want to do. -F On Tue, Jun 23, 2009 at 13:36, Ciaran ciar...@gmail.com wrote: As a follow up, thanks for the help. This approach works perfectly, I've found where in the code I could 'subvert' the app mechanism to allow the executable to automatically open a url on startup without passing it in the on the command line. To modify the 'theme' of the executable, I've been replacing the resources in the theme package, but this seems a little un-clean, is there a better/recommended approach than just replacing the existing files? Also as part of this wrk I stumbled upon the no-doubt infamous Issue 19 (http://code.google.com/p/chromium/issues/detail?id=19) which I see has been chosen as a GSoC project, is there anywhere I can subscribe to in order to ascertain how far through the implementation of that piece of work peeps are, or is the GSoC process a bit of a black-box affair ? -cj On Sat, Jun 20, 2009 at 5:54 PM, Ciaran ciar...@gmail.com wrote: This sounds perfect, ideally I'd bundle a chrome exe which is pretty much locked into a particular url (or set of urls) Thanks folks I'll take a closer look :) -cj. On Sat, Jun 20, 2009 at 5:22 PM, Finnur Thorarinsson fin...@chromium.org wrote: There might be a wiki page somewhere, but to start with, the Page menu has a Create application shortcuts menu item, which helps you create shortcuts for running web sites as applications. You can also use a command line flag, such as chrome.exe --app=http://your_url/ You can use that as a starting point for digging into this feature. On Sat, Jun 20, 2009 at 02:37, Ciaran ciar...@gmail.com wrote: On Fri, Jun 19, 2009 at 6:47 PM, Evan Martin e...@chromium.org wrote: I am not a lawyer, but that is the intent. (In some sense Google Chrome is just a commercial consumer of the code base as well. As I understand it, contributors retain copyright on their contributions, so it's not even the case that Google owns all the code that mentions Google in the copyright. See http://code.google.com/legal/individual-cla-v1.0.html ) BTW, Chromium in the App Mode is more or less an SSB. Thanks for your response :) Can you elaborate further on how I would put chromium into 'App mode' ? Is there a page on the wiki or anything ? -Cj On Thu, Jun 18, 2009 at 3:45 AM, JavaJunkyciar...@gmail.com wrote: Hi folks, I'm currently investigating the possibility of using SSBs (Site Specific Browsers, another example is mozilla's Prism) to ship alongside a commercial web application, the application does not depend on the SSB in any way just makes it more acceptable to corporations who are opposed to updating to more recent web browsers. I've spent some time perusing the mailing list, and looking at the T's and C's that I can locate on the chromium website ( http://code.google.com/chromium/terms.html ). As far as I can tell the primary license and all 3rd party licenses are 'commecially friendly' and as long as the build of chromium doesn't mention Google or any of the associated trademarks then there should be no problem shipping a customised build of chromium on a cd alongside a commercial product. Can anyone confirm whether or not this is the case ? Many thanks - cj. --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote: Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm Regarding the WebKit API, note that no WebCore data types can be used there. So you'll need to create wrapper classes that use data types available in the WebKit API (i.e. WebUrl, WebString). http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Thanks, ukai --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
Only skimmed thusfar as well... but from what i've seen, looks reasonable to
me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.
* Does WebSocketHandle really need to be refcounted. I know ResourceHandle
is a refcounted object and this design looks modeled off of that (which may
be why you've spec'd it this way). Unless your design actually needs
refcounting on this class, you may be able to simplify things without it.
From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made a
good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any code
you want to be shared code shouldn't be slated for that class. To the extent
the 'web socket protocol framing' can be done indepedent of the 'platform'
socket handle (which it looks like it can be), it would be a good thing to
put it in WebSocketChannel so its shared core common code goodness.
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
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: HTML5 Web Socket design doc
BTW, I checked in with IanH - it sounds like WebSockets are also on the
Worker roadmap, so that's something to keep in mind while you iterate on
your design.
+1 to avoiding WebCore/loader, but also +1 to refactoring to enable as much
common code as possible cross-platform - I'm looking at the Chromium worker
code now, and there's a chunk of duplicated logic from the WebKit worker
implementation, which is a bit of a maintenance headache.
-atw
2009/6/24 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.
* Does WebSocketHandle really need to be refcounted. I know ResourceHandle
is a refcounted object and this design looks modeled off of that (which may
be why you've spec'd it this way). Unless your design actually needs
refcounting on this class, you may be able to simplify things without it.
From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made a
good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any code
you want to be shared code shouldn't be slated for that class. To the extent
the 'web socket protocol framing' can be done indepedent of the 'platform'
socket handle (which it looks like it can be), it would be a good thing to
put it in WebSocketChannel so its shared core common code goodness.
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏)
u...@chromium.orgwrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
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 do you do an if-else statement in GYP?
I'd like to be able to test 'my_variable' for 'Blort' and 'Blat', but
if neither of these are true, then I'd like to execute a default. The
problem is that with the syntax below, if 'my_variable' is 'Blort',
then both path A and C will be executed; which is wrong since each of
these paths should be mutually exclusive.
'conditions': [
['my_variable==Blort', {
# path A
}],
['my_variable==Blat', {
# path B
}, {
# path C (default)
}],
To fix, I've tried re-arranging like so:
'conditions': [
['my_variable==Blort', {
# path A
}, {
['my_variable==Blat', {
# path B
}, {
# path C (default)
}],
}],
But this gives errors when you execute the gyp file (complains about a
comma). How do I accomplish this?
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: How do you do an if-else statement in GYP?
Hi Daniel:
Currently you'd have to have another whole conditional inside:
'conditions': [
['my_variable==Blort', {
# path A
}, {
'conditions:
['my_variable==Blat', {
# path B
}, {
# path C (default)
}],
}],
-BradN
On Wed, Jun 24, 2009 at 2:49 PM, Daniel Cowx daniel.c...@gmail.com wrote:
I'd like to be able to test 'my_variable' for 'Blort' and 'Blat', but
if neither of these are true, then I'd like to execute a default. The
problem is that with the syntax below, if 'my_variable' is 'Blort',
then both path A and C will be executed; which is wrong since each of
these paths should be mutually exclusive.
'conditions': [
['my_variable==Blort', {
# path A
}],
['my_variable==Blat', {
# path B
}, {
# path C (default)
}],
To fix, I've tried re-arranging like so:
'conditions': [
['my_variable==Blort', {
# path A
}, {
['my_variable==Blat', {
# path B
}, {
# path C (default)
}],
}],
But this gives errors when you execute the gyp file (complains about a
comma). How do I accomplish this?
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: How do you do an if-else statement in GYP?
Thanks for the prompt reply Brad. Cheers!
On Jun 24, 2:52 pm, Bradley Nelson bradnel...@google.com wrote:
Hi Daniel:
Currently you'd have to have another whole conditional inside:
'conditions': [
['my_variable==Blort', {
# path A
}, {
'conditions:
['my_variable==Blat', {
# path B
}, {
# path C (default)
}],
}],
-BradN
On Wed, Jun 24, 2009 at 2:49 PM, Daniel Cowx daniel.c...@gmail.com wrote:
I'd like to be able to test 'my_variable' for 'Blort' and 'Blat', but
if neither of these are true, then I'd like to execute a default. The
problem is that with the syntax below, if 'my_variable' is 'Blort',
then both path A and C will be executed; which is wrong since each of
these paths should be mutually exclusive.
'conditions': [
['my_variable==Blort', {
# path A
}],
['my_variable==Blat', {
# path B
}, {
# path C (default)
}],
To fix, I've tried re-arranging like so:
'conditions': [
['my_variable==Blort', {
# path A
}, {
['my_variable==Blat', {
# path B
}, {
# path C (default)
}],
}],
But this gives errors when you execute the gyp file (complains about a
comma). How do I accomplish this?
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: HTML5 Web Socket design doc
Also, it occurs to me that I can avoid making the problem worse by not
putting the MessagePort entanglement in the proxy layer, which my patch
currently does (ick). Proving that proper API design does enable better code
re-use :)
-atw taking my own advice
2009/6/24 John Abd-El-Malek j...@chromium.org
2009/6/24 Drew Wilson atwil...@google.com
I'm looking at the code in webworker_impl.cc and webworkerclient_impl.cpp,
vs the code in WebCore/workers/WorkerMessagingProxy.cpp.
As an example:
Chrome version:
void WebWorkerClientImpl::postMessageToWorkerContext(
const WebCore::String message) {
// Worker.terminate() could be called from JS before the context is
started.
if (asked_to_terminate_)
return;
++unconfirmed_message_count_;
if (!WTF::isMainThread()) {
WebWorkerImpl::DispatchTaskToMainThread(
WebCore::createCallbackTask(PostMessageToWorkerContextTask, this,
message));
return;
}
webworker_-postMessageToWorkerContext(
webkit_glue::StringToWebString(message));
}
WebKit version:
void WorkerMessagingProxy::postMessageToWorkerContext(const String
message)
{
if (m_askedToTerminate)
return;
if (m_workerThread) {
++m_unconfirmedMessageCount;
m_workerThread-runLoop().postTask(MessageWorkerContextTask::create(message));
} else
m_queuedEarlyTasks.append(MessageWorkerContextTask::create(message));
}
The duplications become even more apparent as I evolve these APIs to
support MessagePorts. I'm just seeing similar logic (checking for terminated
tasks, tracking undelivered messages, and soon disentangling message ports
and dealing with errors) that has to be updated in parallel in both trees.
Not a big deal, either way. Now that the Chrome implementation is pretty
stable, we might want to refactor the WorkerProxy APIs to see if we can
share more code across implementations.
It'd be great of course if unconfirmed_message_count_
and asked_to_terminate_ weren't needed, but it's used to avoid a large
number of cross process calls (the equivalent variables in WebKit would be
in a different process). Almost all the rest of the file is converting back
and forth between WebCore and Chrome data types in the glue layer, which is
a necessary pain.
-atw
2009/6/24 John Abd-El-Malek j...@chromium.org
2009/6/24 Drew Wilson atwil...@chromium.org
BTW, I checked in with IanH - it sounds like WebSockets are also on the
Worker roadmap, so that's something to keep in mind while you iterate on
your design.
+1 to avoiding WebCore/loader, but also +1 to refactoring to enable as
much common code as possible cross-platform - I'm looking at the Chromium
worker code now, and there's a chunk of duplicated logic from the WebKit
worker implementation, which is a bit of a maintenance headache.
I'm curious, which parts of the code are you talking about?
-atw
2009/6/24 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks
reasonable to me.
* A version of the diagram you have in the chrome doc would be nice in
the webkit doc too.
* Does WebSocketHandle really need to be refcounted. I know
ResourceHandle is a refcounted object and this design looks modeled off of
that (which may be why you've spec'd it this way). Unless your design
actually needs refcounting on this class, you may be able to simplify
things
without it. From the looks of it, WebSocketChannel 'owns' the
WebSocketHandle.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've
made a good decision to keep this out of there and to design the websocket
system in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any
code you want to be shared code shouldn't be slated for that class. To the
extent the 'web socket protocol framing' can be done indepedent of the
'platform' socket handle (which it looks like it can be), it would be a
good
thing to put it in WebSocketChannel so its shared core common code
goodness.
Regarding the WebKit API, note that no WebCore data types can be
used there. So you'll need to create wrapper classes.
I see you have speced WebKit:: wrapper classes with the same name as
the corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
On Wed, Jun 24, 2009 at
[chromium-dev] Re: HTML5 Web Socket design doc
On Jun 24, 2:32 am, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote: Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part:http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part:http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Interesting feature :) It's hard to tell at first glance, because the security section is empty -- but it appears like security has been considered at least in http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17. It might be worth being more explicit about security in our WebKit doc (i.e. creating a new security section). Possible tests we'll want include: - Connect a web socket to some ordinary HTTP server and confirm that the connect fails. - Connect a web socket to a real web socket server that fails to return a websocket-origin header, and validate that the connect fails (if it didn't, a simple server bug could open up responses to all origins) - Check we respect the origin sent from the server. - What about redirectors? Assuming unsupported, verify that connecting to a redirector does not cause any redirection. - URL integration: what happens if a ws:// or wss:// URL is entered into the URL bar, or any other place an URL is accepted? (img tags, script tags etc). - What about embedded newline characters in the various strings the client gets to specify (URL, resource name, protocol etc). Ensure that no lines sent to the server can be caused to be split by doing this. - Length encoding: ensure we handle excessively long length encodings, e.g. 0xff 0xff 0xff... ad infinitum. Test we can handle decoded lengths that happen to be negative (or very large) when assigned to int32, int64, uint32, uint64. - Cookies: ensure we _never_ transmit any HTTP cookies over the unencrypted ws:// channel, if that cookie was marked Secure. Similar test for Authorization headers. Cheers Chris Thanks, ukai --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
On Jun 24, 2:32 am, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote: Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part:http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part:http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Interesting feature :) It's hard to tell at first glance, because the security section is empty -- but it appears like security has been considered at least in http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17. It might be worth being more explicit about security in our WebKit doc (i.e. creating a new security section). Possible tests we'll want include: - Connect a web socket to some ordinary HTTP server and confirm that the connect fails. - Connect a web socket to a real web socket server that fails to return a websocket-origin header, and validate that the connect fails (if it didn't, a simple server bug could open up responses to all origins) - Check we respect the origin sent from the server. - What about redirectors? Assuming unsupported, verify that connecting to a redirector does not cause any redirection. - URL integration: what happens if a ws:// or wss:// URL is entered into the URL bar, or any other place an URL is accepted? (img tags, script tags etc). - What about embedded newline characters in the various strings the client gets to specify (URL, resource name, protocol etc). Ensure that no lines sent to the server can be caused to be split by doing this. - Length encoding: ensure we handle excessively long length encodings, e.g. 0xff 0xff 0xff... ad infinitum. Test we can handle decoded lengths that happen to be negative (or very large) when assigned to int32, int64, uint32, uint64. - Cookies: ensure we _never_ transmit any HTTP cookies over the unencrypted ws:// channel, if that cookie was marked Secure. Similar test for Authorization headers. Cheers Chris Thanks, ukai --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
On Jun 24, 2:32 am, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote: Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part:http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part:http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Interesting feature :) It's hard to tell at first glance, because the security section is empty -- but it appears like security has been considered at least in http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17. It might be worth being more explicit about security in our WebKit doc (i.e. creating a new security section). Possible tests we'll want include: - Connect a web socket to some ordinary HTTP server and confirm that the connect fails. - Connect a web socket to a real web socket server that fails to return a websocket-origin header, and validate that the connect fails (if it didn't, a simple server bug could open up responses to all origins) - Check we respect the origin sent from the server. - What about redirectors? Assuming unsupported, verify that connecting to a redirector does not cause any redirection. - URL integration: what happens if a ws:// or wss:// URL is entered into the URL bar, or any other place an URL is accepted? (img tags, script tags etc). - What about embedded newline characters in the various strings the client gets to specify (URL, resource name, protocol etc). Ensure that no lines sent to the server can be caused to be split by doing this. - Length encoding: ensure we handle excessively long length encodings, e.g. 0xff 0xff 0xff... ad infinitum. Test we can handle decoded lengths that happen to be negative (or very large) when assigned to int32, int64, uint32, uint64. - Cookies: ensure we _never_ transmit any HTTP cookies over the unencrypted ws:// channel, if that cookie was marked Secure. Similar test for Authorization headers. Cheers Chris Thanks, ukai --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] unable to load generated resources
I am building ToT chromium, and dying with a DCHECK here: DCHECK(locale_resources_data_ != NULL) unable to load generated resources; It is trying to load en.dll. However en.dll doesn't exist. If I use a fresh profile this works, as it ends up instead loading en-US.dll which does exist. Is this normal? or is my profile hosed? --~--~-~--~~~---~--~~ 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: about gtest's main in chromium
ah, in fact, I don't really understand what the .gyp files do. Could the gtestmain be found in printing_unittests' project properties under VS2005? I have check that, and didn't find a gtestmain.lib in Configuration Properties--Linker--Input. 2009/6/25 William Chan (陈智昌) willc...@chromium.org printing_unittests depends on gtestmain.lib. See src/printing/printing.gyp. On Wed, Jun 24, 2009 at 12:46 AM, Jickae Davisjick...@gmail.com wrote: yep, for base_unittests, that's true. But what I want to know is how chromium uses GTest. An important problem is how it runs all the GTest projects. Take the simplest GTest project printing_unittests as an example, I know it's run via GTest's main in run_all_unittests.cc. But I don't know how it invokes the main. I checked the project properties of printing_unittests, and didn't find a link to gtestmain.lib as I always do while writing GTest tests. 2009/6/23 Adam Langley a...@chromium.org On Mon, Jun 22, 2009 at 7:55 PM, Jickae Davisjick...@gmail.com wrote: But I find something weird in the chromiun's GTest projects, they neither write a main nor link a gtest_main.lib. How do they start GTest? Well, you can always set a breakpoint at main and see where you end up. For base_unittests, it's base/run_all_unittests.cc for example. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] yet another browser benchmark
http://www.codexon.com/posts/a-real-benchmark-real-websites-with-chrome-firefox-opera-safari-ie Brief summary: - measures warm-disk-based snapshots of real websites - hand-injected script src into pages that uses addEventListener(load) / attachEvent(onload) to tell when load is done (I wonder if parallel script loading plays into it?) - statistical methodology isn't the greatest - concludes with a three-way tie between Chrome, Safari, and Opera Both Chrome and Safari are similarly significantly slower (around 200ms over IE/FF/Opera) for their Baidu test. WebKit bug or measuring bug? This makes me wonder if it'd be helpful for us to publish a blog post on how to do a benchmark. Would mention stuff like whether DOMContentReady includes image loads completion on all browsers (I certainly don't know), geometric mean vs arithmetic mean, whether we expect networking stacks to have an impact on real perf, etc. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: unable to load generated resources
See http://code.google.com/p/chromium/issues/detail?id=15286 http://code.google.com/p/chromium/issues/detail?id=15286This seems to be a regression from (or a latent bug uncovered by) http://src.chromium.org/viewvc/chrome?view=revrevision=19183 Jungshik is looking into it. On Wed, Jun 24, 2009 at 20:32, Eric Roman ero...@chromium.org wrote: I am building ToT chromium, and dying with a DCHECK here: DCHECK(locale_resources_data_ != NULL) unable to load generated resources; It is trying to load en.dll. However en.dll doesn't exist. If I use a fresh profile this works, as it ends up instead loading en-US.dll which does exist. Is this normal? or is my profile hosed? --~--~-~--~~~---~--~~ 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: What's the real reason of giving up Windows 2000 support?
I presume that Chromium decided to support Windows 2000 when the project started in 2006. The reasons may be: (1) The profit is big. There were 6% Windows 2000 users in 2006. (2) The cost is small. There should not be too many differences between Windows 2000 (5.0) and Windows XP (5.1). Afterward, Chromium decided to cut out Windows 2000 when the project grew up in 2008. The reasons may be: (1) The profit is small. There were only 2% Windows 2000 users in 2008. Surely, there would be fewer users in future. Furthermore, most of these remaining users were in corporate environments that were locked-down against using chrome as a third party program. (2) The cost is big. Certain of functions need to be implemented cumbersomely for compatibility with Windows 2000. Moreover, some undocumented features of Windows 2000 lead to extra failures. For example, when initializing an impersonated thread of a restricted sandbox process, nt!ZwMapViewOfSection succeeds on Windows XP, but fails as 0xc022 STATUS_ACCESS_DENIED on Windows 2000. Is it right? cpu wrote: Yes, the real reason is that there is an ongoing cost of keep that version working including extra QA cycles for each release. In terms of supporting a windows version with very few users we should focus our efforts on Win7. But you are welcome to keep an external fork. If there is any consolation, this was argued at length a year ago. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
