There's actually a lot of useful things in this email for someone to learn
if they're seeking to become a more regular contributor.
On Thu, Apr 30, 2009 at 10:29 PM, Mohamed Mansour
m0.interact...@gmail.comwrote:
I usually browse the issue tracker for HelpWanted tags, and try to solve
those
On Apr 30, 10:16 pm, Mohamed Mansour m0.interact...@gmail.com 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
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
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
On Fri, May 1, 2009 at 1:02 AM, Peter Kasting pkast...@chromium.org 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
humour
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!
/humour
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
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
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
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 mar...@chromium.org wrote:
svn lock?
On Fri, May 1, 2009 at 11:35 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
We are very, very close to total unforking. In order
svn lock?
On Fri, May 1, 2009 at 11:35 AM, Dimitri Glazkov dglaz...@chromium.org 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
On Fri, May 1, 2009 at 8:36 AM, Marc-Andre Decoste m...@chromium.org 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
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
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
Perhaps WebViewDelegate::WindowObjectCleared works?
-Darin
On Fri, May 1, 2009 at 9:10 AM, Marshall Greenblatt
magreenbl...@gmail.comwrote:
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
On Fri, May 1, 2009 at 9:06 AM, Marc-Andre Decoste m...@chromium.org 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
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
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
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
Patch is available for review here: http://codereview.chromium.org/99283
Thanks,
Marshall
On Fri, May 1, 2009 at 12:38 PM, Aaron Boodman a...@chromium.org wrote:
Not the right time. WindowObjectCleared() gets called as the frame is
coming up and the DOM window is getting setup.
We needed
On Fri, May 1, 2009 at 10:19 AM, Aaron Boodman a...@chromium.org 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
On Fri, May 1, 2009 at 10:19 AM, Aaron Boodman a...@chromium.org 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
On Fri, May 1, 2009 at 2:06 AM, Peter Kasting pkast...@chromium.org 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
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
Thanks for the replies!
On Fri, May 1, 2009 at 10:42 AM, Adam Barth aba...@chromium.org 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 erik...@chromium.org wrote:
There
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
On Fri, May 1, 2009 at 11:17 AM, Aaron Boodman a...@chromium.org 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.
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
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
On Fri, May 1, 2009 at 11:36 AM, cpu c...@chromium.org 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
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 e...@chromium.org wrote:
We have a bunch of
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 (王重傑)
ajw...@chromium.org wrote:
Is there a place that actually describes when it's appropriate to use which
string
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
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*
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 a...@chromium.org wrote:
On POSIX systems, system calls can be interrupted by signals. In this case,
they'll return
On Fri, May 1, 2009 at 11:01 AM, Jason A. Spiro jasonspi...@gmail.comwrote:
On Fri, May 1, 2009 at 2:06 AM, Peter Kasting pkast...@chromium.org
wrote:
IRC is absolutely the wrong
method for support. Encouraging that makes everything worse.
Why is it a bad method for support?
Because
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.
#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 jasonspi...@gmail.com wrote:
On Fri, May 1, 2009 at 2:06 AM, Peter Kasting
On Fri, May 1, 2009 at 12:35 PM, Adam Langley a...@chromium.org 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
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 dglaz...@chromium.orgwrote:
We are very, very close to
On Fri, May 1, 2009 at 1:07 PM, Adam Barth aba...@chromium.org 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
On Fri, May 1, 2009 at 12:53 PM, Jeremy Orlow jor...@google.com 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:
templatetypename T
T handle_eintr(T a) {
..
}
On Fri, May 1, 2009 at 1:13 PM, Elliot Glaysher (Chromium)
e...@chromium.org 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 1:23 PM, Mike Belshe mbel...@google.com 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
On Fri, May 1, 2009 at 1:27 PM, Adam Langley a...@chromium.org wrote:
On Fri, May 1, 2009 at 12:53 PM, Jeremy Orlow jor...@google.com 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
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 a...@chromium.org wrote:
On Fri, May 1, 2009 at
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
On Fri, May 1, 2009 at 1:30 PM, Adam Langley a...@chromium.org wrote:
On Fri, May 1, 2009 at 1:23 PM, Mike Belshe mbel...@google.com 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,
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
On Fri, May 1, 2009 at 1:31 PM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, May 1, 2009 at 1:27 PM, Adam Langley a...@chromium.org wrote:
On Fri, May 1, 2009 at 12:53 PM, Jeremy Orlow jor...@google.com wrote:
I'm still kind of new here, so forgive me if this is a silly question,
but
On Apr 30, 3:26 pm, Evan Martin e...@chromium.org wrote:
On Thu, Apr 30, 2009 at 3:13 PM, Peter Kasting pkast...@chromium.org wrote:
On Thu, Apr 30, 2009 at 1:50 PM, cpu c...@chromium.org wrote:
Inhttp://src.chromium.org/viewvc/chrome?view=revrevision=14983I
removed a
+100!!
Awesome!!!
On Fri, May 1, 2009 at 2:42 PM, Scott Hess sh...@chromium.org wrote:
HEROIC!
On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov dglaz...@chromium.org
wrote:
Hello all,
This is kind of a momentous occasion. For the first time -- ever, our
WebKit Canary bot (the one
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
On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
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
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
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,
+1 to the blog entry
On Fri, May 1, 2009 at 2:44 PM, Evan Martin e...@chromium.org 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 dglaz...@chromium.org
wrote:
Hello all,
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 j...@chromium.org wrote:
Does this also
include third_party\WebKit\WebKit\chromium\public\WebKitClient.h? I'm
guessing not, since none of
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
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 dglaz...@chromium.orgwrote:
Hello all,
This is kind of a momentous
HEROIC!
On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov dglaz...@chromium.org 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:
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 dglaz...@chromium.org wrote:
Hello all,
This is kind of a momentous occasion. For the first time -- ever, our
WebKit Canary bot (the one
2009/5/1 Evan Martin e...@chromium.org
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
On Sat, May 2, 2009 at 6:09 AM, Evan Martin e...@chromium.org 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
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...
A wstring is a C++ wrapper around a wchar_t string.
What Mike was proposing was changing to char*.
2009/5/1 Mohamed Mansour m0.interact...@gmail.com:
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
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 e...@chromium.org
A wstring is a C++ wrapper
2009/5/1 Mohamed Mansour m0.interact...@gmail.com:
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
67 matches
Mail list logo
