[chromium-dev] Re: What is the best way to get document location from an NPAPI plugin?
I was referring to what I sniffed in IPC traffic: NPN_GetProperty is called on "location" and the returned object is NPN_Invoke'd to call "toString" Isn't this what you mean? If you observed something else, we should figure out what the discrepancy is! On Tue, Jun 9, 2009 at 3:36 PM, Adam Barth wrote: > Flash does something similar, but not *precisely* the same. I stand > by my statement that the below is insecure. > > Adam > > > On Mon, Jun 8, 2009 at 8:08 PM, John Abd-El-Malek wrote: > > BTW this is how Flash does it. > > > > On Mon, Jun 8, 2009 at 7:47 PM, Adam Barth wrote: > >> > >> On Mon, Jun 8, 2009 at 1:29 PM, vijay wrote: > >> > We used to use NPN_GetURL with "javascript:document.location" as the > >> > URL. In the current implementation, after this script is executed in > >> > WebPluginImpl::ExecuteScript (in src/webkit/glue/webplugin_impl.cc), > >> > its checking the result value: > >> > >> This is not a secure way to determine which page embedded the plug-in. > >> If you require this value to make a security decision, you should use > >> a different approach. > >> > >> 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: What is the best way to get document location from an NPAPI plugin?
Here's a demo of an attack that works in Chrome: http://webblaze.org/abarth/tests/document-location/ Flash does something similar, but not *precisely* what Vijay proposed. This approach is extremely fragile. If you require this value to make a security decision, I recommend a different approach (as I have now stated multiple times). Adam On Tue, Jun 9, 2009 at 1:16 AM, John Abd-El-Malek wrote: > I was referring to what I sniffed in IPC traffic: > NPN_GetProperty is called on "location" > and the returned object is NPN_Invoke'd to call "toString" > Isn't this what you mean? If you observed something else, we should figure > out what the discrepancy is! > On Tue, Jun 9, 2009 at 3:36 PM, Adam Barth wrote: >> >> Flash does something similar, but not *precisely* the same. I stand >> by my statement that the below is insecure. >> >> Adam >> >> >> On Mon, Jun 8, 2009 at 8:08 PM, John Abd-El-Malek wrote: >> > BTW this is how Flash does it. >> > >> > On Mon, Jun 8, 2009 at 7:47 PM, Adam Barth wrote: >> >> >> >> On Mon, Jun 8, 2009 at 1:29 PM, vijay wrote: >> >> > We used to use NPN_GetURL with "javascript:document.location" as the >> >> > URL. In the current implementation, after this script is executed in >> >> > WebPluginImpl::ExecuteScript (in src/webkit/glue/webplugin_impl.cc), >> >> > its checking the result value: >> >> >> >> This is not a secure way to determine which page embedded the plug-in. >> >> If you require this value to make a security decision, you should use >> >> a different approach. >> >> >> >> 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: What is the best way to get document location from an NPAPI plugin?
My question to you is what you see Flash doing. I pasted below what I observed by looking at their NPN calls. On Tue, Jun 9, 2009 at 5:23 PM, Adam Barth wrote: > Here's a demo of an attack that works in Chrome: > > http://webblaze.org/abarth/tests/document-location/ > > Flash does something similar, but not *precisely* what Vijay proposed. > This approach is extremely fragile. If you require this value to > make a security decision, I recommend a different approach (as I have > now stated multiple times). > > Adam > > > On Tue, Jun 9, 2009 at 1:16 AM, John Abd-El-Malek wrote: > > I was referring to what I sniffed in IPC traffic: > > NPN_GetProperty is called on "location" > > and the returned object is NPN_Invoke'd to call "toString" > > Isn't this what you mean? If you observed something else, we should > figure > > out what the discrepancy is! > > On Tue, Jun 9, 2009 at 3:36 PM, Adam Barth wrote: > >> > >> Flash does something similar, but not *precisely* the same. I stand > >> by my statement that the below is insecure. > >> > >> Adam > >> > >> > >> On Mon, Jun 8, 2009 at 8:08 PM, John Abd-El-Malek > wrote: > >> > BTW this is how Flash does it. > >> > > >> > On Mon, Jun 8, 2009 at 7:47 PM, Adam Barth > wrote: > >> >> > >> >> On Mon, Jun 8, 2009 at 1:29 PM, vijay wrote: > >> >> > We used to use NPN_GetURL with "javascript:document.location" as > the > >> >> > URL. In the current implementation, after this script is executed > in > >> >> > WebPluginImpl::ExecuteScript (in > src/webkit/glue/webplugin_impl.cc), > >> >> > its checking the result value: > >> >> > >> >> This is not a secure way to determine which page embedded the > plug-in. > >> >> If you require this value to make a security decision, you should > use > >> >> a different approach. > >> >> > >> >> 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: Zygote mode on by default in Linux now. Here's how to disable it...
Does this mean the zygote manager process is the parent process for the browser process and all renderer processes? Whereas before the browser process was the parent to all renderer processes. On Mon, Jun 8, 2009 at 5:39 PM, Dan Kegel wrote: > > http://src.chromium.org/viewvc/chrome?view=rev&revision=17909 enabled > zygote mode on Linux by default. This changes how processes > work on Linux; the initial process becomes a fork server, > and holds open file descriptors for the .pak files. > This lets us continue running even if the app is > updated or uninstalled while we're running. The > next time you restart, the new files will take effect. > > If for some reason (say, you don't like the fact that the > main process is now this funky fork server) you want to > go back to how things were before temporarily, > you can disable zygote mode by doing > export DISABLE_ZYGOTE_MANAGER=x > before running. > > The valgrind ui_test bots are currently greener than they should > be, possibly because zygote mode is interfering with > how I set ui_test mode up under valgrind. I'll have a > look at that tomorrow. > > > > --~--~-~--~~~---~--~~ 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: Zygote mode on by default in Linux now. Here's how to disable it...
Yeah, I just took a poke at this, it seems that zygote \ browser \ renderer \ renderer ... Is there a design document or anything somewhere? Also, did we get an measurements on tab startup performance, memory sharing, etc? On Tue, Jun 9, 2009 at 10:57 AM, Lei Zhang wrote: > > Does this mean the zygote manager process is the parent process for > the browser process and all renderer processes? Whereas before the > browser process was the parent to all renderer processes. > > On Mon, Jun 8, 2009 at 5:39 PM, Dan Kegel wrote: >> >> http://src.chromium.org/viewvc/chrome?view=rev&revision=17909 enabled >> zygote mode on Linux by default. This changes how processes >> work on Linux; the initial process becomes a fork server, >> and holds open file descriptors for the .pak files. >> This lets us continue running even if the app is >> updated or uninstalled while we're running. The >> next time you restart, the new files will take effect. >> >> If for some reason (say, you don't like the fact that the >> main process is now this funky fork server) you want to >> go back to how things were before temporarily, >> you can disable zygote mode by doing >> export DISABLE_ZYGOTE_MANAGER=x >> before running. >> >> The valgrind ui_test bots are currently greener than they should >> be, possibly because zygote mode is interfering with >> how I set ui_test mode up under valgrind. I'll have a >> look at that tomorrow. >> >> > >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Zygotes [was Re: [chromium-dev] Re: Avoiding crash after autoupdate on Linux]
On Tue, May 26, 2009 at 10:54 PM, Evan Martin wrote: > > On Tue, May 26, 2009 at 1:06 PM, Adam Langley wrote: >> But we've gone over this before? Zygotes disable ASLR, make debugging harder >> etc. They might have some performance benefits, but I don't believe that >> they're the correct solution for the auto update issue. > > I suggested Dan bring this up on chromium-dev so we could hash it out > publicly. :) > > (For context for the rest of the list: the question is whether we > re-fork a preforked "zygote" renderer subprocess or do a new fork/exec > of our binary when we want a new renderer process.) > > Here's a list of the issues I've heard about. > > > ASLR: you say it disables ASLR, but it seems you get whatever > randomized address space the initial zygote got. Net effect is that > within a given browser instance each renderer will have the same > layout. How bad is that? (Honest question, not suggesting it isn't > bad.) There are two things that seemed medium bad to me about zygotes and ASLR. - The renderers always have the same layout, meaning if you could find some bug that allowed you to spawn a new tab/process, attack it, and let it crash, you could brute force addresses until you hit it. Although, I suppose the probability is similar either way. - The browser and renderers share the same layout. If you can find a pointer leak / bug in the renderer, you then know the address layout to try and attack the browser process. > > Debugging: you say it's harder, but I'm not sure why. Because of the > renderer-cmd-prefix stuff? But gdb is just as capable of attaching to > a pid -- rather than --renderer-cmd-prefix='xterm -e gdb' we could > just as well do --renderer-cmd-pid-prefix='xterm -e gdb -p'. > > On the pro-zygote side, issues we have: > > Updates clobbering our files. If we open everything before we fork > we're good. (I'm not confident that we can open everything we want > before we fork -- the inspector is a collection of random files > scattered in /usr/share. But the inspector problem applies to any > solution I've yet seen and we ought to be able to pack it into one > mmappable file if we want.) > > Sharing: with zygotes, each instance of webkit shares memory pages, > even the ones we tweak after renderer startup but before we fork. > > Performance: may be faster to start renderers if we've preforked. > > Sharing/performance of course don't count as benefits until we have > numbers to support them. Dan did preliminary measurements and found > no perf win, but I don't know if we have tests that measure the > performance of starting many tabs. > >> However, we could easily make a hardlink with a specific version in the name. >> That could go wrong if packaging systems write the same inode when updating >> rather than creating a new one, but I suspect that they don't. A patch to use >> the zygote hammer for the auto-updating issue would first have to show that >> there's no easier alternatives! > > I don't have a strong opinion on what we should do here beyond "right > now we're broken and we should fix that". We can imagine many > solutions but each time there's a bit of hand-waving. Perhaps you > could make a concrete counterproposal? (Again, I don't mean that to > sound as hostile as it might seem -- I honestly think it'd be good to > be able to weigh pros/cons of approaches.) > > > > --~--~-~--~~~---~--~~ 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: confused with chrome's version control
After carefully check, I think I am confused about continuous and snapshot, :(. Amanda said: continuous: ever time anyone checks in a change, we have a continuous build system that checks out the change and tries to build Chromium. snapshot: a snapshot build is simply a copy of chromium that was successfully built by the continuous build system (that is, each snapshot is the most recent build that did not fail for some reason). Mohomed said: continuous is the most recent revision that passed both unit tests and layout tests. snapshots is exactly what that word defines. Chromium keeps snapshots of specific revisions in history, so you can go back in time. dhhwai said: Continuous builds are those snapshot builds that have passed all the automated tests. Snapshot builds are current, on the fly, development builds whenever a developer has checked in changes for recompiling. You get a snapshot build whenever there is a successful compile. Let me make the question clear : Continuous : builded successfully, tested successfully Snapshot:only builded successfully tarball: the latest version that is builded and tested successfully while a day ends right? --~--~-~--~~~---~--~~ 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: confused with chrome's version control
And I also encountered a new question. How to update to certain revision of different kinds(snapshot/continuous/tarball). For example, I want chrome r17830 of snapshot/continuous/tarball. --~--~-~--~~~---~--~~ 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: confused with chrome's version control
On Tue, Jun 9, 2009 at 9:25 AM, Jickae Davis wrote: > After carefully check, I think I am confused about continuous and snapshot, > :(. > > Amanda said: > continuous: ever time anyone checks in a change, we have a continuous build > system that checks out the change and tries to build Chromium. > snapshot: a snapshot build is simply a copy of chromium that was > successfully built by the continuous build system (that is, each snapshot is > the most recent build that did not fail for some reason). > > Mohomed said: > continuous is the most recent revision that passed both unit tests and > layout tests. > snapshots is exactly what that word defines. Chromium keeps snapshots of > specific revisions in history, so you can go back in time. > > dhhwai said: > Continuous builds are those snapshot builds that have passed all the > automated tests. > Snapshot builds are current, on the fly, development builds whenever a > developer has checked in changes for recompiling. You get a snapshot > build whenever there is a successful compile. > > Let me make the question clear : > > Continuous : builded successfully, tested successfully > Snapshot:only builded successfully > tarball: the latest version that is builded and tested > successfully while a day ends > > right? > > Yes, the one addition is the tarball is raw source, the other two are built binaries. > > > > --~--~-~--~~~---~--~~ 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: confused with chrome's version control
>From the very end of http://dev.chromium.org/developers/how-tos/get-the-code gclient sync --revision s...@ TVL On Tue, Jun 9, 2009 at 9:27 AM, Jickae Davis wrote: > And I also encountered a new question. > > How to update to certain revision of different > kinds(snapshot/continuous/tarball). > > For example, I want chrome r17830 of snapshot/continuous/tarball. > > > > --~--~-~--~~~---~--~~ 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: Zygote mode on by default in Linux now. Here's how to disable it...
On Tue, Jun 9, 2009 at 3:59 AM, Dean McNamee wrote: > On Tue, Jun 9, 2009 at 10:57 AM, Lei Zhang wrote: >> Does this mean the zygote manager process is the parent process for >> the browser process and all renderer processes? Whereas before the >> browser process was the parent to all renderer processes. > > Yeah, I just took a poke at this, it seems that > > zygote > \ browser > \ renderer > \ renderer ... Yes. I tried leaving the initial process as browser, and making the zygote its first child, but it was hard to get all the UI tests passing that way (the process filtering in chrome_process_utils.cc in particular didn't work that way). > Is there a design document or anything somewhere? No, but I can write one this morning. > Also, did we get an measurements on tab startup performance, memory > sharing, etc? My measurements on tab startup showed no clear effect. But http://build.chromium.org/buildbot/perf/linux-release/startup/report.html?history=150 shows that the 'startup' measurement increased by about 5ms and got quite a bit more variable. (My measurements were all with the old parentage arrangement, with the zygote as the first child, perhaps that change made a difference.) - Dan --~--~-~--~~~---~--~~ 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: confused with chrome's version control
Hi Jickae, Your summary is all correct, with the addition of Thomas' note: the source tarball is raw source code. This is useful if you want to see the actual C++ source used to program Chromium. So as Thomas said, gclient sync --revision s...@ will get you the source code of a specific revision number, or just gclient sync will get you the latest source code. If you just want to test run specific revisions of Chromium, you can download the executable binaries from these directories: http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/?C=N;O=D http://build.chromium.org/buildbot/continuous/win/?C=N;O=D These are URLs to the Windows builds sorted most recent first. There are other directory names (below "snapshots" and below "continuous") for the Linux and Mac versions. On Jun 9, 6:40 am, Thomas Van Lenten wrote: > From the very end ofhttp://dev.chromium.org/developers/how-tos/get-the-code > gclient sync --revision s...@ > > TVL > > > > On Tue, Jun 9, 2009 at 9:27 AM, Jickae Davis wrote: > > And I also encountered a new question. > > > How to update to certain revision of different > > kinds(snapshot/continuous/tarball). > > > For example, I want chrome r17830 of snapshot/continuous/tarball. --~--~-~--~~~---~--~~ 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: Zygote mode on by default in Linux now. Here's how to disable it...
On Tue, Jun 9, 2009 at 7:33 AM, Dan Kegel wrote: > Yes. I tried leaving the initial process as browser, and making the > zygote its first child, > but it was hard to get all the UI tests passing that way (the process > filtering in > chrome_process_utils.cc in particular didn't work that way). I noticed this too, but we'll have to switch it back. 90% of the reason for having a zygote process is to get different ASLR for the renderers, otherwise we would just fork from the browser process and rewind the heap. I'm doing a refactoring pass at the moment to: * Remove the list of magic fds from base (since that's a Chrome specific thing) * Remove the lock file * Remove the ability for renderers to screw around with message order * Make sure the renderers have a different ASLR from the browser (although all renderers will have the same ASL). I was going to merge the SUID sandbox stuff with this as well, but then face palmed as I realised that it breaks the SUID sandbox anyway. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Zygotes [was Re: [chromium-dev] Re: Avoiding crash after autoupdate on Linux]
On Tue, Jun 9, 2009 at 4:01 AM, Dean McNamee wrote: > - The renderers always have the same layout, meaning if you could find > some bug that allowed you to spawn a new tab/process, attack it, and > let it crash, you could brute force addresses until you hit it. > Although, I suppose the probability is similar either way Right. Either you're changing your aim to hit a stationary target, or you just fire the same way again and again and wait for a moving target to hit you. > - The browser and renderers share the same layout. If you can find a > pointer leak / bug in the renderer, you then know the address layout > to try and attack the browser process. This is a much bigger deal. It needs to be fixed. I'm working on it now. It was a one-line change in a review and I didn't notice the implications. My bad. 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: What is the best way to get document location from an NPAPI plugin?
I'm hesitant to say because I don't want Vijay to treat this as advice on the "right" way to determine which page included his plug-in. The approach of trying to read the document's location via JavaScript is fundamentally insecure. That being said, my understanding is that Flash examines the location property of the window object and not the document object. Note that simply making this change to the below is *not* sufficient for security. Adam On Tue, Jun 9, 2009 at 1:30 AM, John Abd-El-Malek wrote: > My question to you is what you see Flash doing. I pasted below what I > observed by looking at their NPN calls. > > On Tue, Jun 9, 2009 at 5:23 PM, Adam Barth wrote: >> >> Here's a demo of an attack that works in Chrome: >> >> http://webblaze.org/abarth/tests/document-location/ >> >> Flash does something similar, but not *precisely* what Vijay proposed. >> This approach is extremely fragile. If you require this value to >> make a security decision, I recommend a different approach (as I have >> now stated multiple times). >> >> Adam >> >> >> On Tue, Jun 9, 2009 at 1:16 AM, John Abd-El-Malek wrote: >> > I was referring to what I sniffed in IPC traffic: >> > NPN_GetProperty is called on "location" >> > and the returned object is NPN_Invoke'd to call "toString" >> > Isn't this what you mean? If you observed something else, we should >> > figure >> > out what the discrepancy is! >> > On Tue, Jun 9, 2009 at 3:36 PM, Adam Barth wrote: >> >> >> >> Flash does something similar, but not *precisely* the same. I stand >> >> by my statement that the below is insecure. >> >> >> >> Adam >> >> >> >> >> >> On Mon, Jun 8, 2009 at 8:08 PM, John Abd-El-Malek >> >> wrote: >> >> > BTW this is how Flash does it. >> >> > >> >> > On Mon, Jun 8, 2009 at 7:47 PM, Adam Barth >> >> > wrote: >> >> >> >> >> >> On Mon, Jun 8, 2009 at 1:29 PM, vijay wrote: >> >> >> > We used to use NPN_GetURL with "javascript:document.location" as >> >> >> > the >> >> >> > URL. In the current implementation, after this script is executed >> >> >> > in >> >> >> > WebPluginImpl::ExecuteScript (in >> >> >> > src/webkit/glue/webplugin_impl.cc), >> >> >> > its checking the result value: >> >> >> >> >> >> This is not a secure way to determine which page embedded the >> >> >> plug-in. >> >> >> If you require this value to make a security decision, you should >> >> >> use >> >> >> a different approach. >> >> >> >> >> >> 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: What is the best way to get document location from an NPAPI plugin?
On Wed, Jun 10, 2009 at 12:30 AM, Adam Barth wrote: > I'm hesitant to say because I don't want Vijay to treat this as advice > on the "right" way to determine which page included his plug-in. The > approach of trying to read the document's location via JavaScript is > fundamentally insecure. I think if we tell someone not to do something because it's insecure, we need to at least tell them about the most secure way we know about, even if it's not perfect. IMO unless Vijay's plugin's is on a large number of machines, it won't be a an attractive target for attackers. > > > That being said, my understanding is that Flash examines the location > property of the window object and not the document object. Note that > simply making this change to the below is *not* sufficient for > security. Ok, this matches what I observed and wrote below.. > > > Adam > > > On Tue, Jun 9, 2009 at 1:30 AM, John Abd-El-Malek wrote: > > My question to you is what you see Flash doing. I pasted below what I > > observed by looking at their NPN calls. > > > > On Tue, Jun 9, 2009 at 5:23 PM, Adam Barth wrote: > >> > >> Here's a demo of an attack that works in Chrome: > >> > >> http://webblaze.org/abarth/tests/document-location/ > >> > >> Flash does something similar, but not *precisely* what Vijay proposed. > >> This approach is extremely fragile. If you require this value to > >> make a security decision, I recommend a different approach (as I have > >> now stated multiple times). > >> > >> Adam > >> > >> > >> On Tue, Jun 9, 2009 at 1:16 AM, John Abd-El-Malek > wrote: > >> > I was referring to what I sniffed in IPC traffic: > >> > NPN_GetProperty is called on "location" > >> > and the returned object is NPN_Invoke'd to call "toString" > >> > Isn't this what you mean? If you observed something else, we should > >> > figure > >> > out what the discrepancy is! > >> > On Tue, Jun 9, 2009 at 3:36 PM, Adam Barth > wrote: > >> >> > >> >> Flash does something similar, but not *precisely* the same. I stand > >> >> by my statement that the below is insecure. > >> >> > >> >> Adam > >> >> > >> >> > >> >> On Mon, Jun 8, 2009 at 8:08 PM, John Abd-El-Malek > >> >> wrote: > >> >> > BTW this is how Flash does it. > >> >> > > >> >> > On Mon, Jun 8, 2009 at 7:47 PM, Adam Barth > >> >> > wrote: > >> >> >> > >> >> >> On Mon, Jun 8, 2009 at 1:29 PM, vijay wrote: > >> >> >> > We used to use NPN_GetURL with "javascript:document.location" as > >> >> >> > the > >> >> >> > URL. In the current implementation, after this script is > executed > >> >> >> > in > >> >> >> > WebPluginImpl::ExecuteScript (in > >> >> >> > src/webkit/glue/webplugin_impl.cc), > >> >> >> > its checking the result value: > >> >> >> > >> >> >> This is not a secure way to determine which page embedded the > >> >> >> plug-in. > >> >> >> If you require this value to make a security decision, you should > >> >> >> use > >> >> >> a different approach. > >> >> >> > >> >> >> 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: What is the best way to get document location from an NPAPI plugin?
On Tue, Jun 9, 2009 at 9:33 AM, John Abd-El-Malek wrote: > On Wed, Jun 10, 2009 at 12:30 AM, Adam Barth wrote: >> I'm hesitant to say because I don't want Vijay to treat this as advice >> on the "right" way to determine which page included his plug-in. The >> approach of trying to read the document's location via JavaScript is >> fundamentally insecure. > > I think if we tell someone not to do something because it's insecure, we > need to at least tell them about the most secure way we know about, even if > it's not perfect. IMO unless Vijay's plugin's is on a large number of > machines, it won't be a an attractive target for attackers. I do know a secure way to do this, but it's extremely complex. I don't think it would be responsible for me to try to explain it in this thread because I'd probably screw up the explanation. I should document it carefully sometime, but that's not high on my list of priorities. 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] [Extension] Introducing AniWeather: Animated Weather + Any Weather
I would like to announce another Chrome add-on: AniWeather. AniWeather stands for "Animated Weather + Any Weather". Here are some highlights about it: 1. Weather information in vivid animations 2. Real time condition update + 5-day forecast 3. Check the weather of over 77,000 locations worldwide 4. Switch locations in one click 4. Link to more detailed views seamlessly 5. Customizable to fit your preference (temperature unit, location list, etc.) More details and download at http://www.aniweather.com Thanks to the progress in Chrome 3.0, which makes saving user preferences possible. Shall I call it Chrome's first full-functioning add-on (including user preferences)? :P Several issues (some are known/acknowledged): 1. As usual, the add-on might not work for the first page 2. Click the toolstrip will bring the first tab foreground. 3. When the tooltip for a toolstrip shows up, Chrome would crash while exiting. 4. Sending large amount of data (say 10k) via the extension/script channel might block UI for quite a while (I haven't checked it for the latest version and will do). Note I think 2 and 3 are critical because they make it impossible to interact w/ the toolstrip. I hope you enjoy it and any of your comments are welcome. Best regards, Jack --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Zygotes [was Re: [chromium-dev] Re: Avoiding crash after autoupdate on Linux]
On Tue, Jun 9, 2009 at 10:09 AM, Dan Kegel wrote: > Seems like if we defer starting the zygote until after the > first renderer has opened its .pak files, things get much > simpler -- the renderers won't need to talk to the zygote > server at all. In the case of sandboxing, I suspect we'll need to route font requests into the zygote process (because fontconfig is single threaded, so we can't handle them in the browser process). So it'll need to handle renderer requests anyway. (from chat:) me: pong just seen your email. Don't worry about it. I'm in the middle of pulling the Chrome specific code out of base, so I'll take care of it at the same time. 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: Zygote mode on by default in Linux now. Here's how to disable it...
On Tue, Jun 9, 2009 at 7:33 AM, Dan Kegel wrote: > My measurements on tab startup showed no clear effect. But > http://build.chromium.org/buildbot/perf/linux-release/startup/report.html?history=150 > shows that the 'startup' measurement increased by about 5ms and > got quite a bit more variable. (My measurements were all with the > old parentage arrangement, with the zygote as the first child, perhaps that > change made a difference.) The orange line (reference build that is not affected by this change) also got slower and started bouncing around. I'm not convinced we have enough data to tell how this change impacted startup. The browser RSS seems to have gone down? http://build.chromium.org/buildbot/perf/linux-release/moz/report.html?history=150&graph=vm_rss_final_b And the bytes of IO in the renderer seem to have gone down as well: http://build.chromium.org/buildbot/perf/linux-release/moz/report.html?history=150&graph=total_byte_r --~--~-~--~~~---~--~~ 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: Google History extension
Can someone who works for Google perhaps put me in touch with someone from the Google Web History or Google Toolbar team? I can't find any information anywhere... On May 26, 3:20 pm, John Munro wrote: > By sniffing Firefox I think what happens is that the toolbar does a > HTTP GET to > > http://toolbarqueries.google.com/search?features=Rank:WH&sourceid=nav... > > where the URL at the end (in this case filevision.net) is the URL to > add to History. > > Unfortunately when I try just navigating to a URL like this I get a > 403 Forbidden error. > > Maybe it's something to do with the googleip, iqrn and ch parameters, > since I have no idea what they do. > > On May 26, 2:02 pm, Nick Baum wrote: > > > > > I'd love to see an extension that does this! > > > It might be relatively straight-forward to sniff network requests to > > google.com while browsing with the toolbar enabled. > > > -Nick > > > On Mon, May 25, 2009 at 4:26 PM, John Munro wrote: > > > > Ugh, it's minified - not sure I have the enthusiasm for that. Oh > > > well :( > > > > On May 25, 6:32 pm, Evan Martin wrote: > > > > From a quick search it doesn't look like there's an API available. > > > > One thought is to examine the Google Toolbar for Firefox, as that can > > > > submit to web history and is written primarily in JavaScript. > > > > > On Fri, May 22, 2009 at 6:07 PM, John Munro wrote: > > > > > > One of the things I miss when using Chrome is how Google Toolbar adds > > > > > every page you visit to Google History. > > > > > > I would like to build a Chrome extension that just implements that one > > > > > feature of Google Toolbar - adds every page you visit to Google > > > > > History. > > > > > > I imagine this would be quite simple if it was just a matter of > > > > > sending the current URL as a parameter to a Google History URL or > > > > > something similar. > > > > > > Does anyone know how to submit a visited URL to Google History? > > > > > > Apologies if this is the wrong group to post this to. --~--~-~--~~~---~--~~ 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: [Extension] Introducing AniWeather: Animated Weather + Any Weather
Hi Jack, Is the detail on hover of the toolstrip meant to work in Chrome? I see that you have a content script that looks like it wants to implement this, but it doesn't seem to do anything for me. Are you storing the preferences on the server? That is what it appears like to me. Nice work though. I added my work and home cities. - a On Tue, Jun 9, 2009 at 9:59 AM, jack wrote: > > I would like to announce another Chrome add-on: AniWeather. AniWeather > stands for "Animated Weather + Any Weather". Here are some highlights > about it: > > 1. Weather information in vivid animations > 2. Real time condition update + 5-day forecast > 3. Check the weather of over 77,000 locations worldwide > 4. Switch locations in one click > 4. Link to more detailed views seamlessly > 5. Customizable to fit your preference (temperature unit, location > list, etc.) > > More details and download at http://www.aniweather.com > > Thanks to the progress in Chrome 3.0, which makes saving user > preferences possible. Shall I call it Chrome's first full-functioning > add-on (including user preferences)? :P > > Several issues (some are known/acknowledged): > > 1. As usual, the add-on might not work for the first page > 2. Click the toolstrip will bring the first tab foreground. > 3. When the tooltip for a toolstrip shows up, Chrome would crash while > exiting. > 4. Sending large amount of data (say 10k) via the extension/script > channel might block UI for quite a while (I haven't checked it for the > latest version and will do). > > Note I think 2 and 3 are critical because they make it impossible to > interact w/ the toolstrip. > > I hope you enjoy it and any of your comments are welcome. > > Best regards, > Jack > > > > > --~--~-~--~~~---~--~~ 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 renderer process is created/destoryed
Hi, Form chromium documentation, when creating/destroying tabs, a renderer process is getting created/destroyed. Can you please tell me the code for renderer process is created/destoryed? Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Extension] Introducing AniWeather: Animated Weather + Any Weather
Hi Aaron, Thanks for your comments and please see my reply inline. On Jun 9, 11:00 am, Aaron Boodman wrote: > Hi Jack, > > Is the detail on hover of the toolstrip meant to work in Chrome? I see > that you have a content script that looks like it wants to implement > this, but it doesn't seem to do anything for me. [Jack] It should be working in Chrome. Note when you hover over the toolstrip AniWeather provides a detailed view of current condition near the toolstrip. To avoid annoyance you have to stay your cursor on the toolstrip for a while to trigger the detailed view. If you want to view the 5-day forecast, click the detailed view. Also the first page after you launch Chrome doesn't work. So you have to navigate to a second page to have the hovering working. This is a known issue as discussed before. In fact, the most straightforward way to trigger further action is to click the toolstrip directly. But because of the bug (switching to the first tab), this is a workaround for now. > Are you storing the preferences on the server? That is what it appears > like to me. [Jack] User preferences are stored locally via the bookmarking system, which has been stable enough in Chrome 3 to be used. > Nice work though. I added my work and home cities. [Jack] Thanks. As this is the very preliminary release, any comments or suggestions are welcome. > - a > > On Tue, Jun 9, 2009 at 9:59 AM, jack wrote: > > > I would like to announce another Chrome add-on: AniWeather. AniWeather > > stands for "Animated Weather + Any Weather". Here are some highlights > > about it: > > > 1. Weather information in vivid animations > > 2. Real time condition update + 5-day forecast > > 3. Check the weather of over 77,000 locations worldwide > > 4. Switch locations in one click > > 4. Link to more detailed views seamlessly > > 5. Customizable to fit your preference (temperature unit, location > > list, etc.) > > > More details and download athttp://www.aniweather.com > > > Thanks to the progress in Chrome 3.0, which makes saving user > > preferences possible. Shall I call it Chrome's first full-functioning > > add-on (including user preferences)? :P > > > Several issues (some are known/acknowledged): > > > 1. As usual, the add-on might not work for the first page > > 2. Click the toolstrip will bring the first tab foreground. > > 3. When the tooltip for a toolstrip shows up, Chrome would crash while > > exiting. > > 4. Sending large amount of data (say 10k) via the extension/script > > channel might block UI for quite a while (I haven't checked it for the > > latest version and will do). > > > Note I think 2 and 3 are critical because they make it impossible to > > interact w/ the toolstrip. > > > I hope you enjoy it and any of your comments are welcome. > > > Best regards, > > Jack > > --~--~-~--~~~---~--~~ 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 renderer process is created/destoryed
On Tue, Jun 9, 2009 at 12:12 PM, Meryl Silverburgh wrote: > Form chromium documentation, when creating/destroying tabs, a renderer > process is getting created/destroyed. > Can you please tell me the code for renderer process is created/destoryed? chrome/browser/renderer_host/browser_render_process_host.cc is the best place to start. See BrowserRenderProcessHost::Init 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: [Extension] Introducing AniWeather: Animated Weather + Any Weather
On Tue, Jun 9, 2009 at 12:14 PM, jack wrote: > [Jack] It should be working in Chrome. Note when you hover over the > toolstrip AniWeather provides a detailed view of current condition > near the toolstrip. To avoid annoyance you have to stay your cursor on > the toolstrip for a while to trigger the detailed view. If you want to > view the 5-day forecast, click the detailed view. I see. I think the confusion was that you have to put your mouse over the icon, not the text. I didn't realize this at first. You might consider expanding the hover area to the entire toolstrip. > Also the first page after you launch Chrome doesn't work. So you have > to navigate to a second page to have the hovering working. This is a > known issue as discussed before. > > In fact, the most straightforward way to trigger further action is to > click the toolstrip directly. But because of the bug (switching to the > first tab), this is a workaround for now. FWIW, the issue with focusing the first tab is fixed in the next dev channel release which should come sometime this week. >> Are you storing the preferences on the server? That is what it appears >> like to me. > > [Jack] User preferences are stored locally via the bookmarking system, > which has been stable enough in Chrome 3 to be used. I see :). So why have the preferences page served remotely at http://www.aniweather.com/aniweather.config.html? You can also package this page directly in the extension so that it (and the toolstrip) can directly access the storage (err bookmarks, I mean) API. > [Jack] Thanks. As this is the very preliminary release, any comments > or suggestions are welcome. I think personally, I would like to be able to see all of my cities weather when I hover over the toolstrip -- either as a content script overlay or by sliding the toolstrip open to reveal more icons/temperatures. But this is a great start. Thanks for sharing it. - 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] Difference between TestShell and Chromium
Hi I understand TestShell is a test harness for running layout tests and a Chromium is a multi-process web browser. And I understand Chromium's browser thread does the I/O for each renderer pr ocess (using Webkit +V8). My question is much code in TestShell are 'common' with Chromium. I think these are common: * Webkit rendering engine * V8 JS engine * image decoding code * graphics library (i.e. Skia) what about ? * Http stack? * cookie support * cache support --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Difference between TestShell and Chromium
On Tue, Jun 9, 2009 at 12:34 PM, Daniel Dreiberg < daniel.dreiber...@gmail.com> wrote: > Hi > I understand TestShell is > > a test harness for running layout tests and a Chromium is a multi-process > web browser. > > And I understand Chromium's browser thread does the I/O for each renderer > process (using Webkit +V8). > > My question is much code in TestShell are 'common' with Chromium. > > I think these are common: > > * Webkit rendering engine > > * V8 JS engine > * image decoding code > * graphics library (i.e. Skia) > > what about ? > * Http stack? > * cookie support > * cache support > Yes, these are 'common' as well. Another way to say it is that chromium's 'net' library is used in both the TestShell and Chromium. The primary interface to the net library, used by both TestShell and Chromium, is the URLRequest class. > > > > --~--~-~--~~~---~--~~ 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 is the best way to get document location from an NPAPI plugin?
Our plugin is no Flash but it still has (and continues to have) a decent install base so I'd definitely be interested in keeping things as secure as possible. For now I'm sticking to the npruntime approach suggested by Antoine near the beginning of this thread and it works fine on both Chrome and Firefox. I'm hesitant to go back to the NPN_GetURL with javascript since a future update for Chrome might decide to break it :) As demonstrated by the link above, I realize that it is still not secure. So if there are better ideas, please let me know. Adam, I'd appreciate even a high-level proposal from you; it doesn't have to be detailed. As long as it can work cross-browser I can dig into the details. It may be complex but it can't be that complex :) Thanks for all your time on this! On Jun 9, 9:50 am, Adam Barth wrote: > On Tue, Jun 9, 2009 at 9:33 AM, John Abd-El-Malek wrote: > > On Wed, Jun 10, 2009 at 12:30 AM, Adam Barth wrote: > >> I'm hesitant to say because I don't want Vijay to treat this as advice > >> on the "right" way to determine which page included his plug-in. The > >> approach of trying to read the document's location via JavaScript is > >> fundamentally insecure. > > > I think if we tell someone not to do something because it's insecure, we > > need to at least tell them about the most secure way we know about, even if > > it's not perfect. IMO unless Vijay's plugin's is on a large number of > > machines, it won't be a an attractive target for attackers. > > I do know a secure way to do this, but it's extremely complex. I > don't think it would be responsible for me to try to explain it in > this thread because I'd probably screw up the explanation. I should > document it carefully sometime, but that's not high on my list of > priorities. > > 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: Introducing AniWeather: Animated Weather + Any Weather
On Jun 9, 12:26 pm, Aaron Boodman wrote: > On Tue, Jun 9, 2009 at 12:14 PM, jack wrote: > > [Jack] It should be working in Chrome. Note when you hover over the > > toolstrip AniWeather provides a detailed view of current condition > > near the toolstrip. To avoid annoyance you have to stay your cursor on > > the toolstrip for a while to trigger the detailed view. If you want to > > view the 5-day forecast, click the detailed view. > > I see. I think the confusion was that you have to put your mouse over > the icon, not the text. I didn't realize this at first. You might > consider expanding the hover area to the entire toolstrip. [Jack] Good suggestion and I will add that. > > Also the first page after you launch Chrome doesn't work. So you have > > to navigate to a second page to have the hovering working. This is a > > known issue as discussed before. > > > In fact, the most straightforward way to trigger further action is to > > click the toolstrip directly. But because of the bug (switching to the > > first tab), this is a workaround for now. > > FWIW, the issue with focusing the first tab is fixed in the next dev > channel release which should come sometime this week. [Jack] Sounds great! > >> Are you storing the preferences on the server? That is what it appears > >> like to me. > > > [Jack] User preferences are stored locally via the bookmarking system, > > which has been stable enough in Chrome 3 to be used. > > I see :). So why have the preferences page served remotely > athttp://www.aniweather.com/aniweather.config.html?You can also package > this page directly in the extension so that it (and the toolstrip) can > directly access the storage (err bookmarks, I mean) API. [Jack] I understand that I can put it directly in the extension. This is for the consideration of both timely update and being compatible w/ other browsers instead of writing individual configurations for each of them. > > [Jack] Thanks. As this is the very preliminary release, any comments > > or suggestions are welcome. > > I think personally, I would like to be able to see all of my cities > weather when I hover over the toolstrip -- either as a content script > overlay or by sliding the toolstrip open to reveal more > icons/temperatures. [Jack] Again thanks for all comments and I will consider that in later releases. > But this is a great start. Thanks for sharing it. > > - 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] [extensions] bug gardening
I've gone through and re-ordered all the bugs using a categorization some of us discussed in person yesterday. Here is a convenient query for bookmarking: http://code.google.com/p/chromium/issues/list?can=2&q=area:extensions&sort=mstone+pri&colspec=ID%20Mstone%20Pri%20Summary%20Status%20Owner This is sorted ascending by mstone, then priority. mstone-3 is themes. Within that, I've marked things P1 that must be done in order to go to stable, and things P2 I could imagine going to stable without fixing. mstone-4 is extensions (hopefully). Within that, P1 is a sort of intermediate milestone where I think people could really start developing extensions. P2 is everything we need to do to "launch" to stable. mstone-X is other stuff, mostly features, that we'd like to do but aren't going to block mstone-4 for. People who are working on extensions, please take a look through and make sure you agree. Thanks, - 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] Adding Mac OS X Spellchecker to Chromium
I've been looking implementing support for the OS X spellchecker on the Mac build as part of my SoC project and I thought I'd run some thoughts I had today by the list. For the basic design, both hunspell and the os x spellchecker need to be useable, since hunspell supports * my idea for the overall design * other stuff to be included (mainly the spelling panel) -Paul Wicks --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Adding Mac OS X Spellchecker to Chromium
Crap, sorry to post an incomplete version of this post earlier. Accidentally hit send before I finished it. Argh... Anyway, I've been looking at implementing support for the OS X spellchecker on the Mac build as part of my SoC project and I thought I'd run some thoughts I had today by the list. For the basic design, both hunspell and the os x spellchecker need to be usable, since hunspell supports more languages than OS X does. The public interface of the Spellchecker class is fairly small (mainly 2 methods: SpellCheckWord, AddWord). It seems that mapping these onto the OS X spellchecker shouldn't be too hard. I originally thought to do something more elaborate and create seperate spellchecker classes for each platform, but then realized that I could do it more simply as follows: -leave the majority of spellchecker.cc as is. It works and I don't see any reason to mess with what works. -for SpellCheckWord, change the call to hunspell_->spell(...) to call a (new) private method in the SpellChecker class. In this method, add some code at the beginning that will check if we are on the mac and if the built-in spellchecker supports the current language and if so checks the word using it, other wise using hunspell as before. This way, we can leave the rest of the code alone and still use the SpellCheckWordIterator to grab individual words out of the string. As for getting the suggestions for a word, it might make sense to do things a little differently, since there is no need to create and manage the char** suggestions variable to pass to hunspell, as NSSpellChecker can give us an easy-to-iterate-through NSArray. Probably just an #if defined(OS_MACOSX) would suffice here, since the code here will be wholly different. -for AddWord, their probably isn't as much of a need to abstract the hunspell specific code (it's all hunspell code), so just an #if defined( OS_MACOSX)+language support check would suffice. -The other public methods all deal with language selection and querying, which should remain the same, since the OS X spellchecker only supports a subset of the languages supported by hunspell. (there may need to be a little bit of code to translate between the codes for supported languages so that the built-in spellchecker always gets used when it should, but this should be a relatively simple matter. -The private method IsValidContraction could call the same new private method as defined above. -This way, the public interface stays the same and the mac folks get to use their own dictionary. -The newly added autocorrection code should work just the same as before, as it relies on SpellCheckWord. -also, [NSApplication sharedApplication] needs to be called before the the built in spellchecker is used. I'm not sure of where the best place to put this call is. The upside to doing it this way is that it should be relatively easy to modify the spellchecking code for any one platform without breaking any other. The main downside that I can see for doing it this way is that for languages that are supported by OS X, we will be keeping a hunspell object around that we don't need, at least until the language changes to something hunspell supports and os x doesn't There are a few additional features that the OS X spellchecker supports that need some discussion. 1. Grammar checker: I know I've seen some talk about adding this to chromium somewhere. The OS X spellchecker also has support for checking the grammar of a string (only in 10.5+), so that is something to keep in mind when that stage is reached. 2. Spelling Panel: The OS X spellchecker has support for a "Spelling Panel". Similar to spellchecking in most word processors, this provides a seperate GUI Panel that allows for checking a whole paragraph in one go. The main problems here are that this is functionality that is in no way matched by the Windows or Linux Builds. Additionally, it would require some way of identifying the source of each word, since the spelling panel allows for the creation of a list of ignored words, which are unique to a document. In the case of chromium, a document would correspond to a given textfield, most likely. The NSSpellChecker API provides a function (uniqueSpellDocumentTag) to generate tags for this purpose, but a way would have to be found to generate and match these tags up, which could be complicated (although I admit that I've not spent a lot of time looking at the code that would need to be altered to make this aspect of the spelling panel function). Any thoughts would be great. Thanks, -Paul Wicks --~--~-~--~~~---~--~~ 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: Adding Mac OS X Spellchecker to Chromium
IMHO there is no need to maintain dual hunspell/OSX spellchecker backends. There are addon OSX spellcheckers for other languages e.g. http://www.mitzpettel.com/software/hspell.php . Writing additional spelling servers is pretty simple so I think the correct approach would be: 1. Getting OSX spelling/grammar checking support working well. 2. If the need arises, wrapping hunspell as an Apple Spelling service and provide it as a separate project users can install. Best regards, Jeremy On Tue, Jun 9, 2009 at 5:32 PM, Paul Wicks wrote: > Crap, sorry to post an incomplete version of this post earlier. > Accidentally hit send before I finished it. Argh... > > Anyway, > > I've been looking at implementing support for the OS X spellchecker on the > Mac build as part of my SoC project and I thought I'd run some thoughts I > had today by the list. > > For the basic design, both hunspell and the os x spellchecker need to be > usable, since hunspell supports more languages than OS X does. The public > interface of the Spellchecker class is fairly small (mainly 2 methods: > SpellCheckWord, AddWord). It seems that mapping these onto the OS X > spellchecker shouldn't be too hard. I originally thought to do something > more elaborate and create seperate spellchecker classes for each platform, > but then realized that I could do it more simply as follows: > > -leave the majority of spellchecker.cc as is. It works and I don't see any > reason to mess with what works. > -for SpellCheckWord, change the call to hunspell_->spell(...) to call a > (new) private method in the SpellChecker class. In this method, add some > code at the beginning that will check if we are on the mac and if the > built-in spellchecker supports the current language and if so checks the > word using it, other wise using hunspell as before. This way, we can leave > the rest of the code alone and still use the SpellCheckWordIterator to grab > individual words out of the string. As for getting the suggestions for a > word, it might make sense to do things a little differently, since there is > no need to create and manage the char** suggestions variable to pass to > hunspell, as NSSpellChecker can give us an easy-to-iterate-through NSArray. > Probably just an #if defined(OS_MACOSX) would suffice here, since the code > here will be wholly different. > -for AddWord, their probably isn't as much of a need to abstract the > hunspell specific code (it's all hunspell code), so just an #if defined( > OS_MACOSX)+language support check would suffice. > -The other public methods all deal with language selection and querying, > which should remain the same, since the OS X spellchecker only supports a > subset of the languages supported by hunspell. (there may need to be a > little bit of code to translate between the codes for supported languages so > that the built-in spellchecker always gets used when it should, but this > should be a relatively simple matter. > -The private method IsValidContraction could call the same new private > method as defined above. > > -This way, the public interface stays the same and the mac folks get to use > their own dictionary. > -The newly added autocorrection code should work just the same as before, > as it relies on SpellCheckWord. > -also, [NSApplication sharedApplication] needs to be called before the the > built in spellchecker is used. I'm not sure of where the best place to put > this call is. > > The upside to doing it this way is that it should be relatively easy to > modify the spellchecking code for any one platform without breaking any > other. > The main downside that I can see for doing it this way is that for > languages that are supported by OS X, we will be keeping a hunspell object > around that we don't need, at least until the language changes to something > hunspell supports and os x doesn't > > There are a few additional features that the OS X spellchecker supports > that need some discussion. > 1. Grammar checker: I know I've seen some talk about adding this to > chromium somewhere. The OS X spellchecker also has support for checking the > grammar of a string (only in 10.5+), so that is something to keep in mind > when that stage is reached. > 2. Spelling Panel: The OS X spellchecker has support for a "Spelling > Panel". Similar to spellchecking in most word processors, this provides a > seperate GUI Panel that allows for checking a whole paragraph in one go. The > main problems here are that this is functionality that is in no way matched > by the Windows or Linux Builds. Additionally, it would require some way of > identifying the source of each word, since the spelling panel allows for the > creation of a list of ignored words, which are unique to a document. In the > case of chromium, a document would correspond to a given textfield, most > likely. The NSSpellChecker API provides a function (uniqueSpellDocumentTag) > to generate tags for this purpose, but a way would have to be found to > generate
[chromium-dev] Re: Google History extension
Hi John, Web History doesn't have an official API, but I've emailed the teams. I'll let you know if they can share any more info. -Nick On Tue, Jun 9, 2009 at 10:41 AM, John Munro wrote: > > Can someone who works for Google perhaps put me in touch with someone > from the Google Web History or Google Toolbar team? I can't find any > information anywhere... > > On May 26, 3:20 pm, John Munro wrote: > > By sniffing Firefox I think what happens is that the toolbar does a > > HTTP GET to > > > > http://toolbarqueries.google.com/search?features=Rank:WH&sourceid=nav... > > > > where the URL at the end (in this case filevision.net) is the URL to > > add to History. > > > > Unfortunately when I try just navigating to a URL like this I get a > > 403 Forbidden error. > > > > Maybe it's something to do with the googleip, iqrn and ch parameters, > > since I have no idea what they do. > > > > On May 26, 2:02 pm, Nick Baum wrote: > > > > > > > > > I'd love to see an extension that does this! > > > > > It might be relatively straight-forward to sniff network requests to > > > google.com while browsing with the toolbar enabled. > > > > > -Nick > > > > > On Mon, May 25, 2009 at 4:26 PM, John Munro > wrote: > > > > > > Ugh, it's minified - not sure I have the enthusiasm for that. Oh > > > > well :( > > > > > > On May 25, 6:32 pm, Evan Martin wrote: > > > > > From a quick search it doesn't look like there's an API available. > > > > > One thought is to examine the Google Toolbar for Firefox, as that > can > > > > > submit to web history and is written primarily in JavaScript. > > > > > > > On Fri, May 22, 2009 at 6:07 PM, John Munro > wrote: > > > > > > > > One of the things I miss when using Chrome is how Google Toolbar > adds > > > > > > every page you visit to Google History. > > > > > > > > I would like to build a Chrome extension that just implements > that one > > > > > > feature of Google Toolbar - adds every page you visit to Google > > > > > > History. > > > > > > > > I imagine this would be quite simple if it was just a matter of > > > > > > sending the current URL as a parameter to a Google History URL or > > > > > > something similar. > > > > > > > > Does anyone know how to submit a visited URL to Google History? > > > > > > > > Apologies if this is the wrong group to post this to. > > > --~--~-~--~~~---~--~~ 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: Adding Mac OS X Spellchecker to Chromium
A couple more things: * I think ultimately we should support the grammar checker, but at first just getting spellchecking to work would be great! * +1 for supporting the Cocoa gui for spellchecking paragraphs, see the 2nd paragraph bellow for more thoughts on this. Matching Linux & Windows functionality is a non-goal IMHO, to reiterate we want to behave like a native Cocoa application. WebKit/Safari already support these features so the issue is to get the plumbing working right in our multiprocess model (which may be non-trivial). IMHO the correct route here is to look at how this is done in WebKit and match the behavior there as much as possible, that's what I'm doing with the keyboard events at the moment and it's proving pretty fruitful. It's really exciting you're working on this!! Best regards, Jeremy On Tue, Jun 9, 2009 at 5:50 PM, Jeremy Moskovich wrote: > IMHO there is no need to maintain dual hunspell/OSX spellchecker backends. > There are addon OSX spellcheckers for other languages e.g. > http://www.mitzpettel.com/software/hspell.php > . Writing additional spelling servers is pretty simple so I think the > correct approach would be: > > 1. Getting OSX spelling/grammar checking support working well. > > 2. If the need arises, wrapping hunspell as an Apple Spelling service and > provide it as a separate project users can install. > > Best regards, > Jeremy > > On Tue, Jun 9, 2009 at 5:32 PM, Paul Wicks wrote: > >> Crap, sorry to post an incomplete version of this post earlier. >> Accidentally hit send before I finished it. Argh... >> >> Anyway, >> >> I've been looking at implementing support for the OS X spellchecker on the >> Mac build as part of my SoC project and I thought I'd run some thoughts I >> had today by the list. >> >> For the basic design, both hunspell and the os x spellchecker need to be >> usable, since hunspell supports more languages than OS X does. The public >> interface of the Spellchecker class is fairly small (mainly 2 methods: >> SpellCheckWord, AddWord). It seems that mapping these onto the OS X >> spellchecker shouldn't be too hard. I originally thought to do something >> more elaborate and create seperate spellchecker classes for each platform, >> but then realized that I could do it more simply as follows: >> >> -leave the majority of spellchecker.cc as is. It works and I don't see any >> reason to mess with what works. >> -for SpellCheckWord, change the call to hunspell_->spell(...) to call a >> (new) private method in the SpellChecker class. In this method, add some >> code at the beginning that will check if we are on the mac and if the >> built-in spellchecker supports the current language and if so checks the >> word using it, other wise using hunspell as before. This way, we can leave >> the rest of the code alone and still use the SpellCheckWordIterator to grab >> individual words out of the string. As for getting the suggestions for a >> word, it might make sense to do things a little differently, since there is >> no need to create and manage the char** suggestions variable to pass to >> hunspell, as NSSpellChecker can give us an easy-to-iterate-through NSArray. >> Probably just an #if defined(OS_MACOSX) would suffice here, since the >> code here will be wholly different. >> -for AddWord, their probably isn't as much of a need to abstract the >> hunspell specific code (it's all hunspell code), so just an #if defined( >> OS_MACOSX)+language support check would suffice. >> -The other public methods all deal with language selection and querying, >> which should remain the same, since the OS X spellchecker only supports a >> subset of the languages supported by hunspell. (there may need to be a >> little bit of code to translate between the codes for supported languages so >> that the built-in spellchecker always gets used when it should, but this >> should be a relatively simple matter. >> -The private method IsValidContraction could call the same new private >> method as defined above. >> >> -This way, the public interface stays the same and the mac folks get to >> use their own dictionary. >> -The newly added autocorrection code should work just the same as before, >> as it relies on SpellCheckWord. >> -also, [NSApplication sharedApplication] needs to be called before the the >> built in spellchecker is used. I'm not sure of where the best place to put >> this call is. >> >> The upside to doing it this way is that it should be relatively easy to >> modify the spellchecking code for any one platform without breaking any >> other. >> The main downside that I can see for doing it this way is that for >> languages that are supported by OS X, we will be keeping a hunspell object >> around that we don't need, at least until the language changes to something >> hunspell supports and os x doesn't >> >> There are a few additional features that the OS X spellchecker supports >> that need some discussion. >> 1. Grammar checker: I know I've seen some talk about
[chromium-dev] Re: Introducing AniWeather: Animated Weather + Any Weather
This is very cool, Jack. I l really like the polish of the UI, and in the future I hope we can enable these kinds of interactions without needing to use content scripts. I wonder if we should retroactively inject content-scripts into existing tabs that match? It seems this would be useful for all sorts of extensions. -Nick On Tue, Jun 9, 2009 at 2:23 PM, jack wrote: > > > > On Jun 9, 12:26 pm, Aaron Boodman wrote: > > On Tue, Jun 9, 2009 at 12:14 PM, jack wrote: > > > [Jack] It should be working in Chrome. Note when you hover over the > > > toolstrip AniWeather provides a detailed view of current condition > > > near the toolstrip. To avoid annoyance you have to stay your cursor on > > > the toolstrip for a while to trigger the detailed view. If you want to > > > view the 5-day forecast, click the detailed view. > > > > I see. I think the confusion was that you have to put your mouse over > > the icon, not the text. I didn't realize this at first. You might > > consider expanding the hover area to the entire toolstrip. > > [Jack] Good suggestion and I will add that. > > > > Also the first page after you launch Chrome doesn't work. So you have > > > to navigate to a second page to have the hovering working. This is a > > > known issue as discussed before. > > > > > In fact, the most straightforward way to trigger further action is to > > > click the toolstrip directly. But because of the bug (switching to the > > > first tab), this is a workaround for now. > > > > FWIW, the issue with focusing the first tab is fixed in the next dev > > channel release which should come sometime this week. > > [Jack] Sounds great! > > > >> Are you storing the preferences on the server? That is what it appears > > >> like to me. > > > > > [Jack] User preferences are stored locally via the bookmarking system, > > > which has been stable enough in Chrome 3 to be used. > > > > I see :). So why have the preferences page served remotely athttp:// > www.aniweather.com/aniweather.config.html?You can also package > > this page directly in the extension so that it (and the toolstrip) can > > directly access the storage (err bookmarks, I mean) API. > > [Jack] I understand that I can put it directly in the extension. This > is for the consideration of both timely update and being compatible w/ > other browsers instead of writing individual configurations for each > of them. > > > > [Jack] Thanks. As this is the very preliminary release, any comments > > > or suggestions are welcome. > > > > I think personally, I would like to be able to see all of my cities > > weather when I hover over the toolstrip -- either as a content script > > overlay or by sliding the toolstrip open to reveal more > > icons/temperatures. > > [Jack] Again thanks for all comments and I will consider that in later > releases. > > > But this is a great start. Thanks for sharing it. > > > > - 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: Introducing AniWeather: Animated Weather + Any Weather
On Tue, Jun 9, 2009 at 6:23 PM, Nick Baum wrote: > This is very cool, Jack. I l really like the polish of the UI, and in the > future I hope we can enable these kinds of interactions without needing to > use content scripts. > I wonder if we should retroactively inject content-scripts into existing > tabs that match? > It seems this would be useful for all sorts of extensions. I don't want to retroactively inject because it breaks the promise that scripts are injected before onload, which makes a special case that programmers have to worry about. I think a better solution would be programmatic injection of content scripts (http://code.google.com/p/chromium/issues/detail?id=12465). - 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: Print Settings Mockup
On Fri, Jun 5, 2009 at 9:03 PM, Mohamed Mansour wrote: > I really like the mock-up, when can you do one for Settings? I'll put it on our list, but I don't expect to get to this in the next couple of weeks. In general, we try not to block engineers on UI, so if you make good progress on the preview, we'll prioritize this higher. > > If we are going to include settings to this page (such as margins, headers, > footers, etc), does that mean it would be per page? I was thinking of global > printer settings which will be persistent. I don't know how that will fit > this mock-up, or we could have both. We could have a dialog which sole > purpose is for printer settings and the inline page for per page > settings/preview customization. The inline page can have a link to the > global settings if needed. > I think the settings should just be global and sticky (just like default printer on the mac: it just uses the last one you used). Most people probably don't want to change print settings when they're not printing. > > That will seem to be too crowded, and my vision would be incorporating all > this (preview and settings) into the same page. I am just wondering how the > UI's team vision is, wrt to settings. Would be nice to see. > > We already started with Headers/Footers data persistence in a previous CL. > And would like to have a UI that will let the user interact with such data > instead of editing the Preference file directly. Later on we could start the > print preview implementation, which I "think" is challenging. > I think Ben's opinion was that the preferences would be hard to understand without the preview, so we should do the preview first. I can't comment on the difficulty of it :) > > > -- Mohamed Mansour > > > > On Thu, Jun 4, 2009 at 9:12 PM, Nick Baum wrote: > >> Hi guys, >> I've attached an old print settings mock up from Glen. I think it'd make a >> lot of sense to add the print settings on this page as well. >> >> If someone wants to take a stab at the print preview as pictured here, I >> think that'd be a great first step. Once we have that working, I'd be happy >> to mock up some ideas for settings. >> >> Cheers, >> >> -Nick >> >> On Thu, Jun 4, 2009 at 7:21 AM, Marc-Antoine Ruel wrote: >> >>> Most of the print preview will be implement in RenderView and friends >>> which is in chrome/ ... (previously it was all in browser/ in fact) >>> >>> On Jun 4, 2009 10:04 AM, "Mohamed Mansour" >>> wrote: >>> >>> I don't think so, it would be using the same infrastructure of history / >>> downloads / and new tab page. Someone can correct me if I am wrong. >>> >>> -- Mohamed Mansour >>> >>> On Thu, Jun 4, 2009 at 9:43 AM, Marshall Greenblatt < >>> magreenbl...@gmail.com> wrote: > > Hi 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] sqlite3 usage in chromium
Hi, I see chromium uses sqlite3. Does it use it for Google Gear only? or it uses it for other stuff, e.g. cookies, bookmark, history, user settings Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: sqlite3 usage in chromium
It is used for other stuff. It shouldn't be too hard to search the code base to find out specifically where. On Tue, Jun 9, 2009 at 7:23 PM, Meryl Silverburgh < silverburgh.me...@gmail.com> wrote: > > Hi, > I see chromium uses sqlite3. > Does it use it for Google Gear only? > or it uses it for other stuff, e.g. cookies, bookmark, history, user > settings > > Thank you. > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Is there any way to change the default (i.e. default.dll) theme DLL?
ResourceBundle::LoadThemeResources() always loads default.dll from DIR_THEMES. Other than overriding DIR_THEMES via the PathService, is there another way to change the name of the DLL? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is there any way to change the default (i.e. default.dll) theme DLL?
Themes for Chromium is underway, you shouldn't modify that. You can see the status of the development of themes by looking at these issues: http://code.google.com/p/chromium/issues/list?can=1&q=label:themes -- Mohamed Mansour On Wed, Jun 10, 2009 at 12:28 AM, Daniel Cowx wrote: > > ResourceBundle::LoadThemeResources() always loads default.dll from > DIR_THEMES. Other than overriding DIR_THEMES via the PathService, is > there another way to change the name of the DLL? > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is there any way to change the default (i.e. default.dll) theme DLL?
I think the answer is no for an official compile of Google Chrome. The default.dll is hardcoded in app/resource_bundle_win.cc. But for your own compile, does changing the hardcoded value in app/ resource_bundle_win.cc count as a solution? On Jun 9, 9:28 pm, Daniel Cowx wrote: > ResourceBundle::LoadThemeResources() always loads default.dll from > DIR_THEMES. Other than overriding DIR_THEMES via the PathService, is > there another way to change the name of the DLL? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is there any way to change the default (i.e. default.dll) theme DLL?
Yeah, I could change the value in resource_bundle_win.cc and wrap it in a PP directive for my own build, but it becomes such a pain to maintain this over time (merging gets annoying). It would be easier if I didnt have to do this via a PP directive for my own build. Question: Does anyone have objections to including a default param in the call to ResourceBundle::LoadThemeResources() that causes default.dll to be loaded by default? Alternatively, since default params are frowned upon, I could provide a wrapper function in ResourceBundle to accomplish the same end. -Daniel On Jun 9, 9:36 pm, dhhwai wrote: > I think the answer is no for an official compile of Google Chrome. > The default.dll is hardcoded in app/resource_bundle_win.cc. > > But for your own compile, does changing the hardcoded value in app/ > resource_bundle_win.cc count as a solution? > > On Jun 9, 9:28 pm, Daniel Cowx wrote: > > > > > ResourceBundle::LoadThemeResources() always loads default.dll from > > DIR_THEMES. Other than overriding DIR_THEMES via the PathService, is > > there another way to change the name of the DLL? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is there any way to change the default (i.e. default.dll) theme DLL?
How about a compile-time define instead? then it's a simple matter of adding a -DTHEME_DLL my.dll On Tue, Jun 9, 2009 at 10:51 PM, Daniel Cowx wrote: > > Yeah, I could change the value in resource_bundle_win.cc and wrap it > in a PP directive for my own build, but it becomes such a pain to > maintain this over time (merging gets annoying). It would be easier if > I didnt have to do this via a PP directive for my own build. > > Question: > Does anyone have objections to including a default param in the call > to ResourceBundle::LoadThemeResources() that causes default.dll to be > loaded by default? Alternatively, since default params are frowned > upon, I could provide a wrapper function in ResourceBundle to > accomplish the same end. > > -Daniel > > On Jun 9, 9:36 pm, dhhwai wrote: >> I think the answer is no for an official compile of Google Chrome. >> The default.dll is hardcoded in app/resource_bundle_win.cc. >> >> But for your own compile, does changing the hardcoded value in app/ >> resource_bundle_win.cc count as a solution? >> >> On Jun 9, 9:28 pm, Daniel Cowx wrote: >> >> >> >> > ResourceBundle::LoadThemeResources() always loads default.dll from >> > DIR_THEMES. Other than overriding DIR_THEMES via the PathService, is >> > there another way to change the name of the DLL? > > > -- Stefan Nuxoll --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is there any way to change the default (i.e. default.dll) theme DLL?
Or how about setting the default value of the theme in the Preferences file and loading it from there? On Jun 9, 9:53 pm, Stefan Nuxoll wrote: > How about a compile-time define instead? then it's a simple matter of > adding a -DTHEME_DLL my.dll > > > > > > On Tue, Jun 9, 2009 at 10:51 PM, Daniel Cowx wrote: > > > Yeah, I could change the value in resource_bundle_win.cc and wrap it > > in a PP directive for my own build, but it becomes such a pain to > > maintain this over time (merging gets annoying). It would be easier if > > I didnt have to do this via a PP directive for my own build. > > > Question: > > Does anyone have objections to including a default param in the call > > to ResourceBundle::LoadThemeResources() that causes default.dll to be > > loaded by default? Alternatively, since default params are frowned > > upon, I could provide a wrapper function in ResourceBundle to > > accomplish the same end. > > > -Daniel > > > On Jun 9, 9:36 pm, dhhwai wrote: > >> I think the answer is no for an official compile of Google Chrome. > >> The default.dll is hardcoded in app/resource_bundle_win.cc. > > >> But for your own compile, does changing the hardcoded value in app/ > >> resource_bundle_win.cc count as a solution? > > >> On Jun 9, 9:28 pm, Daniel Cowx wrote: > > >> > ResourceBundle::LoadThemeResources() always loads default.dll from > >> > DIR_THEMES. Other than overriding DIR_THEMES via the PathService, is > >> > there another way to change the name of the DLL? > > -- > Stefan Nuxoll --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Use of User Macros for RelativePath in vcproj files
I notice that some of our projects (e.g. chrome_resources) reference GRIT generated files via the RelativePath entry in the *.vcproj file via the user macro $(OutDir). Can someone please provide insight into how this was made to work? I've tried this quite a few times to no avail. Whenever I try to add a user macro (even copy and pasting what's in chrome_resources.vcproj) into my own project, Visual Studio complains that it can't resolve the path. What gives? --~--~-~--~~~---~--~~ 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: Use of User Macros for RelativePath in vcproj files
I figured it out and thought I'd share with others. Turns out that you have to restart Visual Studio and reload the whole solution for it to pickup the correct paths when you're using a macro. Cheers, Daniel On Jun 9, 10:58 pm, Daniel Cowx wrote: > I notice that some of our projects (e.g. chrome_resources) reference > GRIT generated files via the RelativePath entry in the *.vcproj file > via the user macro $(OutDir). > > Can someone please provide insight into how this was made to work? > I've tried this quite a few times to no avail. Whenever I try to add a > user macro (even copy and pasting what's in chrome_resources.vcproj) > into my own project, Visual Studio complains that it can't resolve the > path. What gives? --~--~-~--~~~---~--~~ 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: Use of User Macros for RelativePath in vcproj files
On Tue, Jun 9, 2009 at 11:19 PM, Daniel Cowx wrote: > Turns out that you have to restart Visual Studio and reload the whole > solution for it to pickup the correct paths when you're using a macro. In general, any time you change a .sln, .vcproj, or .vsprops, you should restart Visual Studio. While this isn't always necessary, it can prevent a lot of very cryptic bugs. This is also why you should restart Visual Studio when doing a gclient sync -- one of the above types of files may have changed. 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: Is there any way to change the default (i.e. default.dll) theme DLL?
On Tue, Jun 9, 2009 at 9:51 PM, Daniel Cowx wrote: > Question: > Does anyone have objections to including a default param in the call > to ResourceBundle::LoadThemeResources() that causes default.dll to be > loaded by default? Default params are forbidden by the Google style guide (as you seem to allude to below). Alternatively, since default params are frowned > upon, I could provide a wrapper function in ResourceBundle to > accomplish the same end. I suspect the Chromium developers in general are fairly opposed to adding more flexibility (and complexity) to the theme system underpinnings, as (as Mohamed mentioned previously on this thread) official support for theming is mostly in-place and presumably will cover most needs here. Glen Murphy is the best person to ask if you have specific theme questions. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
