[chromium-dev] Re: Qt now a possibility?
I'm not understanding the animosity shown toward GTK in this thread thus far. A majority of GNU/Linux distros are now using GNOME as the default desktop, I use and nearly every Free Software user that I know IRL uses and prefers it. I'm not going to bad mouth QT, I used it predominately a couple years ago in the 3.2 days and used it up until the betas of 3.5. All I want is a fast browser and I for one am happy about the choice to use GTK, not only because I use GNOME but also because I've noticed quite a bit of difference between loading QT in a non-QT environment vs loading GTK in a non-GTK environment, GTK is faster. Try loading Dolphin or Konqueror from GNOME and then Thunar, nautilus or epiphany from KDE and it's apparent. Dolphin is a very fast application, pretty darn slow to load in GNOME, Thunar is comparable directly, fast as hell to load in either environment. All I know is that there shouldn't be this kind of hate in the Free Software community. --~--~-~--~~~---~--~~ 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: Qt now a possibility?
I'm not understanding the animosity shown toward GTK in this thread thus far. A majority of GNU/Linux distros are now using GNOME as the default distro, I use and nearly every Free Software user that I know IRL uses and prefers it. I'm not going to bad mouth QT, I used it predominately a couple years ago in the 3.2 days and used it up until the betas of 3.5. All I want is a fast browser and I for one am happy about the choice to use GTK, not only because I use GNOME but also because I've noticed quite a bit of difference between loading QT in a non-QT environment vs loading GTK in a non-GTK environment, GTK is faster. Try loading Dolphin or Konqueror from GNOME and then Thunar, nautilus or epiphany from KDE and it's apparent. Dolphin is a very fast application, pretty darn slow to load in GNOME, Thunar is comparable directly, fast as hell to load in either environment. All I know is that there shouldn't be this kind of hate in the Free Software community. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Why the hate?
I'm not understanding the animosity shown toward GTK in this thread thus far. A majority of GNU/Linux distros are now using GNOME as the default distro, I use and nearly every Free Software user that I know IRL uses and prefers it. I'm not going to bad mouth QT, I used it predominately a couple years ago in the 3.2 days and used it up until the betas of 3.5. All I want is a fast browser and I for one am happy about the choice to use GTK, not only because I use GNOME but also because I've noticed quite a bit of difference between loading QT in a non-QT environment vs loading GTK in a non-GTK environment, GTK is faster. Try loading Dolphin or Konqueror from GNOME and then Thunar, nautilus or epiphany from KDE and it's apparent. Dolphin is a very fast application, pretty darn slow to load in GNOME, Thunar is comparable directly, fast as hell to load in either environment. All I know is that there shouldn't be this kind of hate in the Free Software community. --~--~-~--~~~---~--~~ 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: Merge 41017:41057 also needs a clobber for Windows folks
As it turns out, the clobber applies to Mac and possibly Linux builds. Basically, clobber all. :DG< On Wed, Feb 18, 2009 at 3:11 PM, Dimitri Glazkov wrote: > Hi All, > > Because the latest merge introduces a change to > third_party/WebKit/WebCore/css/html4.css, which is only picked up by > DerivedSources.make, making that change actually appear in your build > requires a clobber. > > :DG< > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Merge 41017:41057 also needs a clobber for Windows folks
Hi All, Because the latest merge introduces a change to third_party/WebKit/WebCore/css/html4.css, which is only picked up by DerivedSources.make, making that change actually appear in your build requires a clobber. :DG< --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] plugin info caching
> It appears that Mozilla (maybe for similar reasons) caches this info > across browser runs and relies on the file mtime to see when its cache > has expired, much to some users' dismay: > https://bugzilla.mozilla.org/show_bug.cgi?id=125469 > Or at least they did in 2002. ;) yea, they definitely still do this, although I don't know if they changed how they decide to update the cache. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Using Purify - how to fix the buildbots
I added a page to the wiki that talks about using Purify in the Chromium project: http://sites.google.com/a/chromium.org/dev/developers/how-tos/using-purify For Googlers, this is an updated version of an old page you may have seen before. It has a few important changes however, so I encourage you to read it. Most importantly, the instructions for how to address the bot turning red, and how to filter out errors temporarily have been updated and clarified. For contributors who don't have access to Purify, there's useful information here about how to tackle errors from the buildbot even without having Purify installed. Erik --~--~-~--~~~---~--~~ 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: checkdeps failure when a unit test relies on v8.h
Yes, exactly. Although there was a hilarious point in time when the guy who registered wpad.com could own the entire Internet. Adam On Wed, Feb 18, 2009 at 8:17 AM, Darin Fisher wrote: > Hmm... coffee kicking in... to answer my own question, since wpad > interception would probably be DNS based, the attacker could also just use > the same approach to intercept specific hostnames for plaintext HTTP. even > with PAC, the attacker wouldn't have much luck intercepting HTTPS, so the > attack surface doesn't seem any larger with PAC than it already is for > plaintext HTTP. > -Darin > > On Wed, Feb 18, 2009 at 8:00 AM, Darin Fisher wrote: >> >> Right... I meant the particular vector of faking the proxy auto config >> file to achieve HTTP interception. That Windows has "auto detect proxies" >> enabled by default would seem to make this an easy target for hackers. >> -Darin >> >> >> On Tue, Feb 17, 2009 at 10:16 PM, Adam Barth wrote: >>> >>> No one else has a sandbox for their JavaScript engine. ACE in their >>> JS engine is game over. >>> >>> Adam >>> >>> >>> On Tue, Feb 17, 2009 at 9:42 PM, Darin Fisher wrote: >>> > I wonder why this hasn't gotten much attention in other browsers... >>> > -Darin >>> > >>> > On Tue, Feb 17, 2009 at 1:42 PM, Adam Barth >>> > wrote: >>> >> >>> >> Hi Eric, >>> >> >>> >> On Tue, Feb 17, 2009 at 12:47 PM, Eric Roman >>> >> wrote: >>> >> > My goal is to do all the work necessary to get V8-PAC resolving >>> >> > working in the browser process first. >>> >> >>> >> That sounds like a good plan, but I think we should implement the >>> >> security mitigation as a second step. >>> >> >>> >> > The logic goes something like: >>> >> > * To exploit V8 you must be running an evil PAC script. >>> >> > * If you are running an evil PAC script, you are already screwed. >>> >> >>> >> The situation is a little more subtle than this. Here is how I think >>> >> about it: >>> >> >>> >> Threat Model: >>> >> >>> >> 1) You are using the browser on an untrusted network. Likelihood: >>> >> Routine (users routinely surf the Web on untrusted wireless networks, >>> >> for example in coffee shops and in airports). >>> >> >>> >> 2) V8 has an exploitable arbitrary code execution vulnerability. >>> >> Likelihood: Will occur at some point. Window of Vulnerability: One >>> >> patch cycle (exploitable ACEs in V8 are P0 bugs). >>> >> >>> >> Designs: >>> >> >>> >> 1) PAC in renderer process: Universal cross-site scripting. The >>> >> attacker can exploit V8, but the sandbox prevents the attacker from >>> >> reading or writing your hard drive. Severity: High. >>> >> >>> >> 2) PAC in browser process: Arbitrary code execution. The malicious >>> >> PAC script can now install malware on the user's machine. Severity: >>> >> Critical. >>> >> >>> >> Conclusion: >>> >> >>> >> Running PAC scripts in the browser process elevates the severity of a >>> >> reasonable chunk of attack surface (ACE in V8) from high to critical. >>> >> >>> >> Recommendation: >>> >> >>> >> Ideally, we would run the PAC script in a dedicated sandboxed process. >>> >> This would prevent a compromised PAC process from doing much of >>> >> anything. Short of that, we should run PAC scripts in the renderer >>> >> process. >>> >> >>> >> > The attacker can now INTERCEPT AND MODIFY all of your HTTP traffic! >>> >> >>> >> This is the same as universal cross-site scripting and is a >>> >> high-severity vulnerability. Being able to install malware on the >>> >> user's machine is more severe (e.g., critical). >>> >> >>> >> > All they really need to do is substitute the next EXE you download >>> >> > with the code they want to execute, and voila. >>> >> >>> >> This requires user interaction. Specifically, the user has to confirm >>> >> the corrupted download. Moreover, this attack vector is present >>> >> regardless of a vulnerability in V8 (i.e., ability 2 above) because an >>> >> untrusted network can do this already (i.e., just with ability 1 >>> >> above). >>> >> >>> >> 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: how keyboard input works
On Wed, Feb 18, 2009 at 8:28 AM, Avi Drissman wrote: > On Wed, Feb 18, 2009 at 11:22 AM, Darin Fisher wrote: > >> Notice that except for a bool, the rest are not part of the structure when >> PLATFORM(CHROMIUM) is defined, so for us PlatformKeyboardEvent is platform >> independent. >> > > Yes, I just found PlatformKeyboardEventChromium.cpp. Looking at > disambiguateKeyDownEvent, I see comments like "we lack information..." Is > there any way we can pass more info along to fix those cases? (Though I'm > not certain enough with the code to say what those cases are...) > > Avi > We can extend WebKeyboardEvent if we need to, but what additional information do you need? Since the eventual DOM keyboard events are platform independent, it seems like we should be able to translate once to a platform independent representation. What am I missing? -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: how keyboard input works
On Wed, Feb 18, 2009 at 11:43 AM, Darin Fisher wrote: > We can extend WebKeyboardEvent if we need to, but what additional > information do you need? > Don't worry, I've got it now. Avi --~--~-~--~~~---~--~~ 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 keyboard input works
OK On Wed, Feb 18, 2009 at 8:42 AM, Avi Drissman wrote: > OK, so I think I see what needs to be done. What was tripping me up was > that though we want WebKeyboardEvent to match up with PlatformKeyboardEvent, > it's totally different now. We can fix that. > > Avi > > > On Wed, Feb 18, 2009 at 11:28 AM, Avi Drissman wrote: > >> On Wed, Feb 18, 2009 at 11:22 AM, Darin Fisher wrote: >> >>> Notice that except for a bool, the rest are not part of the structure >>> when PLATFORM(CHROMIUM) is defined, so for us PlatformKeyboardEvent is >>> platform independent. >>> >> >> Yes, I just found PlatformKeyboardEventChromium.cpp. Looking at >> disambiguateKeyDownEvent, I see comments like "we lack information..." Is >> there any way we can pass more info along to fix those cases? (Though I'm >> not certain enough with the code to say what those cases are...) >> >> Avi >> > > --~--~-~--~~~---~--~~ 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 keyboard input works
OK, so I think I see what needs to be done. What was tripping me up was that though we want WebKeyboardEvent to match up with PlatformKeyboardEvent, it's totally different now. We can fix that. Avi On Wed, Feb 18, 2009 at 11:28 AM, Avi Drissman wrote: > On Wed, Feb 18, 2009 at 11:22 AM, Darin Fisher wrote: > >> Notice that except for a bool, the rest are not part of the structure when >> PLATFORM(CHROMIUM) is defined, so for us PlatformKeyboardEvent is platform >> independent. >> > > Yes, I just found PlatformKeyboardEventChromium.cpp. Looking at > disambiguateKeyDownEvent, I see comments like "we lack information..." Is > there any way we can pass more info along to fix those cases? (Though I'm > not certain enough with the code to say what those cases are...) > > Avi > --~--~-~--~~~---~--~~ 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 keyboard input works
On Wed, Feb 18, 2009 at 11:22 AM, Darin Fisher wrote: > Notice that except for a bool, the rest are not part of the structure when > PLATFORM(CHROMIUM) is defined, so for us PlatformKeyboardEvent is platform > independent. > Yes, I just found PlatformKeyboardEventChromium.cpp. Looking at disambiguateKeyDownEvent, I see comments like "we lack information..." Is there any way we can pass more info along to fix those cases? (Though I'm not certain enough with the code to say what those cases are...) Avi --~--~-~--~~~---~--~~ 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 keyboard input works
On Wed, Feb 18, 2009 at 8:18 AM, Avi Drissman wrote: > On Wed, Nov 12, 2008 at 7:28 PM, Darin Fisher wrote: > >> The intent was for WebKeyboardEvent to mirror PlatformKeyboardEvent such >> that conversion between the two was a simple as copying fields directly. > > > The issue with this approach is that PlatformKeyboardEvent is not a simple > POD class, and is not a "cross-platform" keyboard abstraction as it's > touted. It's ifdef-ed all over the place per-platform. > I think you are referring to these data members: #if PLATFORM(MAC) RetainPtr m_macEvent; #endif #if PLATFORM(WIN) || PLATFORM(CHROMIUM) bool m_isSystemKey; #endif #if PLATFORM(GTK) GdkEventKey* m_gdkEventKey; #endif #if PLATFORM(QT) QKeyEvent* m_qtEvent; #endif Notice that except for a bool, the rest are not part of the structure when PLATFORM(CHROMIUM) is defined, so for us PlatformKeyboardEvent is platform independent. -Darin > > > We *can* treat it as such, though, and it appears we're already trying to > do so (see the #if PLATFORM(CHROMIUM) on the m_isSystemKey member). That > means we would haul all the platform code back up from WebCore to glue, and > keep a duplicated copy. (We couldn't use it directly for various reasons > enumerated elsewhere.) > > On Wed, Nov 12, 2008 at 2:59 PM, Evan Martin wrote: > >> 3) [...]we have code that knows how to serialize >> those over the IPC layer[...] > > > = reinterpret_cast (see RenderWidgetHost::ForwardInputEvent as > an example). > > It's probably the right idea to promote events to being first-class IPC > citizens. > > Avi > > > > > --~--~-~--~~~---~--~~ 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 keyboard input works
On Wed, Nov 12, 2008 at 7:28 PM, Darin Fisher wrote: > The intent was for WebKeyboardEvent to mirror PlatformKeyboardEvent such > that conversion between the two was a simple as copying fields directly. The issue with this approach is that PlatformKeyboardEvent is not a simple POD class, and is not a "cross-platform" keyboard abstraction as it's touted. It's ifdef-ed all over the place per-platform. We *can* treat it as such, though, and it appears we're already trying to do so (see the #if PLATFORM(CHROMIUM) on the m_isSystemKey member). That means we would haul all the platform code back up from WebCore to glue, and keep a duplicated copy. (We couldn't use it directly for various reasons enumerated elsewhere.) On Wed, Nov 12, 2008 at 2:59 PM, Evan Martin wrote: > 3) [...]we have code that knows how to serialize > those over the IPC layer[...] = reinterpret_cast (see RenderWidgetHost::ForwardInputEvent as an example). It's probably the right idea to promote events to being first-class IPC citizens. Avi --~--~-~--~~~---~--~~ 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: checkdeps failure when a unit test relies on v8.h
Hmm... coffee kicking in... to answer my own question, since wpad interception would probably be DNS based, the attacker could also just use the same approach to intercept specific hostnames for plaintext HTTP. even with PAC, the attacker wouldn't have much luck intercepting HTTPS, so the attack surface doesn't seem any larger with PAC than it already is for plaintext HTTP. -Darin On Wed, Feb 18, 2009 at 8:00 AM, Darin Fisher wrote: > Right... I meant the particular vector of faking the proxy auto config file > to achieve HTTP interception. That Windows has "auto detect proxies" > enabled by default would seem to make this an easy target for hackers. > -Darin > > > > On Tue, Feb 17, 2009 at 10:16 PM, Adam Barth wrote: > >> No one else has a sandbox for their JavaScript engine. ACE in their >> JS engine is game over. >> >> Adam >> >> >> On Tue, Feb 17, 2009 at 9:42 PM, Darin Fisher wrote: >> > I wonder why this hasn't gotten much attention in other browsers... >> > -Darin >> > >> > On Tue, Feb 17, 2009 at 1:42 PM, Adam Barth >> wrote: >> >> >> >> Hi Eric, >> >> >> >> On Tue, Feb 17, 2009 at 12:47 PM, Eric Roman >> wrote: >> >> > My goal is to do all the work necessary to get V8-PAC resolving >> >> > working in the browser process first. >> >> >> >> That sounds like a good plan, but I think we should implement the >> >> security mitigation as a second step. >> >> >> >> > The logic goes something like: >> >> > * To exploit V8 you must be running an evil PAC script. >> >> > * If you are running an evil PAC script, you are already screwed. >> >> >> >> The situation is a little more subtle than this. Here is how I think >> >> about it: >> >> >> >> Threat Model: >> >> >> >> 1) You are using the browser on an untrusted network. Likelihood: >> >> Routine (users routinely surf the Web on untrusted wireless networks, >> >> for example in coffee shops and in airports). >> >> >> >> 2) V8 has an exploitable arbitrary code execution vulnerability. >> >> Likelihood: Will occur at some point. Window of Vulnerability: One >> >> patch cycle (exploitable ACEs in V8 are P0 bugs). >> >> >> >> Designs: >> >> >> >> 1) PAC in renderer process: Universal cross-site scripting. The >> >> attacker can exploit V8, but the sandbox prevents the attacker from >> >> reading or writing your hard drive. Severity: High. >> >> >> >> 2) PAC in browser process: Arbitrary code execution. The malicious >> >> PAC script can now install malware on the user's machine. Severity: >> >> Critical. >> >> >> >> Conclusion: >> >> >> >> Running PAC scripts in the browser process elevates the severity of a >> >> reasonable chunk of attack surface (ACE in V8) from high to critical. >> >> >> >> Recommendation: >> >> >> >> Ideally, we would run the PAC script in a dedicated sandboxed process. >> >> This would prevent a compromised PAC process from doing much of >> >> anything. Short of that, we should run PAC scripts in the renderer >> >> process. >> >> >> >> > The attacker can now INTERCEPT AND MODIFY all of your HTTP traffic! >> >> >> >> This is the same as universal cross-site scripting and is a >> >> high-severity vulnerability. Being able to install malware on the >> >> user's machine is more severe (e.g., critical). >> >> >> >> > All they really need to do is substitute the next EXE you download >> >> > with the code they want to execute, and voila. >> >> >> >> This requires user interaction. Specifically, the user has to confirm >> >> the corrupted download. Moreover, this attack vector is present >> >> regardless of a vulnerability in V8 (i.e., ability 2 above) because an >> >> untrusted network can do this already (i.e., just with ability 1 >> >> above). >> >> >> >> 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: checkdeps failure when a unit test relies on v8.h
Right... I meant the particular vector of faking the proxy auto config file to achieve HTTP interception. That Windows has "auto detect proxies" enabled by default would seem to make this an easy target for hackers. -Darin On Tue, Feb 17, 2009 at 10:16 PM, Adam Barth wrote: > No one else has a sandbox for their JavaScript engine. ACE in their > JS engine is game over. > > Adam > > > On Tue, Feb 17, 2009 at 9:42 PM, Darin Fisher wrote: > > I wonder why this hasn't gotten much attention in other browsers... > > -Darin > > > > On Tue, Feb 17, 2009 at 1:42 PM, Adam Barth wrote: > >> > >> Hi Eric, > >> > >> On Tue, Feb 17, 2009 at 12:47 PM, Eric Roman > wrote: > >> > My goal is to do all the work necessary to get V8-PAC resolving > >> > working in the browser process first. > >> > >> That sounds like a good plan, but I think we should implement the > >> security mitigation as a second step. > >> > >> > The logic goes something like: > >> > * To exploit V8 you must be running an evil PAC script. > >> > * If you are running an evil PAC script, you are already screwed. > >> > >> The situation is a little more subtle than this. Here is how I think > >> about it: > >> > >> Threat Model: > >> > >> 1) You are using the browser on an untrusted network. Likelihood: > >> Routine (users routinely surf the Web on untrusted wireless networks, > >> for example in coffee shops and in airports). > >> > >> 2) V8 has an exploitable arbitrary code execution vulnerability. > >> Likelihood: Will occur at some point. Window of Vulnerability: One > >> patch cycle (exploitable ACEs in V8 are P0 bugs). > >> > >> Designs: > >> > >> 1) PAC in renderer process: Universal cross-site scripting. The > >> attacker can exploit V8, but the sandbox prevents the attacker from > >> reading or writing your hard drive. Severity: High. > >> > >> 2) PAC in browser process: Arbitrary code execution. The malicious > >> PAC script can now install malware on the user's machine. Severity: > >> Critical. > >> > >> Conclusion: > >> > >> Running PAC scripts in the browser process elevates the severity of a > >> reasonable chunk of attack surface (ACE in V8) from high to critical. > >> > >> Recommendation: > >> > >> Ideally, we would run the PAC script in a dedicated sandboxed process. > >> This would prevent a compromised PAC process from doing much of > >> anything. Short of that, we should run PAC scripts in the renderer > >> process. > >> > >> > The attacker can now INTERCEPT AND MODIFY all of your HTTP traffic! > >> > >> This is the same as universal cross-site scripting and is a > >> high-severity vulnerability. Being able to install malware on the > >> user's machine is more severe (e.g., critical). > >> > >> > All they really need to do is substitute the next EXE you download > >> > with the code they want to execute, and voila. > >> > >> This requires user interaction. Specifically, the user has to confirm > >> the corrupted download. Moreover, this attack vector is present > >> regardless of a vulnerability in V8 (i.e., ability 2 above) because an > >> untrusted network can do this already (i.e., just with ability 1 > >> above). > >> > >> 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: Is there a scroll bar?
OK, Thanks... I'll try to find the slowdown then... BYE MAD On Tue, Feb 17, 2009 at 6:48 PM, Brett Wilson wrote: > On Tue, Feb 17, 2009 at 3:43 PM, Marc-Andre Decoste > wrote: > > Salut, > >I'm looking for a way to know, at the BrowserView (or even at > > the RenderWidgetHostViewWin) level, if there is one, and only one scroll > bar > > visible. I thought I could ask Windows with ::GetScrollBarInfo, but it > > doesn't work since the scroll bars are handled by WebKit and not by > Windows. > > Scroll bars a non-native and rendered by WebKit. The browser doesn't > know anything about it. I think you will have to do this at the WebKit > level. > > Brett > --~--~-~--~~~---~--~~ 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: Qt now a possibility?
On 17 Gen, 19:45, "Ben Goodger (Google)" wrote: > +1 > > FWIW, the changes I've made in the browser over the past few months > (MagicBrowzr) should have made it possible for the front end to be > written in any number of native toolkits. Our first test is going to > be Cocoa on OS X. > > -Ben > So, different native toolkits for each platform. But while Windows has mfc and Osx uses cocoa/carbon, i wonder what is "THE" native toolkit for linux (?) Or, if you prefer, why did you choose gtk over qt (at least) on linux? It's very strange, since google earth uses qt... --~--~-~--~~~---~--~~ 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: Qt now a possibility?
On 17 Gen, 19:45, "Ben Goodger (Google)" wrote: > +1 > > FWIW, the changes I've made in the browser over the past few months > (MagicBrowzr) should have made it possible for the front end to be > written in any number of native toolkits. Our first test is going to > be Cocoa on OS X. > > -Ben So, different native toolkits for each platform. But while Windows has mfc and Osx uses cocoa/carbon, i wonder what is the 'native toolkit' for linux (?) Or, if you prefer, why did you choose gtk over qt (at least) on linux? --~--~-~--~~~---~--~~ 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: Writing tips to our build instructions?
Thank you all those who updated the build instructions. Regards, Hironori Bono E-mail: hb...@chromium.org On Wed, Feb 18, 2009 at 3:09 AM, Evan Martin wrote: > On Tue, Feb 17, 2009 at 9:37 AM, Pam Greene wrote: >> And I've updated >> http://sites.google.com/a/chromium.org/dev/developers/how-tos/get-the-code >> to make the "make sure the path has no spaces" note apply to all >> platforms rather than only Windows. (Is it true for Linux too?) > > It would surprise me if it mattered, but it also surprises me it > matters on Win/Mac. > Can't hurt, I guess. > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
