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
> 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
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
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
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
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.
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
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
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
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/
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.
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
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
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
-~--~~~~--~~--
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
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
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
--~--~-~--~
+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
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
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
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
+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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
--~--~-~--~~---
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
83 matches
Mail list logo
