[chromium-dev] Re: Setting Default Search Engine

2009-05-01 Thread stylo~
Also, the name it defaults to for the added search engine is wrong. It uses the url, not the name in the xml file. > Also, doesn't seem a very good system even if it does work. How do you > actually find/select the search engine you want to use? Yahoo is > installed; I haven't a clue how to selec

[chromium-dev] Re: Setting Default Search Engine

2009-05-01 Thread stylo~
> Here's some reasons why it might fail: > . You already have a search engine forhttp://url.com/. Thanks, that was it, sort of. It wasn't really a search engine, it was a bookmark with a %s keyword imported from Firefox with the same base URL. When deleted, it works. Need some error feedback ad

[chromium-dev] Re: Why are pref keys wchar_t's?

2009-05-01 Thread Brett Wilson
2009/5/1 Mohamed Mansour : > Why wouldn't we just use std::string ? Many places in the code uses > std::string. DictionaryValue needs to be converted as well as many others. > So what do we finally decide, go what Pink stated and use char* or use > std::string. I believe the reason is that you pa

[chromium-dev] Re: Why are pref keys wchar_t's?

2009-05-01 Thread Mohamed Mansour
Why wouldn't we just use std::string ? Many places in the code uses std::string. DictionaryValue needs to be converted as well as many others. So what do we finally decide, go what Pink stated and use char* or use std::string. 2009/5/1 Evan Martin > A wstring is a C++ wrapper around a wchar_t s

[chromium-dev] Re: Why are pref keys wchar_t's?

2009-05-01 Thread Evan Martin
A wstring is a C++ wrapper around a wchar_t string. What Mike was proposing was changing to char*. 2009/5/1 Mohamed Mansour : > Hi, I have done a small patch that converts the pref's to use wstring > instead of wchar_t (everywhere in the code). It is just a few places. The > code compiles. But I

[chromium-dev] Re: Why are pref keys wchar_t's?

2009-05-01 Thread 王重傑
I don't actually know why that didn't work...maybe some sort of weird initialization order thing? If the kPrefsToObserve was initialized before kWebKitJavaEnabled was then it'd likely read it as an empty string? Don't really know. I couldn't get it to reproduce on a smaller test case using gcc.

[chromium-dev] Re: Why are pref keys wchar_t's?

2009-05-01 Thread Mohamed Mansour
Hi, I have done a small patch that converts the pref's to use wstring instead of wchar_t (everywhere in the code). It is just a few places. The code compiles. But I would like to get some advice on why some errors occur. I don't know who would like to CR this... http://codereview.chromium.org/10029

[chromium-dev] Re: [BUG][PATCH] Small issue with "page_action.h"

2009-05-01 Thread Lei Zhang
I created http://codereview.chromium.org/99309 for you. Thanks. On Fri, May 1, 2009 at 4:25 PM, LivioSoares wrote: > >  Dear Chromium folks, > >  I was building revision 15114 this afternoon and was snagged by > this: > > cc1plus: warnings being treated as errors > In file included from /home/li

[chromium-dev] Re: unforking: 20% perf hit for international page cycler expected soon

2009-05-01 Thread Brett Wilson
On Sat, May 2, 2009 at 6:09 AM, Evan Martin wrote: > > The suggestions on that code review are good: we ought to measure how > many fonts normal users see, and then pick the cache tuning parameter > accordingly. > > Adam Barth is a good person to ask about how to do this, since he > seems to be m

[chromium-dev] [BUG][PATCH] Small issue with "page_action.h"

2009-05-01 Thread LivioSoares
Dear Chromium folks, I was building revision 15114 this afternoon and was snagged by this: cc1plus: warnings being treated as errors In file included from /home/livio/src/chrome/chromium/src/chrome/ browser/extensions/extension.h:19, from /home/livio/src/chrome/chromium/src/

[chromium-dev] Re: unforking: 20% perf hit for international page cycler expected soon

2009-05-01 Thread 신정식, 申政湜
2009/5/1 Evan Martin > > The suggestions on that code review are good: we ought to measure how > many fonts normal users see, and then pick the cache tuning parameter > accordingly. > > Adam Barth is a good person to ask about how to do this, since he > seems to be measuring all sorts of things.

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread David Levin
On Fri, May 1, 2009 at 3:38 PM, John Abd-El-Malek wrote: > This is definitely awesome! > Too bad, I was just about to sign up to do the next n merges ;) > Dimitri, it sounds like John wants to be a webkit build sheriff :) (the evolution of the merger roll). > > > On Fri, May 1, 2009 at 2:38 P

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread John Abd-El-Malek
This is definitely awesome! Too bad, I was just about to sign up to do the next n merges ;) On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote: > > Hello all, > > This is kind of a momentous occasion. For the first time -- ever, our > WebKit Canary bot (the one that pulls directly from WebKit

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread Aaron Boodman
Amazing! Congrats Dimitri :) - 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: unforking: 20% perf hit for international page cycler expected soon

2009-05-01 Thread Evan Martin
The suggestions on that code review are good: we ought to measure how many fonts normal users see, and then pick the cache tuning parameter accordingly. Adam Barth is a good person to ask about how to do this, since he seems to be measuring all sorts of things. On Fri, May 1, 2009 at 3:07 PM, Da

[chromium-dev] unforking: 20% perf hit for international page cycler expected soon

2009-05-01 Thread David Levin
One of the few remaining forks is in WebCore/platform/graphics/FontCache.cpp (https://bugs.webkit.org/show_bug.cgi?id=21451). I'll be checking in a change to remove this fork and as such we should expect ~20% perf hit for the international page cycler. The internatonal page cycler test intentiona

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread Peter Kasting
On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote: > What does this mean? This means that our unforking efforts have > finally paid off -- we can now pull directly from WebKit upstream! Nice! Please do write something for the Chromium blog! We need posts there. PK --~--~-~--~

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread Jeremy Orlow
+1 to the blog entry On Fri, May 1, 2009 at 2:44 PM, Evan Martin wrote: > > Truly momentous. You should post the the Chromium blog about it (and > why it's meaningful). > Great work! > > On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov > wrote: > > > > Hello all, > > > > This is kind of a momen

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread Avi Drissman
Whoo!!! Partay! Avi On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote: > > Hello all, > > This is kind of a momentous occasion. For the first time -- ever, our > WebKit Canary bot (the one that pulls directly from WebKit upstream) > has built successfully and was able to run tests: > > > ht

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread Mike Belshe
What day would this momentous occasion have occurred if Dimitri hadn't joined Google on Monday August 4, 2008? * * *Thanks for bailing us out, DG!* * * *:-)* * * *Mike* On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote: > > Hello all, > > This is kind of a momentous occasion. For the first ti

[chromium-dev] Unforking: Canary Bot Lives!

2009-05-01 Thread Dimitri Glazkov
Hello all, This is kind of a momentous occasion. For the first time -- ever, our WebKit Canary bot (the one that pulls directly from WebKit upstream) has built successfully and was able to run tests: http://build.chromium.org/buildbot/waterfall.fyi/builders/Webkit%20(webkit.org)/builds/2937 Wha

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread Jeremy Moskovich
+100!! Awesome!!! On Fri, May 1, 2009 at 2:42 PM, Scott Hess wrote: > > HEROIC! > > On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov > wrote: > > > > Hello all, > > > > This is kind of a momentous occasion. For the first time -- ever, our > > WebKit Canary bot (the one that pulls directly from W

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread Evan Martin
Truly momentous. You should post the the Chromium blog about it (and why it's meaningful). Great work! On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote: > > Hello all, > > This is kind of a momentous occasion. For the first time -- ever, our > WebKit Canary bot (the one that pulls directly

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread David Levin
Awesome! This is a really cool. On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote: > > Hello all, > > This is kind of a momentous occasion. For the first time -- ever, our > WebKit Canary bot (the one that pulls directly from WebKit upstream) > has built successfully and was able to run test

[chromium-dev] Re: Unforking: Canary Bot Lives!

2009-05-01 Thread Scott Hess
HEROIC! On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote: > > Hello all, > > This is kind of a momentous occasion. For the first time -- ever, our > WebKit Canary bot (the one that pulls directly from WebKit upstream) > has built successfully and was able to run tests: > > http://build.chro

[chromium-dev] Re: No more commits to third_party/WebKit

2009-05-01 Thread Dimitri Glazkov
Right. Changes to WebKit/WebKit/chromium are still allowed, because this is not yet upstream. :DG< On Fri, May 1, 2009 at 1:11 PM, John Abd-El-Malek wrote: > Does this also > include  third_party\WebKit\WebKit\chromium\public\WebKitClient.h?  I'm > guessing not, since none of those files are in

[chromium-dev] Re: CoInitialize gone from the renderer

2009-05-01 Thread cpu
On Apr 30, 3:26 pm, Evan Martin wrote: > On Thu, Apr 30, 2009 at 3:13 PM, Peter Kasting wrote: > > On Thu, Apr 30, 2009 at 1:50 PM, cpu wrote: > > >> Inhttp://src.chromium.org/viewvc/chrome?view=rev&revision=14983I > >> removed a CoInitialize()/CoUnInitialize() pair in the renderer process >

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread 王重傑
On Fri, May 1, 2009 at 1:31 PM, Jeremy Orlow wrote: > On Fri, May 1, 2009 at 1:27 PM, Adam Langley wrote: > >> On Fri, May 1, 2009 at 12:53 PM, Jeremy Orlow wrote: >> > I'm still kind of new here, so forgive me if this is a silly question, >> but >> > why do this with a define and not an templa

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Marc-Antoine Ruel
What about NewRunnableFunction() in task.h? Slightly overkill because of heap usage and parameter copy but it is quite strict. It also requires writing the call in a different and less obvious way, which may counter the benefit. M-A On Fri, May 1, 2009 at 4:39 PM, Adam Langley wrote: > > On Fr

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Mike Belshe
On Fri, May 1, 2009 at 1:30 PM, Adam Langley wrote: > On Fri, May 1, 2009 at 1:23 PM, Mike Belshe wrote: > > It's been a while since I dealt with unix signals; but in the work I did, > > the common trick was to disable signals on all threads except one. Then, > > you only have to deal with hand

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Adam Langley
On Fri, May 1, 2009 at 1:32 PM, Adam Barth wrote: > There's also a problem if you write something like: > > HANDLE_EINTR(close(PromptUserForFileDescriptor())); > > Macros suck. > > What about something like base::close that's inline and knows how to loop? Yea, the macro will trigger multiple eva

[chromium-dev] depot_tools is moving!

2009-05-01 Thread Marc-Antoine Ruel
gcl, gclient and friends are moving from http://src.chromium.org/svn/trunk/depot_tools/ to http://src.chromium.org/svn/trunk/tools/depot_tools/ To help you with the switch, there is now a little script to switch automatically. Just run ** *convert_depot_tools* to convert the depot_tools to the

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Adam Barth
There's also a problem if you write something like: HANDLE_EINTR(close(PromptUserForFileDescriptor())); Macros suck. What about something like base::close that's inline and knows how to loop? Adam On Fri, May 1, 2009 at 1:27 PM, Adam Langley wrote: > On Fri, May 1, 2009 at 1:13 PM, Elliot G

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Jeremy Orlow
On Fri, May 1, 2009 at 1:27 PM, Adam Langley wrote: > On Fri, May 1, 2009 at 12:53 PM, Jeremy Orlow wrote: > > I'm still kind of new here, so forgive me if this is a silly question, > but > > why do this with a define and not an template function? > > One could imagine a template function: > > t

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Adam Langley
On Fri, May 1, 2009 at 1:23 PM, Mike Belshe wrote: > It's been a while since I dealt with unix signals; but in the work I did, > the common trick was to disable signals on all threads except one.  Then, > you only have to deal with handling signals there.  Otherwise, you've pretty > much always g

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Adam Langley
On Fri, May 1, 2009 at 1:13 PM, Elliot Glaysher (Chromium) wrote: > Yes. Regretfully, C doesn't have hygienic macros. It probably would be > a good idea to change "ret" to a name less likely to conflict... Yep, good point. It's now __eintr_result__. Cheers AGL --~--~-~--~~---

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Adam Langley
On Fri, May 1, 2009 at 12:53 PM, Jeremy Orlow wrote: > I'm still kind of new here, so forgive me if this is a silly question, but > why do this with a define and not an template function? One could imagine a template function: template T handle_eintr(T &a) { .. } But when using it as: hand

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Mike Belshe
It's been a while since I dealt with unix signals; but in the work I did, the common trick was to disable signals on all threads except one. Then, you only have to deal with handling signals there. Otherwise, you've pretty much always got trouble because you never know which threads will service

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Elliot Glaysher (Chromium)
On Fri, May 1, 2009 at 1:07 PM, Adam Barth wrote: > Wow, that's pretty deep magic. > >> And you can use it like: >>  HANDLE_EINTR(close(fd)); > > Isn't it disaster if you say: > > HANDLE_EINTR(close(ret)); Yes. Regretfully, C doesn't have hygienic macros. It probably would be a good idea to chan

[chromium-dev] Re: No more commits to third_party/WebKit

2009-05-01 Thread John Abd-El-Malek
Does this also include third_party\WebKit\WebKit\chromium\public\WebKitClient.h? I'm guessing not, since none of those files are in the WebKit repository yet, but just want to double check. On Fri, May 1, 2009 at 8:35 AM, Dimitri Glazkov wrote: > > We are very, very close to total unforking. In

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Adam Barth
On Fri, May 1, 2009 at 12:35 PM, Adam Langley wrote: > On POSIX, it uses GCC magic to return the correct type based on the expression > and restarts the system call if it throws EINTR. Here it is: > > #define HANDLE_EINTR(x) ({ \ >  typeof(x) ret; \ >  do { \ >    ret = x; \ >  } while (ret == -1

[chromium-dev] Re: Discussion to take over #chrome on irc

2009-05-01 Thread Ben Goodger (Google)
#chromium is a channel for Chromium project contributors, not a support channel. We will not be making any changes to direct users there for support. -Ben On Fri, May 1, 2009 at 11:01 AM, Jason A. Spiro wrote: > > On Fri, May 1, 2009 at 2:06 AM, Peter Kasting wrote: > > ... >> IRC is absolutel

[chromium-dev] Re: Why are pref keys wchar_t's?

2009-05-01 Thread Andrew Scherkus
I once went on a mission to change Value to use UTF-8 strings, and hilariously enough after doing a few of those changes we ended up with string16. Maybe I'll go on another crusade to change Value to use string16... Anyway, the tricky part is that it's the Dictionary Value type forcing wstring. I

[chromium-dev] Re: Discussion to take over #chrome on irc

2009-05-01 Thread Peter Kasting
On Fri, May 1, 2009 at 11:01 AM, Jason A. Spiro wrote: > On Fri, May 1, 2009 at 2:06 AM, Peter Kasting > wrote: > > IRC is absolutely the wrong > > method for support. Encouraging that makes everything worse. > > Why is it a bad method for support? Because it's roughly one-to-one. We want som

[chromium-dev] Re: POSIX: EINTR correctness

2009-05-01 Thread Jeremy Orlow
I'm still kind of new here, so forgive me if this is a silly question, but why do this with a define and not an template function? On Fri, May 1, 2009 at 12:35 PM, Adam Langley wrote: > > On POSIX systems, system calls can be interrupted by signals. In this case, > they'll return EINTR, indicati

[chromium-dev] Re: Why are pref keys wchar_t's?

2009-05-01 Thread Tony Chang
The history is that the Value type, which is the underlying data type used by PrefService used to only have wstring types. This bled into PrefService which caused PrefService to only understand wstring as keys. I'd be happy to see a patch that changed PrefService keys to std::string or char* whi

[chromium-dev] POSIX: EINTR correctness

2009-05-01 Thread Adam Langley
On POSIX systems, system calls can be interrupted by signals. In this case, they'll return EINTR, indicating that the system call needs to be restarted. (The situation is a little more complicated than this with SA_RESTART, but you can read man 7 signal if you like.) The short of it is that you

[chromium-dev] Re: Why are pref keys wchar_t's?

2009-05-01 Thread Mike Pinkerton
Well, in this case they're not user-visible, so there's no reason for them to not be char*s. Unless I'm missing something obvious. On Fri, May 1, 2009 at 3:02 PM, Albert J. Wong (王重傑) wrote: > Is there a place that actually describes when it's appropriate to use which > string type, and how to k

[chromium-dev] Re: Why are pref keys wchar_t's?

2009-05-01 Thread 王重傑
Is there a place that actually describes when it's appropriate to use which string type, and how to know if we should be "fixing" code we run across? Is everything just supposed to be string16? -Albert On Fri, May 1, 2009 at 11:59 AM, Evan Martin wrote: > > We have a bunch of places where wch

[chromium-dev] Re: Why are pref keys wchar_t's?

2009-05-01 Thread Evan Martin
We have a bunch of places where wchar_ts still exist, and none of them are correct. I think this isn't particular instance isn't likely to b *that* much waste but it definitely would be nice to fix. I fixed command line switch names to be ASCII on the train into work once just 'cause it was both

[chromium-dev] Re: Unpacking Extensions and the Sandbox

2009-05-01 Thread Aaron Boodman
On Fri, May 1, 2009 at 11:36 AM, cpu wrote: > > Utility process is an amenable idea. We do something like that for > first-run import as well. > > Key items, I can think of: > > 1- Utility process would not display UI (would it?) > 2- We can allow a directory to be available for read/write > 3- U

[chromium-dev] Re: Unpacking Extensions and the Sandbox

2009-05-01 Thread Jeremy Orlow
On Fri, May 1, 2009 at 11:36 AM, cpu wrote: > > Utility process is an amenable idea. We do something like that for > first-run import as well. > > Key items, I can think of: > > 1- Utility process would not display UI (would it?) > 2- We can allow a directory to be available for read/write > 3- U

[chromium-dev] Why are pref keys wchar_t's?

2009-05-01 Thread Mike Pinkerton
Why are our internal pref keys all wchar_t strings? That's pretty wasteful for something the user never sees and doesn't need to be localized. It's really wasteful on Mac and Linux (32bit wchar_t). Is this on anyone's radar to fix? Should I file a bug? -- Mike Pinkerton Mac Weenie pinker...@goo

[chromium-dev] Re: Unpacking Extensions and the Sandbox

2009-05-01 Thread cpu
Utility process is an amenable idea. We do something like that for first-run import as well. Key items, I can think of: 1- Utility process would not display UI (would it?) 2- We can allow a directory to be available for read/write 3- Use IPC for progress / heartbeat In other words pretty much a

[chromium-dev] Re: Unpacking Extensions and the Sandbox

2009-05-01 Thread Scott Hess
On Fri, May 1, 2009 at 11:17 AM, Aaron Boodman wrote: > We can use DuplicateHandle() to get the input file handle in, but I am > not sure what to do about getting the directory sturcture out. Crazy-talk: Have the renderer unpack the zip into a SQLite database. Architecture-astronaut-talk: Have

[chromium-dev] Performance impact due to unforking ResourceResponse.h

2009-05-01 Thread Dimitri Glazkov
Team, As part of the global WebKit unforking, I will be rolling out shortly the change to ResourceResponse.h that we put in a while back: http://codereview.chromium.org/29007 We have now completed the investigation and there's no need for this fork anymore. As a result, you will see a memory/s

[chromium-dev] Re: Unpacking Extensions and the Sandbox

2009-05-01 Thread Aaron Boodman
Thanks for the replies! On Fri, May 1, 2009 at 10:42 AM, Adam Barth wrote: > I think we should go with the utility process. We've seen several > examples where this would be a useful concept to have. On Fri, May 1, 2009 at 10:48 AM, Erik Kay wrote: > There have been other cases people have br

[chromium-dev] Re: Unpacking Extensions and the Sandbox

2009-05-01 Thread Finnur Thorarinsson
> The issue with images is with themes, since they're displayed by the browser process. The issue with images is also an issue with PageActions, where we want to display icons (handed to us by an extension) inside the Omnibox. --~--~-~--~~~---~--~~ Chromium Develope

[chromium-dev] Re: Discussion to take over #chrome on irc

2009-05-01 Thread Jason A. Spiro
On Fri, May 1, 2009 at 2:06 AM, Peter Kasting wrote: ... > IRC is absolutely the wrong > method for support. Encouraging that makes everything worse. Why is it a bad method for support? > Some people will do things wrong. The number of people who are doing things > wrong by joining the wrong

[chromium-dev] Re: Unpacking Extensions and the Sandbox

2009-05-01 Thread Ojan Vafai
An advantage of the utility process is that it's not tied to the lifetime of the tab, so we don't have to deal with edge cases like when the user closes a tab that's mid-installing an extension. Ojan On Fri, May 1, 2009 at 10:42 AM, Adam Barth wrote: > > I think we should go with the utility pro

[chromium-dev] Re: Unpacking Extensions and the Sandbox

2009-05-01 Thread Erik Kay
On Fri, May 1, 2009 at 10:19 AM, Aaron Boodman wrote: > > Right now, we are unpacking extensions in the browser process. This > basically consists of unzipping the package into a directory structure > and parsing a JSON manifest. > > Both of these things feel like things we should not be doing in

[chromium-dev] Re: Unpacking Extensions and the Sandbox

2009-05-01 Thread Nicolas Sylvain
On Fri, May 1, 2009 at 10:19 AM, Aaron Boodman wrote: > > Right now, we are unpacking extensions in the browser process. This > basically consists of unzipping the package into a directory structure > and parsing a JSON manifest. > > Both of these things feel like things we should not be doing in

[chromium-dev] Re: Unpacking Extensions and the Sandbox

2009-05-01 Thread Adam Barth
I think we should go with the utility process. We've seen several examples where this would be a useful concept to have. As for the zip libraries, I seem to recall that we can marshal file handles into sandboxed processes, but I'm not an expert on this. Adam On Fri, May 1, 2009 at 10:19 AM, A

[chromium-dev] Re: Notification when a WebFrame is destroyed

2009-05-01 Thread Marshall Greenblatt
Patch is available for review here: http://codereview.chromium.org/99283 Thanks, Marshall On Fri, May 1, 2009 at 12:38 PM, Aaron Boodman wrote: > Not the right time. WindowObjectCleared() gets called as the frame is > coming up and the DOM window is getting setup. > > We needed something like

[chromium-dev] Re: No more commits to third_party/WebKit

2009-05-01 Thread Ojan Vafai
This should still work fine. One person can lock the whole directory, then people who need to commit unforkage can lock the specific files they need to unfork using --force. That said, the only forkage that happens these days is when doing a webkit merge. What should the merger do if they find them

[chromium-dev] Re: Setting Default Search Engine

2009-05-01 Thread Scott Violet
Do you have a working page you can point me at so that I can definitively tell you why your script isn't working? Here's some reasons why it might fail: . You already have a search engine for http://url.com/. . The name assigned to the keyword is already in use and the user has modified the exist

[chromium-dev] Unpacking Extensions and the Sandbox

2009-05-01 Thread Aaron Boodman
Right now, we are unpacking extensions in the browser process. This basically consists of unzipping the package into a directory structure and parsing a JSON manifest. Both of these things feel like things we should not be doing in the browser. Additionally, extensions can contains PNG images tha

[chromium-dev] Re: Need help in finding a performance problem...

2009-05-01 Thread Adam Langley
On Fri, May 1, 2009 at 9:06 AM, Marc-Andre Decoste wrote: > Salut Evan, >   thanks, I will do that... And the results seems better than I initially > thought... If you get performance improvements, please do commit :) Evan is correct that Darin needs to check this over, but I'll happy code revi

[chromium-dev] Re: Notification when a WebFrame is destroyed

2009-05-01 Thread Aaron Boodman
Not the right time. WindowObjectCleared() gets called as the frame is coming up and the DOM window is getting setup. We needed something like this for extensions, but we ended up just putting our code in WebFrameImpl instead of adding an interface to the delegate. - a On Fri, May 1, 2009 at 9:2

[chromium-dev] Re: Notification when a WebFrame is destroyed

2009-05-01 Thread Darin Fisher
Perhaps WebViewDelegate::WindowObjectCleared works? -Darin On Fri, May 1, 2009 at 9:10 AM, Marshall Greenblatt wrote: > Hi All, > > Is there currently a way to be notified when a WebFrame instance is about > to be destroyed? > > The Chromium Embedded Framework needs this notification to properl

[chromium-dev] Notification when a WebFrame is destroyed

2009-05-01 Thread Marshall Greenblatt
Hi All, Is there currently a way to be notified when a WebFrame instance is about to be destroyed? The Chromium Embedded Framework needs this notification to properly clean up memory associated with specific WebFrame instances (for example, custom NPObject types bound to the WebFrame via BindToWi

[chromium-dev] Re: Need help in finding a performance problem...

2009-05-01 Thread Marc-Andre Decoste
Salut Evan, thanks, I will do that... And the results seems better than I initially thought... Now I need a better way to validate the results, because I think the high level evaluation I did previously was misleading... Looking at the data a little closer, I seem to have reached a much bette

[chromium-dev] Re: Need help in finding a performance problem...

2009-05-01 Thread Evan Martin
On Fri, May 1, 2009 at 8:36 AM, Marc-Andre Decoste wrote: >    So these don't seem to be THE reason for this slow down... So I keep > digging... But I wonder if it would be worth it or not to commit these > changes anyway, since they do provide a small performance improvement (at > least in the s

[chromium-dev] Re: No more commits to third_party/WebKit

2009-05-01 Thread Marc-Antoine Ruel
svn lock? On Fri, May 1, 2009 at 11:35 AM, Dimitri Glazkov wrote: > > We are very, very close to total unforking. In order to facilitate the > completion of this process, please refrain from landing any changes in > trunk/deps/third_party/WebKit. This holds true even if your patch is > already a

[chromium-dev] Re: No more commits to third_party/WebKit

2009-05-01 Thread Dimitri Glazkov
Not yet. There's a small bunch of people still landing unforkages. :DG< On Fri, May 1, 2009 at 8:40 AM, Marc-Antoine Ruel wrote: > svn lock? > > On Fri, May 1, 2009 at 11:35 AM, Dimitri Glazkov > wrote: >> >> We are very, very close to total unforking. In order to facilitate the >> completion

[chromium-dev] Re: Need help in finding a performance problem...

2009-05-01 Thread Marc-Andre Decoste
Salut again, I got a bit further, but not quite there yet... The (0, 0, 17, 17) invalidation request came from the fact that WebKit invalidates the scroll bars when their enabled state is set, and it was done "before" the frame rect of the scroll bar is set... So I fixed that (by simply reve

[chromium-dev] No more commits to third_party/WebKit

2009-05-01 Thread Dimitri Glazkov
We are very, very close to total unforking. In order to facilitate the completion of this process, please refrain from landing any changes in trunk/deps/third_party/WebKit. This holds true even if your patch is already approved upstream. So, to put it simply: NO MOAR THIRD_PARTY/WEBKIT COMMEETS.

[chromium-dev] Re: Discussion to take over #chrome on irc

2009-05-01 Thread Mike Pinkerton
I think part of Peter's point is that we *don't want* people looking for support in #chromium. It's a developer channel. Our "ad-hoc" filtering to keep support-seekers out seems to be working fine. I have no desire to change that. On Fri, May 1, 2009 at 1:41 AM, Jason A. Spiro wrote: > We don't

[chromium-dev] Re: Chrome closes the window without warning

2009-05-01 Thread Marc-Antoine Ruel
I'd suggest to stop using a mouse and only use the shortcut keys: alt-tab, ctrl-tab, ctrl-f4. Never ever use alt-f4! Feature requests like this are best sent to chromium-discuss@ unless you actually want to implement it. But instead, please star this feature request; you'll save everyone's time

[chromium-dev] Re: Discussion to take over #chrome on irc

2009-05-01 Thread Jason A. Spiro
On Fri, May 1, 2009 at 1:02 AM, Peter Kasting wrote: ... > And since there seems little benefit in registering > #chrome just to redirect it to #chromium I don't see why we'd do this. > Frankly anyone able to get on IRC is able to find the right place for > support. ... Some people don't even kn

[chromium-dev] Nomination for chromium account?

2009-05-01 Thread Shinichiro Hamaji
Hi, I'm Shinichiro, working on chromium recently, and fixing chromium bugs to learn the code base of chromium. As I finished 13 patches (http://dev.chromium.org/getting-involved/become-a-committer says that 10-20 patches are required), I'm sending this email to be a committer or a provisional com

[chromium-dev] Chrome closes the window without warning

2009-05-01 Thread Amitabh
Hi, I am not sure this is the right forum, but I think its a bug. If there are multiple tabs open and you hit the window close button, it does not warn and closes the window. Cannot call it a feature as there are tabs where I would be working actively and may hit the close button accidently or call

[chromium-dev] Re: Setting Default Search Engine

2009-05-01 Thread stylo~
On Apr 30, 10:16 pm, Mohamed Mansour wrote: > Chromium doesn't support "window.external.AddSearchProvider" , it supports > the OpenSearch specification. Except that IS the OpenSearch specification: "Aside from using autodiscovery links, both IE7 and Firefox 2 can be pointed to your OpenSearc