Re: [Fwd: Re: [chromium-dev] Hammer compile error]
2009/3/22 Scott Carlow : > I am not quite sure what to make of this. It is all pointing to errors > in the code. Could I have picked up a bad tarball by some odd chance? > Should I try to grab another sourcecode package, or just go in and try > to correct the errors? I don't see this. Where did you download the code? You may want to run gclient sync again. -- Seo Sanghyeon --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[Fwd: Re: [chromium-dev] Hammer compile error]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scottie wrote: > > I am trying to compile the latest Chromium source on Ubuntu 8.10. I > > have already installed depot_tools. Using hammer to compile the code, > > I get two errors that halt scons: > > > > /home/scott/chromium/src/chrome/common/render_messages.h:498: error: > > 'RAW_KEY_DOWN' is not a member of 'WebInputEvent' > > Compiling Hammer/dbg/obj/chrome/browser/page_state.o > > Running GRIT on app/generated_resources.grd > > scons: *** [Hammer/dbg/obj/chrome/browser/chrome_plugin_host.o] Error > > 1 > > > > > > Any suggestions? I'm a rookie when it comes to development, so it may > > just be user error. > > > > > > > > I take that back. I got passed that issue by making some changes to webinputevent.h I know run into some more complicated errors. common/resource_dispatcher.cc:418: error: no matching function for call to 'webkit_glue::ResourceLoaderBridge::Peer::OnCompletedRequest(const URLRequestStatus&, const std::basic_string, std::allocator >&)' /home/scott/chromium/src/webkit/glue/resource_loader_bridge.h:114: note: candidates are: virtual void webkit_glue::ResourceLoaderBridge::Peer::OnCompletedRequest(const URLRequestStatus&) Compiling Hammer/dbg/obj/chrome/common/sandbox_init_wrapper.o scons: *** [Hammer/dbg/obj/chrome/common/resource_dispatcher.o] Error 1 scons: building terminated because of errors. I am not quite sure what to make of this. It is all pointing to errors in the code. Could I have picked up a bad tarball by some odd chance? Should I try to grab another sourcecode package, or just go in and try to correct the errors? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBAgAGBQJJxbmWAAoJEIqHGvHj/PGMoLkP/jhKKOOHQRKUumy9BB4GLMFh TP2aCYmCI3IFwVIfsjZHShZIa+5m886j7dQ0ic2RM6n2GZtPf141kxu7YpekNKeD UF/0eYE2/9rk7r7jCFae24y5ZfYbnXD8/dzDF5icSjanz/QDoDjZvngp1/HALxdO 95+Zl/OFLoi231pa3pwXVoEUE9RwBGGTt2EUGINpr84hUb+4trPrWE5/XR0JxGG5 k6VoEAIV+Vunt/HEcyP208rbC79OmCwQ7z3Fr2lIIAl8E/QI4f/7uqgVpdNFOSd4 GOdV1mh2loWLlOB9x0sK5AaPgCCM7MyGHOZaVroZpVLlFXA/tTvjauty5Bp4soAU IECBYkcgCeenU4rg27w6uO5paN9XRuN/qe7rOGi2fPm8PUK1g4wUChnB8jBaU0yB HyZiBDv1b1WcbZRCylE9u19YlGlO5PzX7YXEv5SXtvFAn17xhpUIIo/KDlaU04TS JqohfXbCNZfdjJvh6vePHeJ/Y0JbBklNEvM56EIK8hx0/rVki2cvClpTsky/xVhe N1aDW17yUYJgsLIQrqhPJ1HDZ1pMXX9DUOiF8OPW636t0FzRGahBTv/ZPWpmZ4Ww yDO4J+flQWyUQg5EoZToOzuzRVvEa8a0ngfEQ3lrqNpUoHVzJAvAMWqAbmDFkbrl HGPI63w9sayLjwZ2QEST =bhBg -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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: Theme Implimentation
You might try asking one of the folk who built the third party theming software for this capability. -Ben On Sat, Mar 21, 2009 at 7:44 PM, Meok wrote: > > Hi all. In light of sites like http://lab209.com/google-chrome-themes/ > which offer a variety of themes which can be applied to Chromium > simply by over-writing one file, my question is, how difficult is it > to write a little module that tells Chrome to switch the default.dll > file (I think that's the one) with another one upon restart. Chrome > would automatically make a backup of the original for when you want to > switch back. > > I'm not a programmer, at least not at that level, so I don't know how > difficult that would be, but I was just thinking that if people can > manually change the theme, it shouldn't be too difficult to make a > little UI in the browser to automate the process. The capability is > already there to change the skin and it would appease or "wow" A LOT > of reluctant users until the full Extension framework is finished. > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Theme Implimentation
Hi all. In light of sites like http://lab209.com/google-chrome-themes/ which offer a variety of themes which can be applied to Chromium simply by over-writing one file, my question is, how difficult is it to write a little module that tells Chrome to switch the default.dll file (I think that's the one) with another one upon restart. Chrome would automatically make a backup of the original for when you want to switch back. I'm not a programmer, at least not at that level, so I don't know how difficult that would be, but I was just thinking that if people can manually change the theme, it shouldn't be too difficult to make a little UI in the browser to automate the process. The capability is already there to change the skin and it would appease or "wow" A LOT of reluctant users until the full Extension framework is finished. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Quick question about struct initialization
Can someone please confirm whether it's safe to initialize a POD
struct using:
MyStruct blat = {0};
with gcc on Linux/Mac? I know this works fine with the VC compiler,
but I dont have gcc handy.
Thanks,
D
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Rendering issues in chromium with theme applied
Hi, This issue is really quite serious for me as I am unable to use chromium on certain websites. I have hacked my uxtheme.dll on Windows XP so that I may apply third party visual themes to windows. I've applied a theme called XPMC (URL: http://b0se.deviantart.com/art/XPMC-RC3-20901820 ). This theme is in the form of an msstyles file. When I visit this google group to post a new message, the edit boxes do not render. More specifically, their borders are not drawing. It is only when I click to place my caret inside one of them does the yellow border appear. Is there a quick work around for this issue (other than the obvious: disabling my custom theme)? Maybe there is some command line parameter I can specify to tell chromium to not use the system theme. I'm using version 2.0.170.0 of Chromium. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Hammer compile error
I am trying to compile the latest Chromium source on Ubuntu 8.10. I have already installed depot_tools. Using hammer to compile the code, I get two errors that halt scons: /home/scott/chromium/src/chrome/common/render_messages.h:498: error: 'RAW_KEY_DOWN' is not a member of 'WebInputEvent' Compiling Hammer/dbg/obj/chrome/browser/page_state.o Running GRIT on app/generated_resources.grd scons: *** [Hammer/dbg/obj/chrome/browser/chrome_plugin_host.o] Error 1 Any suggestions? I'm a rookie when it comes to development, so it may just be user error. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Views and Linux
Summary: The Google Chrome team should build the Linux front end for Google Chrome using Views and Gtk rather than using Gtk alone. Operational Details This week, Elliot will continue to stub out some of the basic widget and top level window framework. I will continue vacuuming some of the other constructs we have (NativeControl and a few things in browser/). I've put together a basic work list that will bring almost everything up under the label "views-linux": http://code.google.com/p/chromium/issues/list?q=label:views-linux Feel free to sign up for aspects that you're interested in working on. Rationale >From a product perspective, the Google Chrome leadership has a strong desire to have the browser that Google delivers as "Google Chrome" share the clearly identifiable aesthetic of Chrome on other platforms. On MacOS it is possible to do this while blending in fairly well with the surrounding environment. The prototypes that Cole has been building and that have been making their way into the Mac ToT bear this out. On Linux, the variety of window managers in use mean that to achieve our unique skyline, in all likelihood the window manager frame would have to be disabled and we would provide our own. Because there isn't a consistent window manager appearance, there's no stable target for what the browser frame and hence UI (which derives its appearance from the frame) should look like. Because of this, the Linux team has been copying the Windows UI appearance using Gtk and friends for the widgets, layout and rendering. It's my opinion that the engineering work in doing this is not worth it considering the tradeoffs: - It requires maintaining a front end that looks identical to Windows but which has entirely different code, which includes writing a new custom layout and event propagation system for things like the TabStrip, where one already exists on Windows. - Regardless of whether the underlying browser UI were implemented entirely in Gtk using its own layout system or with a combination of Gtk+views, it's likely that there'll be a number of Linux users who don't like what we produce because to get the "Chrome look" we will have to disable the frame and use non-standard button appearances. For these reasons I think the best investment of time is to bring up Views so that we can share code with Windows. We will retain Gtk widgets everywhere where the Windows front end uses Windows Common Controls - for native buttons, checkboxes, text fields, some menus, etc - so that we don't need to roll our own IME or accessibility. Views is used to provide the containing layout engine and custom rendering system. Over the past week Elliot and I have been investigating bringing up the the base elements of the Views system on Linux. I had some reason to believe that it may be easier to do so now since over the past month or so I've made some improvements to the views::Window class hierarchy that simplifies the arrangement considerably. From the work Elliot's been able to do, I believe it should be possible to bring up Views widgets relatively easily. I am investing time in helping clear the path in the Views code to do so (See my earlier emails about native controls). What this means for Gtk-only and Qt: I am actually very supportive of Gtk- and Qt-only front ends. I am supportive of them not looking like Chrome if it means they fit in better with the GNOME and KDE environments. I would love to see the Chromium project deliver (and host the source of) something that each of those environments feel is worthy of being a first class browser for their system. This work should not be encumbered by having to have Chrome's exact aesthetic. My comments above are related to where I think the efforts of the Google development team's effort should be directed at this time. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Linux ui_tests
Nice work!! Thanks for making this happen :-) -Darin 2009/3/20 Paweł Hajdan Jr. > I just checked in a change which makes first UI test run on Linux. The > lucky winner is ImagesTest.AnimatedGIFs. Enjoy! > > Paweł > > > > --~--~-~--~~~---~--~~ 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: ResourceMessageFilter::OnGet(Root)WindowRect and NULL windows
It would be nice to track down the source of the null NativeViewId. I bet that corresponds to a real bug. -Darin On Fri, Mar 20, 2009 at 9:36 AM, Adam Langley wrote: > > On Fri, Mar 20, 2009 at 8:11 AM, Avi Drissman wrote: > > http://codereview.chromium.org/47002 > > http://crbug.com/9060 > > There's several parts here: > * Why is the renderer asking questions about a NULL NativeViewId? > * Why does that result in a NULL pointer in the browser? > > I don't know the answer to the first. It's probably some assumption in > WebKit which assumes that it has a valid window at all times and we > break that with multiprocess. However, it seems to be harmless. > > As for the second: we currently take pointers, raw from the renderer. > This is just a hack. At some point, we need to make NativeViewIds be > something else and have a proper translation layer. But we don't yet. > > > > 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: depot_tools needs msvcrt71?
Yeah, this sounds familiar. I think most developers end up having those DLLs installed somehow. Maybe they get installed once you install Visual Studio? Somehow we seem to have not had this issue come up before or as often as I might have expected. -Darin On Sat, Mar 21, 2009 at 9:40 AM, Dan Kegel wrote: > > Our gclient's python may need to bundle msvcrt71.dll; > without it, on my Win Vista 64 system, I get > repeated "this app needs msvcrt71" errors. > > Well-behaved apps, like > http://prdownloads.sourceforge.net/bzflag/bzflag-2.0.10.exe?download > do bundle that dll, and in fact the workaround I chose > was to download that file and copy the three ms*71*dll > files to c:/windows/sysWOW64. > (I probably should have copied it into depot_tools > next to python.exe instead, but didn't think of that.) > > > > --~--~-~--~~~---~--~~ 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: Need advice on where localStorage should live
+chromium-dev. On Sat, Mar 21, 2009 at 9:30 AM, John Abd-El-Malek wrote: > > > On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow wrote: > >> *If you don't care where various bits of the localStorage implementation >> live and you aren't scared about letting stuff out of the sandbox, you can >> stop reading now.* >> >> * >> * >> Background: >> >> For those who don't know the spec by heart: SessionStorage can be thought >> of as 'tab local' storage space for each origin. LocalStorage is shared >> across all browser windows of the same origin and is persistent. All data >> is stored in key/value pairs where both the key and value are strings. It's >> possible to subscribe to DOM storage events. Events and ease of use are why >> a developer might use localStorage even though the database interface >> exists. The exact spec is here: http://dev.w3.org/html5/webstorage/ >> >> >> *Where should the localStorage implementation live? >> * >> >> I'm planning on implementing localStorage very soon within Chromium. >> Unfortunately, how to do this is not very clearcut. Here are all the >> possibilities I know of so far: (Note that I'm intentionally ignoring the >> backing file format for now...as that debate will partially depend on how >> it's implemented.) >> >> 1) The most obvious solution is to have have the browser process keep >> track of the key/values for each origin and write it to disk. The problem >> with this approach is that we're allowing user supplied data to exist in >> memory (possibly the stack at times, though we could probably avoid this if >> we tried) outside of a sandbox. Ian Fette (and I'm sure others) have pretty >> big reservations for this reason. That said, this is definitely the >> simplest and cleanest solution, so if we can figure out something that we're >> confident with security wise, this is how I'd like to do it. >> > > I really don't see the big issue here. We already do this with renderer > supplied data such as FORMs, POST, even really long URLs. The main point is > to ensure that we don't trust that data. > > >> >> 2) What follows from #1 is simply pulling all the localStorage code into >> its own (sandboxed) process. The problem is that, unless a lot of the >> internet starts using localStorage, it seems disproportionately heavy >> weight. Starting it on demand and killing it off if localStorage hasn't >> been used for a while would mitigate. >> >> 3) A completely different solution is to use shared memory + the code >> recently written to pass file handles between processes. The shared memory >> would be used to coordinate between processes and to store key/val data. >> One render process for each origin will take responsibility for syncing data >> to disk. Event notifications can occur either via IPC (though sharing >> key/val data can NOT for latency/responsiveness reasons) or shared >> memory--whichever is easier. Obviously the chief problem with this is >> memory usage. I'm sure it'll also be more complex and have a greater >> bug/exploit cross section. >> >> 4) A variation of #3 would be to keep all key/val data in the file and >> only use shared memory for locking (if necessary). I'm not going to discuss >> the implementation details because I don't want us to get hung up on them, >> but the general idea would be for each process to have an open file handle >> for their origin(s) and somehow (shared memory, flock, etc) coordinate with >> the other processes. This will almost certainly be slower than memory (if >> nothing else, due to system calls) but it'll use less memory and possibly be >> easier to make secure. >> >> 5) One last option is to layer the whole thing on top of the HTML 5 >> database layer. Unfortunately, there's no efficient way for this layer to >> support events. Even hooking directly into sqlite won't work since its >> triggers layer apparently only notifies you (i.e. works) if the >> insert/delete/update happens in your own process. Of course sqlite can be >> the backing for any other option, but please, let's hold off on that >> discussion for now. >> > > It seems that either way you have to build your own custom notification > system in order to alert all renderer processes if a url they have loaded > has updated storage values. Why not use sqlite in each renderer process > then, with this system build on top of it? > > >> >> >> *So here are my questions:* >> >> How paranoid should we be about passing a user created string to the >> browsing process and having it send the data on to the renderer and some >> backend like sqlite? >> > Good question. 100% of the untrusted web content that ends up in sandboxed processes ends up flowing thru the browser process, and much of it gets cached on disk. Every page and embedded resource, script generated values of in form posts, cookie strings etc, all of it is resides in the process browser for a time and on disk. This content is no different... so how paranoid... since its not i
[chromium-dev] depot_tools needs msvcrt71?
Our gclient's python may need to bundle msvcrt71.dll; without it, on my Win Vista 64 system, I get repeated "this app needs msvcrt71" errors. Well-behaved apps, like http://prdownloads.sourceforge.net/bzflag/bzflag-2.0.10.exe?download do bundle that dll, and in fact the workaround I chose was to download that file and copy the three ms*71*dll files to c:/windows/sysWOW64. (I probably should have copied it into depot_tools next to python.exe instead, but didn't think of that.) --~--~-~--~~~---~--~~ 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: Need advice on where localStorage should live
On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow wrote: > *If you don't care where various bits of the localStorage implementation > live and you aren't scared about letting stuff out of the sandbox, you can > stop reading now.* > > * > * > Background: > > For those who don't know the spec by heart: SessionStorage can be thought > of as 'tab local' storage space for each origin. LocalStorage is shared > across all browser windows of the same origin and is persistent. All data > is stored in key/value pairs where both the key and value are strings. It's > possible to subscribe to DOM storage events. Events and ease of use are why > a developer might use localStorage even though the database interface > exists. The exact spec is here: http://dev.w3.org/html5/webstorage/ > > > *Where should the localStorage implementation live? > * > > I'm planning on implementing localStorage very soon within Chromium. > Unfortunately, how to do this is not very clearcut. Here are all the > possibilities I know of so far: (Note that I'm intentionally ignoring the > backing file format for now...as that debate will partially depend on how > it's implemented.) > > 1) The most obvious solution is to have have the browser process keep > track of the key/values for each origin and write it to disk. The problem > with this approach is that we're allowing user supplied data to exist in > memory (possibly the stack at times, though we could probably avoid this if > we tried) outside of a sandbox. Ian Fette (and I'm sure others) have pretty > big reservations for this reason. That said, this is definitely the > simplest and cleanest solution, so if we can figure out something that we're > confident with security wise, this is how I'd like to do it. > I really don't see the big issue here. We already do this with renderer supplied data such as FORMs, POST, even really long URLs. The main point is to ensure that we don't trust that data. > > 2) What follows from #1 is simply pulling all the localStorage code into > its own (sandboxed) process. The problem is that, unless a lot of the > internet starts using localStorage, it seems disproportionately heavy > weight. Starting it on demand and killing it off if localStorage hasn't > been used for a while would mitigate. > > 3) A completely different solution is to use shared memory + the code > recently written to pass file handles between processes. The shared memory > would be used to coordinate between processes and to store key/val data. > One render process for each origin will take responsibility for syncing data > to disk. Event notifications can occur either via IPC (though sharing > key/val data can NOT for latency/responsiveness reasons) or shared > memory--whichever is easier. Obviously the chief problem with this is > memory usage. I'm sure it'll also be more complex and have a greater > bug/exploit cross section. > > 4) A variation of #3 would be to keep all key/val data in the file and > only use shared memory for locking (if necessary). I'm not going to discuss > the implementation details because I don't want us to get hung up on them, > but the general idea would be for each process to have an open file handle > for their origin(s) and somehow (shared memory, flock, etc) coordinate with > the other processes. This will almost certainly be slower than memory (if > nothing else, due to system calls) but it'll use less memory and possibly be > easier to make secure. > > 5) One last option is to layer the whole thing on top of the HTML 5 > database layer. Unfortunately, there's no efficient way for this layer to > support events. Even hooking directly into sqlite won't work since its > triggers layer apparently only notifies you (i.e. works) if the > insert/delete/update happens in your own process. Of course sqlite can be > the backing for any other option, but please, let's hold off on that > discussion for now. > It seems that either way you have to build your own custom notification system in order to alert all renderer processes if a url they have loaded has updated storage values. Why not use sqlite in each renderer process then, with this system build on top of it? > > > *So here are my questions:* > > How paranoid should we be about passing a user created string to the > browsing process and having it send the data on to the renderer and some > backend like sqlite? > > Do we trust sqlite enough to use it outside of a sandbox? (Hopefully, > because we're already doing this, right? If not are there other mechanisms > for storing the data on disk that we do trust?) > > Would we feel more comfortable with #1 if the renderer processes somehow > mangled the keys and values before sending them out? For example, they > could base64 encode them or even do something non-deterministic so that > attackers have no guarantee about what the memory would look like that's > passing through the browser process? > > > And, most importantly, which op
