[chromium-dev] Re: Make PostTask virtual?

[Jim Roskind]

+1 Darin
+1 Maruel

It was/is impressively hard to modify the message loop/pump without harming
performance, and that performance is so central, that it tends to be visible
in top level browser benchmarks.
It was very difficult to make this body of code as simple() as it is.
 ...and it is not very simple.  Please try not to add any complexity in what
is seemingly super subtle code.

Adding and calling through virtual methods may have some impact, and should
be done very cautiously.  Virtualizing existing methods, if they are
mainstream, is pretty much guaranteed to impact performance.

Adding interfaces, as proposed by Darin, would be seemingly risk free, at
least in terms of performance.

Jim

On Tue, Aug 4, 2009 at 11:04 AM, Marc-Antoine Ruel wrote:

> On Tue, Aug 4, 2009 at 2:01 PM, Albert J. Wong (王重傑) 
> wrote:
>
>>
 On Tue, Aug 4, 2009 at 6:28 AM, Marc-Antoine Ruel 
 wrote:

>
> I'm slightly against. No real reason :) except that it'll definitely
> bloat the WPO build.


>> How bad would the bloat be?
>>
>
> Please get data by building both with and without the virtual keyword in
> official/wpo (not release) build.
>
> M-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: How to disable plugin support in chromium on Mac OSX

[Stuart Morgan]

On Tue, Aug 4, 2009 at 8:37 PM, n179911 wrote:
> Can you please tell me how can I disable plugin support in my own
> chromium build on Mac OSX so that when I execute chomium in XCode
> flash plugin is not enabled?

--disable-plugins

-Stuart

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] How to disable plugin support in chromium on Mac OSX

[n179911]

Hi,

I notice the latest trunk of chromium has flash plugin support.
Can you please tell me how can I disable plugin support in my own
chromium build on Mac OSX so that when I execute chomium in XCode
flash plugin is not enabled?

Thank you.

--~--~-~--~~~---~--~~
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: Mystery error "Assertion failed: (slab->magic == SLAB_MAGIC), function slab_alloc, file x-alloc.c, line 353."

[Adam Langley]

On Tue, Aug 4, 2009 at 5:11 PM, Peter Kasting wrote:
> That is probably coming from the allocator underneath Chrome (presumably the
> one provided by the OS kernel).  It probably means you have memory
> corruption that eventually leads to this.

Yea, it does look a lot like it's from the kernel - but I don't think
it is. SLAB was the kernel's default memory allocator for a long time,
but SLAB_MAGIC isn't from the kernel sources (at least going back to
2005).


AGL

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mystery error "Assertion failed: (slab->magic == SLAB_MAGIC), function slab_alloc, file x-alloc.c, line 353."

[Peter Kasting]

On Tue, Aug 4, 2009 at 5:03 PM, Dan Kegel  wrote:

> Twice now (three days ago and today) I got the error
> Assertion failed: (slab->magic == SLAB_MAGIC), function slab_alloc,
> file x-alloc.c, line 353.
> while running the ui tests under valgrind on the mac...
> and I can't figure out where it's coming from.
> I've grepped through the chromium and valgrind sources,
> and I've googled, with no luck.
>

That is probably coming from the allocator underneath Chrome (presumably the
one provided by the OS kernel).  It probably means you have memory
corruption that eventually leads to this.

PK

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Mystery error "Assertion failed: (slab->magic == SLAB_MAGIC), function slab_alloc, file x-alloc.c, line 353."

[Dan Kegel]

Twice now (three days ago and today) I got the error
Assertion failed: (slab->magic == SLAB_MAGIC), function slab_alloc,
file x-alloc.c, line 353.
while running the ui tests under valgrind on the mac...
and I can't figure out where it's coming from.
I've grepped through the chromium and valgrind sources,
and I've googled, with no luck.

Does that message ring a bell to anyone?

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[nakro]

Ian, i have a lot of respect to you chrome devs, but i could never
figure why
you don't just punch holes in the sandbox when Flash or Java or maybe
even Reader work

these are by far the most used plugins in the world (where Flash is #1
i would think)

i do recall even reading an area of the sandbox which does this for
flash.
and i also recall one of you saying that if you do it then flash could
not be auto-updated
but you are google, i am sure you can talk to adobe and maybe run
flash on startup without the sandbox
then if it does not want to update, you kill it and force it into the
sandbox when it is needed

actually, since i know nothing about NPAPI i am prob talking BS so
thanx for checking it!
and have fun
--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Ian Fette]

So far as I can tell, the page is not instantiating Java. it's instantiating
acrobat / flash, and perhaps that instantiates java? At any rate, so far as
I can tell there's little that can be done here.

2009/8/4 nakro 

>
> Ok, but just so you know, i also checked this site again(!) with the --
> safe-plugins switch
>
> and since i had Process Explorer open with always on top, and since
> sun java's dies with this safe-plugins mode
> it would seem that it was java who triggered this mess, and since you
> do not ask for permissions to run java code
> with chrome, it is a bit creepy but ok, if you say this is kosher,
> i take your word for it
>
> >
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[nakro]

Ok, but just so you know, i also checked this site again(!) with the --
safe-plugins switch

and since i had Process Explorer open with always on top, and since
sun java's dies with this safe-plugins mode
it would seem that it was java who triggered this mess, and since you
do not ask for permissions to run java code
with chrome, it is a bit creepy but ok, if you say this is kosher,
i take your word for it

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Ian Fette]

So far as I can tell, this URL is basically exploiting reader and flash. We
don't sandbox plugins currently (see the list / blog posts for history), so
sadly this is "working as expected"

2009/8/4 nakro 

>
> hi,
>
> i sent this to your agl an hour back as he showed interest in sites
> which might break out of the sandbox
> but maybe he is not online now or something
>
> i do not want to post a link here, for obvious reasons, so if anyone
> with an @chromium mail contact me
> i will send you the link, and you better hurry before the site
> changes, it already did twice
> and it does do some "impossible" things
>
> yoav
> >
>

--~--~-~--~~~---~--~~
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: Urgent, a very evil site i think which does evil things (no joke)

[Ian Fette]

I reached out to Nakro and got the URL. I've looped in a subset of people (
secur...@chromium.org) and am looking at this now.

2009/8/4 nakro 

>
> hi,
>
> i sent this to your agl an hour back as he showed interest in sites
> which might break out of the sandbox
> but maybe he is not online now or something
>
> i do not want to post a link here, for obvious reasons, so if anyone
> with an @chromium mail contact me
> i will send you the link, and you better hurry before the site
> changes, it already did twice
> and it does do some "impossible" things
>
> yoav
> >
>

--~--~-~--~~~---~--~~
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] creating desktop shortcuts

[Antoine Labour]

On Tue, Aug 4, 2009 at 1:22 PM, Paweł Hajdan Jr. wrote:
> Yes, but even then we need to know how the launcher is named. Hardcoding
> "google-chrome" is not good for chromium builds (and we are going to have
> Chromium packaged for Gentoo). Having it "chromium" for Chromium is also not
> good, because of the conflict with Chromium (the game).

The launcher knows, from $0, right ? Could it pass it to the
executable as a command line argument or an environment variable, and
pick it up from there ?

Antoine

>
> On Tue, Aug 4, 2009 at 13:18, Evan Martin  wrote:
>>
>> E.g. this successfully starts xeyes when you click on it.
>>
>> [Desktop Entry]
>> Version=1.0
>> Encoding=UTF-8
>> Name=test.txt
>> Type=Application
>> Exec=xeyes
>> Name[en_US]=test.txt
>>
>>
>> On Tue, Aug 4, 2009 at 1:17 PM, Evan Martin wrote:
>> > Do we need a full path?  I think desktop files know to search $PATH
>> > for executables.
>> >
>> > On Tue, Aug 4, 2009 at 1:14 PM, Paweł Hajdan
>> > Jr. wrote:
>> >> There is one problem with creating desktop shortcuts on Linux: getting
>> >> correct path to the launcher script.
>> >> Gears find Firefox launcher using
>> >>
>> >> "which": http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc
>> >> Currently Chromium needs the launcher for correct library path to load
>> >> custom ffmpeg libraries.
>> >> The launcher may be at different locations on different distros.
>> >> Do you have ideas what to do? I was thinking about patching some file
>> >> for
>> >> each distro with the correct path... but it's not the most elegant
>> >> solution.
>> >> >>
>> >>
>> >
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Urgent, a very evil site i think which does evil things (no joke)

[nakro]

hi,

i sent this to your agl an hour back as he showed interest in sites
which might break out of the sandbox
but maybe he is not online now or something

i do not want to post a link here, for obvious reasons, so if anyone
with an @chromium mail contact me
i will send you the link, and you better hurry before the site
changes, it already did twice
and it does do some "impossible" things

yoav
--~--~-~--~~~---~--~~
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] creating desktop shortcuts

[Mike Mammarella]

Yeah, there's not much you can do in that case. For the default
browser setting, when there's no desktop file it just claims that it's
the default browser to avoid bothering you about it every time.
Fortunately that case should only occur with people running unpackaged
versions and not using that wrapper script. (Or for people with really
broken packages...) Perhaps the error message could suggest running it
with the wrapper for the feature to work though?

--Mike

On Tue, Aug 4, 2009 at 1:37 PM, Paweł Hajdan Jr. wrote:
> Thanks. Looks like a good solution.
> How about a case when there is no desktop file? I don't have better idea
> than displaying an error message.
>
> On Tue, Aug 4, 2009 at 13:28, Mike Mammarella  wrote:
>>
>> There should also already be a desktop file for Chrome/Chromium on the
>> system; you might consider using it as a template in order to create
>> the desktop shortcut. You can find it by searching a set of
>> directories given by the environment variables $XDG_DATA_HOME and
>> $XDG_DATA_DIRS, the former defaulting to $HOME/.local/share and the
>> latter being a colon-separated search path defaulting to
>> /usr/local/share:/usr/share. Within each directory you'd look for a
>> subdirectory named "applications" that contains desktop files. (This
>> info comes from the XDG site.)
>>
>> As for the correct name for the desktop file, check out
>> chrome/browser/shell_integration_linux.cc which has to do this to
>> figure out whether we are the default browser or not. There is a bit
>> of an issue when you're running an unpackaged version you just
>> compiled; in that case, unless you run it with "chrome-wrapper"
>> instead of just "chrome" there might not be a desktop file at all.
>> (See chrome/tools/build/linux/chrome-wrapper which is copied alongside
>> the binary when you compile.) But that's probably OK.
>>
>> --Mike
>>
>> On Tue, Aug 4, 2009 at 1:22 PM, Paweł Hajdan Jr.
>> wrote:
>> > Yes, but even then we need to know how the launcher is named. Hardcoding
>> > "google-chrome" is not good for chromium builds (and we are going to
>> > have
>> > Chromium packaged for Gentoo). Having it "chromium" for Chromium is also
>> > not
>> > good, because of the conflict with Chromium (the game).
>> >
>> > On Tue, Aug 4, 2009 at 13:18, Evan Martin  wrote:
>> >>
>> >> E.g. this successfully starts xeyes when you click on it.
>> >>
>> >> [Desktop Entry]
>> >> Version=1.0
>> >> Encoding=UTF-8
>> >> Name=test.txt
>> >> Type=Application
>> >> Exec=xeyes
>> >> Name[en_US]=test.txt
>> >>
>> >>
>> >> On Tue, Aug 4, 2009 at 1:17 PM, Evan Martin wrote:
>> >> > Do we need a full path?  I think desktop files know to search $PATH
>> >> > for executables.
>> >> >
>> >> > On Tue, Aug 4, 2009 at 1:14 PM, Paweł Hajdan
>> >> > Jr. wrote:
>> >> >> There is one problem with creating desktop shortcuts on Linux:
>> >> >> getting
>> >> >> correct path to the launcher script.
>> >> >> Gears find Firefox launcher using
>> >> >>
>> >> >>
>> >> >> "which": http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc
>> >> >> Currently Chromium needs the launcher for correct library path to
>> >> >> load
>> >> >> custom ffmpeg libraries.
>> >> >> The launcher may be at different locations on different distros.
>> >> >> Do you have ideas what to do? I was thinking about patching some
>> >> >> file
>> >> >> for
>> >> >> each distro with the correct path... but it's not the most elegant
>> >> >> solution.
>> >> >> >>
>> >> >>
>> >> >
>> >
>> >
>> > >> >
>> >
>
>

--~--~-~--~~~---~--~~
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] creating desktop shortcuts

[Paweł Hajdan Jr .]

Thanks. Looks like a good solution.
How about a case when there is no desktop file? I don't have better idea
than displaying an error message.

On Tue, Aug 4, 2009 at 13:28, Mike Mammarella  wrote:

> There should also already be a desktop file for Chrome/Chromium on the
> system; you might consider using it as a template in order to create
> the desktop shortcut. You can find it by searching a set of
> directories given by the environment variables $XDG_DATA_HOME and
> $XDG_DATA_DIRS, the former defaulting to $HOME/.local/share and the
> latter being a colon-separated search path defaulting to
> /usr/local/share:/usr/share. Within each directory you'd look for a
> subdirectory named "applications" that contains desktop files. (This
> info comes from the XDG site.)
>
> As for the correct name for the desktop file, check out
> chrome/browser/shell_integration_linux.cc which has to do this to
> figure out whether we are the default browser or not. There is a bit
> of an issue when you're running an unpackaged version you just
> compiled; in that case, unless you run it with "chrome-wrapper"
> instead of just "chrome" there might not be a desktop file at all.
> (See chrome/tools/build/linux/chrome-wrapper which is copied alongside
> the binary when you compile.) But that's probably OK.
>
> --Mike
>
> On Tue, Aug 4, 2009 at 1:22 PM, Paweł Hajdan Jr.
> wrote:
> > Yes, but even then we need to know how the launcher is named. Hardcoding
> > "google-chrome" is not good for chromium builds (and we are going to have
> > Chromium packaged for Gentoo). Having it "chromium" for Chromium is also
> not
> > good, because of the conflict with Chromium (the game).
> >
> > On Tue, Aug 4, 2009 at 13:18, Evan Martin  wrote:
> >>
> >> E.g. this successfully starts xeyes when you click on it.
> >>
> >> [Desktop Entry]
> >> Version=1.0
> >> Encoding=UTF-8
> >> Name=test.txt
> >> Type=Application
> >> Exec=xeyes
> >> Name[en_US]=test.txt
> >>
> >>
> >> On Tue, Aug 4, 2009 at 1:17 PM, Evan Martin wrote:
> >> > Do we need a full path?  I think desktop files know to search $PATH
> >> > for executables.
> >> >
> >> > On Tue, Aug 4, 2009 at 1:14 PM, Paweł Hajdan
> >> > Jr. wrote:
> >> >> There is one problem with creating desktop shortcuts on Linux:
> getting
> >> >> correct path to the launcher script.
> >> >> Gears find Firefox launcher using
> >> >>
> >> >> "which":
> http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc
> >> >> Currently Chromium needs the launcher for correct library path to
> load
> >> >> custom ffmpeg libraries.
> >> >> The launcher may be at different locations on different distros.
> >> >> Do you have ideas what to do? I was thinking about patching some file
> >> >> for
> >> >> each distro with the correct path... but it's not the most elegant
> >> >> solution.
> >> >> >>
> >> >>
> >> >
> >
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
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] creating desktop shortcuts

[Evan Martin]

Ah, yes.  I actually sorta hacked this for the manpage.  See the
"manpage" rule in chrome/chrome.gyp.
Perhaps that could be generalized at a higher level so that the
"filename" variable (which is really the binary name) is available to
you as well.  Maybe via a -D flag?  See also the discussion on
http://codereview.chromium.org/160026 where I attempted to add the -D
flag but was (rightly) shot down.

On Tue, Aug 4, 2009 at 1:22 PM, Paweł Hajdan Jr. wrote:
> Yes, but even then we need to know how the launcher is named. Hardcoding
> "google-chrome" is not good for chromium builds (and we are going to have
> Chromium packaged for Gentoo). Having it "chromium" for Chromium is also not
> good, because of the conflict with Chromium (the game).
>
> On Tue, Aug 4, 2009 at 13:18, Evan Martin  wrote:
>>
>> E.g. this successfully starts xeyes when you click on it.
>>
>> [Desktop Entry]
>> Version=1.0
>> Encoding=UTF-8
>> Name=test.txt
>> Type=Application
>> Exec=xeyes
>> Name[en_US]=test.txt
>>
>>
>> On Tue, Aug 4, 2009 at 1:17 PM, Evan Martin wrote:
>> > Do we need a full path?  I think desktop files know to search $PATH
>> > for executables.
>> >
>> > On Tue, Aug 4, 2009 at 1:14 PM, Paweł Hajdan
>> > Jr. wrote:
>> >> There is one problem with creating desktop shortcuts on Linux: getting
>> >> correct path to the launcher script.
>> >> Gears find Firefox launcher using
>> >>
>> >> "which": http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc
>> >> Currently Chromium needs the launcher for correct library path to load
>> >> custom ffmpeg libraries.
>> >> The launcher may be at different locations on different distros.
>> >> Do you have ideas what to do? I was thinking about patching some file
>> >> for
>> >> each distro with the correct path... but it's not the most elegant
>> >> solution.
>> >> >> >>
>> >>
>> >
>
>

--~--~-~--~~~---~--~~
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] creating desktop shortcuts

[Mike Mammarella]

There should also already be a desktop file for Chrome/Chromium on the
system; you might consider using it as a template in order to create
the desktop shortcut. You can find it by searching a set of
directories given by the environment variables $XDG_DATA_HOME and
$XDG_DATA_DIRS, the former defaulting to $HOME/.local/share and the
latter being a colon-separated search path defaulting to
/usr/local/share:/usr/share. Within each directory you'd look for a
subdirectory named "applications" that contains desktop files. (This
info comes from the XDG site.)

As for the correct name for the desktop file, check out
chrome/browser/shell_integration_linux.cc which has to do this to
figure out whether we are the default browser or not. There is a bit
of an issue when you're running an unpackaged version you just
compiled; in that case, unless you run it with "chrome-wrapper"
instead of just "chrome" there might not be a desktop file at all.
(See chrome/tools/build/linux/chrome-wrapper which is copied alongside
the binary when you compile.) But that's probably OK.

--Mike

On Tue, Aug 4, 2009 at 1:22 PM, Paweł Hajdan Jr. wrote:
> Yes, but even then we need to know how the launcher is named. Hardcoding
> "google-chrome" is not good for chromium builds (and we are going to have
> Chromium packaged for Gentoo). Having it "chromium" for Chromium is also not
> good, because of the conflict with Chromium (the game).
>
> On Tue, Aug 4, 2009 at 13:18, Evan Martin  wrote:
>>
>> E.g. this successfully starts xeyes when you click on it.
>>
>> [Desktop Entry]
>> Version=1.0
>> Encoding=UTF-8
>> Name=test.txt
>> Type=Application
>> Exec=xeyes
>> Name[en_US]=test.txt
>>
>>
>> On Tue, Aug 4, 2009 at 1:17 PM, Evan Martin wrote:
>> > Do we need a full path?  I think desktop files know to search $PATH
>> > for executables.
>> >
>> > On Tue, Aug 4, 2009 at 1:14 PM, Paweł Hajdan
>> > Jr. wrote:
>> >> There is one problem with creating desktop shortcuts on Linux: getting
>> >> correct path to the launcher script.
>> >> Gears find Firefox launcher using
>> >>
>> >> "which": http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc
>> >> Currently Chromium needs the launcher for correct library path to load
>> >> custom ffmpeg libraries.
>> >> The launcher may be at different locations on different distros.
>> >> Do you have ideas what to do? I was thinking about patching some file
>> >> for
>> >> each distro with the correct path... but it's not the most elegant
>> >> solution.
>> >> >>
>> >>
>> >
>
>
> >
>

--~--~-~--~~~---~--~~
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] creating desktop shortcuts

[Paweł Hajdan Jr .]

Yes, but even then we need to know how the launcher is named. Hardcoding
"google-chrome" is not good for chromium builds (and we are going to have
Chromium packaged for Gentoo). Having it "chromium" for Chromium is also not
good, because of the conflict with Chromium (the game).

On Tue, Aug 4, 2009 at 13:18, Evan Martin  wrote:

> E.g. this successfully starts xeyes when you click on it.
>
> [Desktop Entry]
> Version=1.0
> Encoding=UTF-8
> Name=test.txt
> Type=Application
> Exec=xeyes
> Name[en_US]=test.txt
>
>
> On Tue, Aug 4, 2009 at 1:17 PM, Evan Martin wrote:
> > Do we need a full path?  I think desktop files know to search $PATH
> > for executables.
> >
> > On Tue, Aug 4, 2009 at 1:14 PM, Paweł Hajdan Jr.
> wrote:
> >> There is one problem with creating desktop shortcuts on Linux: getting
> >> correct path to the launcher script.
> >> Gears find Firefox launcher using
> >> "which":
> http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc
> >> Currently Chromium needs the launcher for correct library path to load
> >> custom ffmpeg libraries.
> >> The launcher may be at different locations on different distros.
> >> Do you have ideas what to do? I was thinking about patching some file
> for
> >> each distro with the correct path... but it's not the most elegant
> solution.
> >> > >>
> >>
> >
>

--~--~-~--~~~---~--~~
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] creating desktop shortcuts

[Evan Martin]

E.g. this successfully starts xeyes when you click on it.

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=test.txt
Type=Application
Exec=xeyes
Name[en_US]=test.txt


On Tue, Aug 4, 2009 at 1:17 PM, Evan Martin wrote:
> Do we need a full path?  I think desktop files know to search $PATH
> for executables.
>
> On Tue, Aug 4, 2009 at 1:14 PM, Paweł Hajdan Jr. 
> wrote:
>> There is one problem with creating desktop shortcuts on Linux: getting
>> correct path to the launcher script.
>> Gears find Firefox launcher using
>> "which": http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc
>> Currently Chromium needs the launcher for correct library path to load
>> custom ffmpeg libraries.
>> The launcher may be at different locations on different distros.
>> Do you have ideas what to do? I was thinking about patching some file for
>> each distro with the correct path... but it's not the most elegant solution.
>> >>
>>
>

--~--~-~--~~~---~--~~
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] creating desktop shortcuts

[Evan Martin]

Do we need a full path?  I think desktop files know to search $PATH
for executables.

On Tue, Aug 4, 2009 at 1:14 PM, Paweł Hajdan Jr. wrote:
> There is one problem with creating desktop shortcuts on Linux: getting
> correct path to the launcher script.
> Gears find Firefox launcher using
> "which": http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc
> Currently Chromium needs the launcher for correct library path to load
> custom ffmpeg libraries.
> The launcher may be at different locations on different distros.
> Do you have ideas what to do? I was thinking about patching some file for
> each distro with the correct path... but it's not the most elegant solution.
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] [linux] creating desktop shortcuts

[Paweł Hajdan Jr .]

There is one problem with creating desktop shortcuts on Linux: getting
correct path to the launcher script.
Gears find Firefox launcher using "which":
http://code.google.com/p/gears/source/browse/trunk/gears/desktop/desktop_linux.cc

Currently Chromium needs the launcher for correct library path to load
custom ffmpeg libraries.

The launcher may be at different locations on different distros.

Do you have ideas what to do? I was thinking about patching some file for
each distro with the correct path... but it's not the most elegant solution.

--~--~-~--~~~---~--~~
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: code coverage and browser_tests

[John Grabowski]

No.  You can find the list of unittest files run by coverage in chrome.gyp;
look at the end of chrome.gyp for the coverage target and list of
dependencies.
I will be spending time on coverage to expand this and fix other related
problems (e.g. no win coverage builder yet).

jrg

On Mon, Aug 3, 2009 at 9:21 AM, Paweł Hajdan Jr. wrote:

> Does code coverage run browser_tests? It seems that not.
> >
>

--~--~-~--~~~---~--~~
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: Multiple outputs and errors: fail in make build

[Tony Chang]

On Tue, Aug 4, 2009 at 9:25 AM, Ben Laurie wrote:
> Of course, you are also correct, in that there's a pile of
> dependencies make doesn't see - as I think I've said before, I'm a fan
> of automatic dependency extraction, which it seems grit could easily
> be persuaded to spit out (just as gcc can).

In fact, the scons build currently does this (see
tools/grit/grit/scons.py).  It would probably be pretty easy to have
grit also generate a .d file that lists the input dependencies when
run.  Then make could depend on the .d files like it does for .cc
files.

I think this might involve some special casing in the gyp make
generator for handling gyp files.

--~--~-~--~~~---~--~~
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: Make PostTask virtual?

[Marc-Antoine Ruel]

On Tue, Aug 4, 2009 at 2:01 PM, Albert J. Wong (王重傑) wrote:

>
>>> On Tue, Aug 4, 2009 at 6:28 AM, Marc-Antoine Ruel 
>>> wrote:
>>>

 I'm slightly against. No real reason :) except that it'll definitely
 bloat the WPO build.
>>>
>>>
> How bad would the bloat be?
>

Please get data by building both with and without the virtual keyword in
official/wpo (not release) build.

M-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: Make PostTask virtual?

[王重傑]

Responding to three separate parts of the thread (too bad we aren't using
Wave :P).

On Tue, Aug 4, 2009 at 7:35 AM, Darin Fisher  wrote:

> I don't think we want a HasPendingTasks method.  Consider that the
> MessageLoop may be used by multiple threads.  Any code depending on
> HasPendingTasks is likely to be fragile.  Also, a MessageLoop may have work
> to do that is not task related.


I think adding inspection functions isn't a bad solution, assuming they're
marked for testing (eg., Making the name HasPendingTasksForTest()).

Using these functions in a multithreaded is not safe, but in unittests,
we've been using a pattern of creating a message loop, then executing
message_loop.RunAllPending() to simulate one iteration of the loop.  This
setup doesn't execute a new thread and gives us a "paused" loop that would
actually be quite suitable for inspection.

This might actually be one of the least invasive methods of allowing for a
test point to be inserted.


> On Tue, Aug 4, 2009 at 6:41 AM, Andrew Scherkus wrote:
>
>> I think it'd interesting to try.  I imagine we'd need some helper gmock
>> actions to take care of executing/deleting tasks.
>> Out of curiosity, would adding a HasPendingTasks() method solve your
>> current testing issue?
>>
>>
>> On Tue, Aug 4, 2009 at 6:28 AM, Marc-Antoine Ruel wrote:
>>
>>>
>>> I'm slightly against. No real reason :) except that it'll definitely
>>> bloat the WPO build.
>>
>>
How bad would the bloat be?

Another possible solution that avoids a virtual is to add a constructor that
takes a mock delegate for just the for functions.  Then in the message loop
code, add a shim into each API that can be intercepted.  Something like

  MessgaeLoop(PostTaskDelegate *mock_delegate)
  : mock_delegate_(mock_delegate) {
  }

  void PostTask(...) {
if (mock_delegate_) {
   mock_delegate_->PostTask();
   return;
}
// do real work.
  }

This is a bit ugly since it will take a bit of inspection to know which
methods are mockable, and the shim needs to be put into each mockable
function.  However, it has the niceness of not really disturbing the current
API structure and avoiding virtual.


>
>>> M-A
>>>
>>> On Tue, Aug 4, 2009 at 2:37 AM, Darin Fisher wrote:
>>> > MessageLoop is not designed to be subclassed.  Call me a minimalist,
>>> but I
>>> > think it damages slightly the readability of the code to have methods
>>> marked
>>> > virtual that do not need to be.  That said, I love mocking.  Since a
>>> lot of
>>> > code doesn't actually need a MessageLoop so much as a place to post
>>> tasks,
>>> > maybe it would be better to define an interface for posting tasks that
>>> > MessageLoop can implement.  Then a lot of code could be switched over
>>> to
>>> > that interface, making the code a bit more abstract.  Think of
>>> > IPC::Message::Sender as an example of this kind of abstraction.
>>>
>>

That'd work and give a pretty clear separation.  However, I also have a
couple of slight hesitations:
  (a) It adds yet another interface + complexity.  We already have
MessagePump,
   MessagePump::Delegate, MessageLoop, etc., which at least when
   starting out, can get really confusing.
  (b) It still makes the methods virtual, which has the effect of making
them
   feel subclassable (like you said), and bloating the build (like M-A
said)


Of these three choices, I'm tempted to go with the shim approach, with the
mock being passed during construction.

-Albert

>
>>> > On Mon, Aug 3, 2009 at 8:23 PM, Albert J. Wong (王重傑) <
>>> ajw...@chromium.org>
>>> > wrote:
>>> >>
>>> >> I've noticed that most public functions on MessageLoop are
>>> non-virtual.
>>> >>  How bad would it be to make PostTask, and its variants, virtual?  Are
>>> the
>>> >> perf implications or similar that would be bad?
>>> >> I'd like to be able to use gmock to mock out a message loop so I can
>>> test
>>> >> if my code knows to stop posting tasks.  However, not having the
>>> message
>>> >> loop be virtual makes this hard.
>>> >> Thanks,
>>> >> Albert
>>> >>
>>> >
>>> >
>>> > >
>>> >
>>>
>>> >>>
>>>
>>
>

--~--~-~--~~~---~--~~
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: browser/sync is moving in

[Idan Avraham]

You don't even have to export from Google Bookmarks first and then import
into Chrome. The Chrome importer ("Wrench Menu" -> "Import bookmarks &
settings...") supports importing bookmarks from the Google Toolbar which is
the same set of Google Bookmarks associated with your @gmail address. This
is certainly not as nice as a two-way sync between the two stores, but our
focus is initially on syncing bookmarks between instances of Chrome.

On Tue, Aug 4, 2009 at 10:34 AM, Bob Oliver Bigellow XLII
wrote:

>
> In theory, you can export your Google Bookmarks and import those into
> Chrome.  With this accomplished, you'd be in the "new system" which I
> presume will ultimately replace Google Bookmarks, using the Google
> Docs List as a replacement interface.
>
> In the meantime, it will mean you won't be able to keep your Google
> Toolbar (in Firefox and IE) bookmarks synced with Chrome until there
> is an add-on for those browsers to sync with this new system.
>
>
> On Aug 3, 11:07 am, "m.f"  wrote:
> > I agree on the convenience of syncing with the users' existing (if it
> > exists) Google Bookmarks data store.  I myself have been using Google
> > Bookmarks for quite some time and built up a nice inventory that I
> > would love to sync directly to.  Will this be a feature?
> >
> > On Jul 31, 5:59 pm, Caleb Eggensperger  wrote:
> >
> >
> >
> > > The doc says:
> >
> > >- Provide a web interface to access stored / synced bookmarks,
> likely via
> > >the docs.google.com doclist.
> >
> > > What about google.com/bookmarks? Shouldn't be difficult -- toolbar
> syncs to
> > > there currently.
> >
> > > On Fri, Jul 31, 2009 at 14:07, Tim Steele  wrote:
> > > > Hi!
> >
> > > > A bunch of us have been working on a feature to sync user data in
> Chromium
> > > > with a Google account.  (Surprise! :))  The great news is that we'll
> be
> > > > starting to work directly in the Chromium project this week, and let
> me tell
> > > > you, are we excited to do that!  This email discusses how we're
> planning to
> > > > get started, in detail (maybe too much detail... sorry).
> >
> > > > We have built a library that implements the client side of our sync
> > > > protocol<
> http://sites.google.com/a/chromium.org/dev/developers/design-document...>,
> > > > as well as the Google server-side infrastructure to serve Google
> Chrome
> > > > users and synchronize data to their Google Account.  Of course, all
> the code
> > > > going into Chromium is open source, and the messages between the
> client and
> > > > server use the open protobuf 
> format
> > > > and library.  Check out the sync developer page<
> http://sites.google.com/a/chromium.org/dev/developers/design-document...>
> if
> > > > you're interested in low-level goals and technical details.
> >
> > > > We will be landing this code in a few steps rather than one giant
> > > > changelist for a number of reasons.  First, this makes reviewing a
> *lot* easier;
> > > > it isn't the most straightforward code by nature, so the more fine
> grained
> > > > scrutiny the code gets, the better.  Second, we've been working in a
> > > > proprietary environment until now because of the dependency of having
> to
> > > > build the complementary Google production server environment for
> syncing.
> > > >  As such, the code uses a small number of internal libraries that we
> need to
> > > > open-source or replace, as well as libraries that would be redundant
> to what
> > > > Chromium already includes.  Removing these, and open sourcing the
> entire
> > > > sync engine, is our highest priority and we expect this to take about
> three
> > > > weeks.
> >
> > > > So how will we commit the code in pieces and not totally hose the
> build in
> > > > the process?  First, a little more background.  You may have come
> across the
> > > > CHROME_PERSONALIZATION #define when digging through Chromium source
> code.
> > > >  Right now, this is used in conjunction with a relatively small
> number of
> > > > private c++ source files to conditionally build Chromium with sync
> enabled.
> > > >  These files are in fact a glue layer between Chromium and what is
> called
> > > > the "syncapi", which is the bulk of the client library I was talking
> about
> > > > above.  On windows, syncapi is built into a DLL, and when
> > > > CHROME_PERSONALIZATION is defined this DLL gets placed alongside
> chrome.dll
> > > > for use at runtime.  Syncapi builds and runs on Linux, but not Mac
> (yet).
> >
> > > > With the initial checkin, we will leave the CHROME_PERSONALIZATION
> #define
> > > > as-is, so the sync code will not be built by default.  We'll be
> working hard
> > > > over the coming weeks to make sure the code passes all existing test
> suites
> > > > that are part of the regular buildbot cycle, and on removing the
> #define.
> > > >  After that, our hope is that we will be free of the DLL altogether
> and have
> > > > all the code checked in to the repository, fully func

[chromium-dev] Re: browser/sync is moving in

[Bob Oliver Bigellow XLII]

In theory, you can export your Google Bookmarks and import those into
Chrome.  With this accomplished, you'd be in the "new system" which I
presume will ultimately replace Google Bookmarks, using the Google
Docs List as a replacement interface.

In the meantime, it will mean you won't be able to keep your Google
Toolbar (in Firefox and IE) bookmarks synced with Chrome until there
is an add-on for those browsers to sync with this new system.


On Aug 3, 11:07 am, "m.f"  wrote:
> I agree on the convenience of syncing with the users' existing (if it
> exists) Google Bookmarks data store.  I myself have been using Google
> Bookmarks for quite some time and built up a nice inventory that I
> would love to sync directly to.  Will this be a feature?
>
> On Jul 31, 5:59 pm, Caleb Eggensperger  wrote:
>
>
>
> > The doc says:
>
> >    - Provide a web interface to access stored / synced bookmarks, likely via
> >    the docs.google.com doclist.
>
> > What about google.com/bookmarks? Shouldn't be difficult -- toolbar syncs to
> > there currently.
>
> > On Fri, Jul 31, 2009 at 14:07, Tim Steele  wrote:
> > > Hi!
>
> > > A bunch of us have been working on a feature to sync user data in Chromium
> > > with a Google account.  (Surprise! :))  The great news is that we'll be
> > > starting to work directly in the Chromium project this week, and let me 
> > > tell
> > > you, are we excited to do that!  This email discusses how we're planning 
> > > to
> > > get started, in detail (maybe too much detail... sorry).
>
> > > We have built a library that implements the client side of our sync
> > > protocol,
> > > as well as the Google server-side infrastructure to serve Google Chrome
> > > users and synchronize data to their Google Account.  Of course, all the 
> > > code
> > > going into Chromium is open source, and the messages between the client 
> > > and
> > > server use the open protobuf  format
> > > and library.  Check out the sync developer 
> > > page
> > >  if
> > > you're interested in low-level goals and technical details.
>
> > > We will be landing this code in a few steps rather than one giant
> > > changelist for a number of reasons.  First, this makes reviewing a *lot* 
> > > easier;
> > > it isn't the most straightforward code by nature, so the more fine grained
> > > scrutiny the code gets, the better.  Second, we've been working in a
> > > proprietary environment until now because of the dependency of having to
> > > build the complementary Google production server environment for syncing.
> > >  As such, the code uses a small number of internal libraries that we need 
> > > to
> > > open-source or replace, as well as libraries that would be redundant to 
> > > what
> > > Chromium already includes.  Removing these, and open sourcing the entire
> > > sync engine, is our highest priority and we expect this to take about 
> > > three
> > > weeks.
>
> > > So how will we commit the code in pieces and not totally hose the build in
> > > the process?  First, a little more background.  You may have come across 
> > > the
> > > CHROME_PERSONALIZATION #define when digging through Chromium source code.
> > >  Right now, this is used in conjunction with a relatively small number of
> > > private c++ source files to conditionally build Chromium with sync 
> > > enabled.
> > >  These files are in fact a glue layer between Chromium and what is called
> > > the "syncapi", which is the bulk of the client library I was talking about
> > > above.  On windows, syncapi is built into a DLL, and when
> > > CHROME_PERSONALIZATION is defined this DLL gets placed alongside 
> > > chrome.dll
> > > for use at runtime.  Syncapi builds and runs on Linux, but not Mac (yet).
>
> > > With the initial checkin, we will leave the CHROME_PERSONALIZATION #define
> > > as-is, so the sync code will not be built by default.  We'll be working 
> > > hard
> > > over the coming weeks to make sure the code passes all existing test 
> > > suites
> > > that are part of the regular buildbot cycle, and on removing the #define.
> > >  After that, our hope is that we will be free of the DLL altogether and 
> > > have
> > > all the code checked in to the repository, fully functional or not, in a 
> > > few
> > > weeks.  We do *not* plan on ever checking in the windows-only syncapi dll
> > > to the main chromium repository.  So until the dll is no longer needed, 
> > > the
> > > public repository won't have all the bits to actually build Chromium with
> > > sync enabled.  That said, we want to keep the sync build running smoothly,
> > > so we will use a combination of command-line flag (to enable sync) and
> > > delay-loading syncapi.dll only when it is needed.  This will allow the
> > > "glue" code to compile as part of the normal Chromium build without
> > > introducing a depend

Re: generated files in the tree (was Re: [chromium-dev] Fwd: Make workers functional on OSX and Linux.)

[Dan Kegel]

On Tue, Aug 4, 2009 at 10:18 AM, Dirk Pranke wrote:
> On Tue, Aug 4, 2009 at 10:10 AM, Darin Fisher wrote:
>> I think we need to make it possible for the buildbots to run in a mode where
>> there are absolutely no generated files output into the source directory.
>
> Insofar as I've had a couple of checkins break builds because of this,
> I support the idea of "fixing" this, but I'm not sure that moving
> generated project files of the source tree is the way to go. What
> problem are you really trying to solve?

Darin and I already made arguments for out-of-tree builds two weeks ago
in the thread "Generating files in source tree considered harmful"
two weeks ago.  To summarize:
- darin and I both like it because we're used to doing it that way
from previous projects
- cross-compilation often requires different generated files for
different targets,
  may as well put them in the output directory (not that we're going to support
  cross-compilation any time soon)
I think what it comes down to is: whoever wants to solve
the problems we're hitting should just go ahead and draft
a solution, people will probably live with whichever solution
works.
- Dan

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

generated files in the tree (was Re: [chromium-dev] Fwd: Make workers functional on OSX and Linux.)

[Dirk Pranke]

On Tue, Aug 4, 2009 at 10:10 AM, Darin Fisher wrote:
> I think we need to make it possible for the buildbots to run in a mode where
> there are absolutely no generated files output into the source directory.
> How can we make this happen?
> (I understand that some users like having files output to the source
> directory, so that's why I said this only has to be a mode usable by the
> buildbots.)

Insofar as I've had a couple of checkins break builds because of this,
I support the idea of "fixing" this, but I'm not sure that moving
generated project files of the source tree is the way to go. What
problem are you really trying to solve? Not having the files show up
in "svn status"? Or making sure that files actually get deleted? Maybe
we need a more selective "make clean" command instead?

More importantly, I would really prefer it if we just had one way of
doing things, rather than multiple configurable ways. All of these
options make the build and test systems hard to understand and harder
to debug, and I've broken the build more times because of this than I
have because of generated files ;)

-- Dirk

--~--~-~--~~~---~--~~
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: Fwd: Make workers functional on OSX and Linux.

[Evan Martin]

We had a thread about this earlier:
  
http://groups.google.com/group/chromium-dev/browse_thread/thread/5d7e84515fc03218

I believe the make build will work* the same regardless of where the
build files are generated, since it canonicalizes all paths used to be
relative to the source root anyway.  It should be a one-liner tweak to
the generator to put the files in a parallel tree.

* for the value of "work" that it currently has, which is to say
screwing up 1/10 times

On Tue, Aug 4, 2009 at 10:10 AM, Darin Fisher wrote:
> I think we need to make it possible for the buildbots to run in a mode where
> there are absolutely no generated files output into the source directory.
> How can we make this happen?
> (I understand that some users like having files output to the source
> directory, so that's why I said this only has to be a mode usable by the
> buildbots.)
> -Darin
>
> -- Forwarded message --
> From: 
> Date: Tue, Aug 4, 2009 at 9:59 AM
> Subject: Re: Make workers functional on OSX and Linux.
> To: le...@chromium.org, j...@chromium.org
> Cc: chromium-revi...@googlegroups.com, da...@chromium.org,
> bre...@chromium.org, b...@chromium.org
>
>
> On 2009/07/13 23:30:22, John Abd-El-Malek wrote:
>>
>> lgtm
>
> YOU FORGOT TO SVN:IGNORE THE GENERATED PROJECT FILES. (I'll do because
> you're not alone)
>
> http://codereview.chromium.org/155015
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Fwd: Make workers functional on OSX and Linux.

[Darin Fisher]

I think we need to make it possible for the buildbots to run in a mode where
there are absolutely no generated files output into the source directory.
How can we make this happen?

(I understand that some users like having files output to the source
directory, so that's why I said this only has to be a mode usable by the
buildbots.)

-Darin


-- Forwarded message --
From: 
Date: Tue, Aug 4, 2009 at 9:59 AM
Subject: Re: Make workers functional on OSX and Linux.
To: le...@chromium.org, j...@chromium.org
Cc: chromium-revi...@googlegroups.com, da...@chromium.org,
bre...@chromium.org, b...@chromium.org


On 2009/07/13 23:30:22, John Abd-El-Malek wrote:

> lgtm
>

YOU FORGOT TO SVN:IGNORE THE GENERATED PROJECT FILES. (I'll do because
you're not alone)

http://codereview.chromium.org/155015

--~--~-~--~~~---~--~~
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: Testing HTML5 Video tag in chromium

[Evan Martin]

I don't think fta reads this list, so you might need to ask him directly.

On Tue, Aug 4, 2009 at 9:28 AM, Jerome Leclanche wrote:
> Are the chromium linux PPA debs video-enabled? tinyvid just gives me blank
> spaces instead of a video.
> Cheers
> --
> J. Leclanche / Adys
>
>
> On Tue, Aug 4, 2009 at 4:55 AM, Albert J. Wong (王重傑) 
> wrote:
>>
>> This has come up a bunch, so I think it warrants a post.
>> If you're playing with the HTML5 video tag in a chromium build (ie. Daily
>> builds, or your own builds from source), the only video codec enabled is
>> Ogg/Vorbis.  Thus, http://www.youtube.com/html5 isn't going to work.  Please
>> try a ogg/vorbis site instead such as http://tinyvid.tv instead to test.
>> This is true for all platforms.
>> -Albert
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Testing HTML5 Video tag in chromium

[Jerome Leclanche]

Are the chromium linux PPA debs video-enabled? tinyvid just gives me blank
spaces instead of a video.
Cheers

--
J. Leclanche / Adys


On Tue, Aug 4, 2009 at 4:55 AM, Albert J. Wong (王重傑) wrote:

> This has come up a bunch, so I think it warrants a post.
> If you're playing with the HTML5 video tag in a chromium build (ie. Daily
> builds, or your own builds from source), the only video codec enabled is
> Ogg/Vorbis.  Thus, http://www.youtube.com/html5 isn't going to work.
>  Please try a ogg/vorbis site instead such as http://tinyvid.tv instead to
> test.
>
> This is true for all platforms.
>
> -Albert
>
> >
>

--~--~-~--~~~---~--~~
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: browser/sync is moving in

[m.f]

I agree on the convenience of syncing with the users' existing (if it
exists) Google Bookmarks data store.  I myself have been using Google
Bookmarks for quite some time and built up a nice inventory that I
would love to sync directly to.  Will this be a feature?

On Jul 31, 5:59 pm, Caleb Eggensperger  wrote:
> The doc says:
>
>    - Provide a web interface to access stored / synced bookmarks, likely via
>    the docs.google.com doclist.
>
> What about google.com/bookmarks? Shouldn't be difficult -- toolbar syncs to
> there currently.
>
>
>
>
>
> On Fri, Jul 31, 2009 at 14:07, Tim Steele  wrote:
> > Hi!
>
> > A bunch of us have been working on a feature to sync user data in Chromium
> > with a Google account.  (Surprise! :))  The great news is that we'll be
> > starting to work directly in the Chromium project this week, and let me tell
> > you, are we excited to do that!  This email discusses how we're planning to
> > get started, in detail (maybe too much detail... sorry).
>
> > We have built a library that implements the client side of our sync
> > protocol,
> > as well as the Google server-side infrastructure to serve Google Chrome
> > users and synchronize data to their Google Account.  Of course, all the code
> > going into Chromium is open source, and the messages between the client and
> > server use the open protobuf  format
> > and library.  Check out the sync developer 
> > page
> >  if
> > you're interested in low-level goals and technical details.
>
> > We will be landing this code in a few steps rather than one giant
> > changelist for a number of reasons.  First, this makes reviewing a *lot* 
> > easier;
> > it isn't the most straightforward code by nature, so the more fine grained
> > scrutiny the code gets, the better.  Second, we've been working in a
> > proprietary environment until now because of the dependency of having to
> > build the complementary Google production server environment for syncing.
> >  As such, the code uses a small number of internal libraries that we need to
> > open-source or replace, as well as libraries that would be redundant to what
> > Chromium already includes.  Removing these, and open sourcing the entire
> > sync engine, is our highest priority and we expect this to take about three
> > weeks.
>
> > So how will we commit the code in pieces and not totally hose the build in
> > the process?  First, a little more background.  You may have come across the
> > CHROME_PERSONALIZATION #define when digging through Chromium source code.
> >  Right now, this is used in conjunction with a relatively small number of
> > private c++ source files to conditionally build Chromium with sync enabled.
> >  These files are in fact a glue layer between Chromium and what is called
> > the "syncapi", which is the bulk of the client library I was talking about
> > above.  On windows, syncapi is built into a DLL, and when
> > CHROME_PERSONALIZATION is defined this DLL gets placed alongside chrome.dll
> > for use at runtime.  Syncapi builds and runs on Linux, but not Mac (yet).
>
> > With the initial checkin, we will leave the CHROME_PERSONALIZATION #define
> > as-is, so the sync code will not be built by default.  We'll be working hard
> > over the coming weeks to make sure the code passes all existing test suites
> > that are part of the regular buildbot cycle, and on removing the #define.
> >  After that, our hope is that we will be free of the DLL altogether and have
> > all the code checked in to the repository, fully functional or not, in a few
> > weeks.  We do *not* plan on ever checking in the windows-only syncapi dll
> > to the main chromium repository.  So until the dll is no longer needed, the
> > public repository won't have all the bits to actually build Chromium with
> > sync enabled.  That said, we want to keep the sync build running smoothly,
> > so we will use a combination of command-line flag (to enable sync) and
> > delay-loading syncapi.dll only when it is needed.  This will allow the
> > "glue" code to compile as part of the normal Chromium build without
> > introducing a dependency on this dll, yet still make it possible to run with
> > the dll present.
>
> > On that note, we're planning to use the syncapi DLL to produce a
> > sync-enabled Google Chrome build for dev-channel users in a week or so, to
> > get the feature into experimentally inclined hands.  We have a great deal of
> > infrastructure, both in the browser and in the form of production Google
> > services, that need to start seeing real user traffic and usage.  It takes a
> > great deal of testing and confidence inspired by real usage statistics
> > before any complex system like this can be deemed adequate for use by a
> > large user base.  So if we want to let all Google Chrome users use sync (and
> > we do! w

[chromium-dev] Re: browser/sync is moving in

[corporateuser]

Looks great, Thank you, I wrote about this enhancement needed:
g) A bookmarks/applications/Chat floating tab WITHIN the browser,
Sharing ANY webpage with all my Contacts etc : Just like facebook
provides a useful toolbar at the bottom of browser page containing
list of applications/bookmarks/Contacts with whom one can chat, etc, a
browser floating tab is needed, which would be available at all web
pages that I visit. That way, I can share any webpage with all my
Contacts etc too. Or if one goes to www.playlist.com and logs in, you
will see a Meebo.com toolbar at bottom of screen, that shows ALL my
contacts from yahoo, msn, gmail, facebook, etc whom I can chat with
and share the webpage with. This toolbar should be available at all
web  pages that I visit.

>From my blog  
>http://people20.blogspot.com/2007/10/wrote-to-gmail-yahoomail-hotmail-to.html
, http://docs.google.com/Doc?id=dthcr25_155gbfdnd


Besides others:
Chome Browser/Google Toolbar enhancements needed:
I love Chrome browser, some more enhancements will help:
a) Ability to create browser toolbar components, like "Search on
Wikipedia", "Stock symbol for Google Finance" for quick opening up of
websites, so I do not have to open up a new window and then type in my
specific search query.
b) Password Autofill and automatic login into a website: Avant Browser
(www.avantbrowser.com) has nice capability of creating password
autofills and logging into website for you. Google Chrome and other
browsers should also have this. Also there should be an option that
some passwords are stored only locally, and some can be stored on the
Internet (ie available from any computer, upon login).
c) I would like ability to annotate text on a webpage, kind of a
google notes, on webpages. For example, If a webpage has a list of
videos or lectures and I want to note down next to the videos which
ones I have watched so as to not watch them again, then I should be
able to annotate text notes on the webpage. Currently, I have to open
up separate google notes etc, which is cumbersome. Then, also I should
have ability to delete my notes (either some or all of them).
d) Bookmarklets (for quickly sending gmail, or quick post to Blogger,
or quick post to Facebook, note in Google Reader, etc) are critical
and should be key feature of any browser. Chrome and other browsers
should provide a big and growing list of bookmarklets, that users can
drag into their bookmarklets list. These are  huge productivity gain.
Also it should provide capability for users to be able to create their
own bookmarklets for automating various things.
e) Bookmarklets directory : There should be a directory in google
chrome for bookmarklets (similar to directory of igoogle gadgets, that
users can pick from), since bookmarklets (for quickly sending gmail,
or quick post to Blogger, or quick post to Facebook, note in Google
Reader, etc) are critical.
f) Google Chrome auto-suggest not working for some sites: For example,
I want to start typing "rea..." and Google Chrome auto-suggest should
show my previously used "http://www.google.com/reader";, ie Google
Reader. But typing "rea..." does not auto-suggest this site.
g) A bookmarks/applications/Chat floating tab WITHIN the browser,
Sharing ANY webpage with all my Contacts etc : Just like facebook
provides a useful toolbar at the bottom of browser page containing
list of applications/bookmarks/Contacts with whom one can chat, etc, a
browser floating tab is needed, which would be available at all web
pages that I visit. That way, I can share any webpage with all my
Contacts etc too. Or if one goes to www.playlist.com and logs in, you
will see a Meebo.com toolbar at bottom of screen, that shows ALL my
contacts from yahoo, msn, gmail, facebook, etc whom I can chat with
and share the webpage with. This toolbar should be available at all
web  pages that I visit.

>From my blog  
>http://people20.blogspot.com/2007/10/wrote-to-gmail-yahoomail-hotmail-to.html
, http://docs.google.com/Doc?id=dthcr25_155gbfdnd

--~--~-~--~~~---~--~~
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: browser/sync is moving in

[Jason]

On Jul 31, 5:07 pm, Tim Steele  wrote:
> A bunch of us have been working on a feature to sync user data in Chromium
> with a Google account.  (Surprise! :))  The great news is that we'll be
> starting to work directly in the Chromium project this week, and let me tell
> you, are we excited to do that!  This email discusses how we're planning to
> get started, in detail (maybe too much detail... sorry).

Fantastic idea.  I love the notion of using XMPP for this.  Now I just
hope that this doesn't go the way of Google Browser Sync.  That was an
insanely useful service that got taken out back and shot, causing me
to relocate my sync'd bookmarks, etc. to Foxmarks, now Xmarks.

Along with this (ideally) should be a FF plugin, and possibly a SIMBL
plugin to use with Safari & the kids as well..

--~--~-~--~~~---~--~~
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: Multiple outputs and errors: fail in make build

[Ben Laurie]

On Tue, Aug 4, 2009 at 5:11 PM, Evan Martin wrote:
> On Tue, Aug 4, 2009 at 9:02 AM, Ben Laurie wrote:
>>> There's a big comment block about five lines below where you made that
>>> modification talking about how to express multiple outputs to make,
>>> along with a link to a discussion of the problem in the make manual.
>>
>> I know. That's where I got this fix from - it's one of the suggestions
>> in the manual :-)
>>
>> What you currently do didn't seem to quite map to their suggestions, though.
>
> Ah, yes, now that I reread it I see you are correct.
>
>>> Really, the problem is that you do not have all the dependencies in
>>> front of make.  The problem you're having is that files A and B
>>
>> Well, no ... it should retry building B because it hasn't been built
>> yet. And, it should try whether I supply D.png or not. Which it does,
>> with my patch.
>
> And again, I am wrong here and you are correct.  Thank you for your
> patience in explaining.  :)

Of course, you are also correct, in that there's a pile of
dependencies make doesn't see - as I think I've said before, I'm a fan
of automatic dependency extraction, which it seems grit could easily
be persuaded to spit out (just as gcc can).

> Let me think about your change some more.

--~--~-~--~~~---~--~~
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: Multiple outputs and errors: fail in make build

[Evan Martin]

On Tue, Aug 4, 2009 at 9:02 AM, Ben Laurie wrote:
>> There's a big comment block about five lines below where you made that
>> modification talking about how to express multiple outputs to make,
>> along with a link to a discussion of the problem in the make manual.
>
> I know. That's where I got this fix from - it's one of the suggestions
> in the manual :-)
>
> What you currently do didn't seem to quite map to their suggestions, though.

Ah, yes, now that I reread it I see you are correct.

>> Really, the problem is that you do not have all the dependencies in
>> front of make.  The problem you're having is that files A and B
>
> Well, no ... it should retry building B because it hasn't been built
> yet. And, it should try whether I supply D.png or not. Which it does,
> with my patch.

And again, I am wrong here and you are correct.  Thank you for your
patience in explaining.  :)

Let me think about your change some more.

--~--~-~--~~~---~--~~
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: Multiple outputs and errors: fail in make build

[Ben Laurie]

On Tue, Aug 4, 2009 at 4:52 PM, Evan Martin wrote:
> [retry with proper email address, please respond to this one if you
> got the other one]
>
> On Tue, Aug 4, 2009 at 8:11 AM, Ben Laurie wrote:
>> If you have a rule that produces multiple outputs, for example, the
>> one for src/chrome/app/theme/theme_resources.grd, the make build
>> currently works incorrectly if an error is encountered after the first
>> output is produced - subsequent makes do not try to rebuild the
>> outputs (e.g. try introducing a reference to a file that does not
>> exist in theme_resources.grd).
>>
>> I tried fixing it like this:
>>
>> Index: src/tools/gyp/pylib/gyp/generator/make.py
>> ===
>> --- src/tools/gyp/pylib/gyp/generator/make.py   (revision 568)
>> +++ src/tools/gyp/pylib/gyp/generator/make.py   (working copy)
>> @@ -685,7 +685,7 @@
>>         force_append = ' FORCE_DO_CMD'
>>       else:
>>         force_append = ' | FORCE_DO_CMD'
>> -    self.WriteLn('%s: %s%s%s' % (outputs[0], order_insert, ' '.join(inputs),
>> +    self.WriteLn('%s: %s%s%s' % (' '.join(outputs), order_insert, '
>> '.join(inputs),
>>                                  force_append))
>>     if actions:
>>       for action in actions:
>>
>> But this seems to cause other things to rebuild, too, so ... not sure
>> if this is the way to go. Before I delve deeper, anyone got a better
>> idea?
>
> There's a big comment block about five lines below where you made that
> modification talking about how to express multiple outputs to make,
> along with a link to a discussion of the problem in the make manual.

I know. That's where I got this fix from - it's one of the suggestions
in the manual :-)

What you currently do didn't seem to quite map to their suggestions, though.

> As for other ideas... hrm.  I guess we could go with yet another stampfile?
>
> Really, the problem is that you do not have all the dependencies in
> front of make.  The problem you're having is that files A and B
> conceptually depend on foobar.grd and C.png, while at the gyp level
> they just depend on foobar.grd.
> Now you modify foobar.grd to add a dependency on D.png.  We rebuild
> because foobar.grd was modified, then fail between A and B due to the
> missing D.png.  When you finally provide D.png, there is no new
> information in the dependency graph -- from make's perspective,
> there's no need to retry building A and B because the error you had
> last time should still exist now.

Well, no ... it should retry building B because it hasn't been built
yet. And, it should try whether I supply D.png or not. Which it does,
with my patch.

But, other things break :-(

>  You could just "touch foobar.grd" to work around it.

Indeed, that's what I've been doing.

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Multiple outputs and errors: fail in make build

[Ben Laurie]

If you have a rule that produces multiple outputs, for example, the
one for src/chrome/app/theme/theme_resources.grd, the make build
currently works incorrectly if an error is encountered after the first
output is produced - subsequent makes do not try to rebuild the
outputs (e.g. try introducing a reference to a file that does not
exist in theme_resources.grd).

I tried fixing it like this:

Index: src/tools/gyp/pylib/gyp/generator/make.py
===
--- src/tools/gyp/pylib/gyp/generator/make.py   (revision 568)
+++ src/tools/gyp/pylib/gyp/generator/make.py   (working copy)
@@ -685,7 +685,7 @@
 force_append = ' FORCE_DO_CMD'
   else:
 force_append = ' | FORCE_DO_CMD'
-self.WriteLn('%s: %s%s%s' % (outputs[0], order_insert, ' '.join(inputs),
+self.WriteLn('%s: %s%s%s' % (' '.join(outputs), order_insert, '
'.join(inputs),
  force_append))
 if actions:
   for action in actions:

But this seems to cause other things to rebuild, too, so ... not sure
if this is the way to go. Before I delve deeper, anyone got a better
idea?

--~--~-~--~~~---~--~~
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: Make PostTask virtual?

[Darin Fisher]

I don't think we want a HasPendingTasks method.  Consider that the
MessageLoop may be used by multiple threads.  Any code depending on
HasPendingTasks is likely to be fragile.  Also, a MessageLoop may have work
to do that is not task related.
-Darin


On Tue, Aug 4, 2009 at 6:41 AM, Andrew Scherkus wrote:

> I think it'd interesting to try.  I imagine we'd need some helper gmock
> actions to take care of executing/deleting tasks.
> Out of curiosity, would adding a HasPendingTasks() method solve your
> current testing issue?
>
>
> On Tue, Aug 4, 2009 at 6:28 AM, Marc-Antoine Ruel wrote:
>
>>
>> I'm slightly against. No real reason :) except that it'll definitely
>> bloat the WPO build.
>>
>> M-A
>>
>> On Tue, Aug 4, 2009 at 2:37 AM, Darin Fisher wrote:
>> > MessageLoop is not designed to be subclassed.  Call me a minimalist, but
>> I
>> > think it damages slightly the readability of the code to have methods
>> marked
>> > virtual that do not need to be.  That said, I love mocking.  Since a lot
>> of
>> > code doesn't actually need a MessageLoop so much as a place to post
>> tasks,
>> > maybe it would be better to define an interface for posting tasks that
>> > MessageLoop can implement.  Then a lot of code could be switched over to
>> > that interface, making the code a bit more abstract.  Think of
>> > IPC::Message::Sender as an example of this kind of abstraction.
>> > -Darin
>> >
>> >
>> > On Mon, Aug 3, 2009 at 8:23 PM, Albert J. Wong (王重傑) <
>> ajw...@chromium.org>
>> > wrote:
>> >>
>> >> I've noticed that most public functions on MessageLoop are non-virtual.
>> >>  How bad would it be to make PostTask, and its variants, virtual?  Are
>> the
>> >> perf implications or similar that would be bad?
>> >> I'd like to be able to use gmock to mock out a message loop so I can
>> test
>> >> if my code knows to stop posting tasks.  However, not having the
>> message
>> >> loop be virtual makes this hard.
>> >> Thanks,
>> >> Albert
>> >>
>> >
>> >
>> > >
>> >
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Make PostTask virtual?

[Andrew Scherkus]

I think it'd interesting to try.  I imagine we'd need some helper gmock
actions to take care of executing/deleting tasks.
Out of curiosity, would adding a HasPendingTasks() method solve your current
testing issue?

On Tue, Aug 4, 2009 at 6:28 AM, Marc-Antoine Ruel wrote:

>
> I'm slightly against. No real reason :) except that it'll definitely
> bloat the WPO build.
>
> M-A
>
> On Tue, Aug 4, 2009 at 2:37 AM, Darin Fisher wrote:
> > MessageLoop is not designed to be subclassed.  Call me a minimalist, but
> I
> > think it damages slightly the readability of the code to have methods
> marked
> > virtual that do not need to be.  That said, I love mocking.  Since a lot
> of
> > code doesn't actually need a MessageLoop so much as a place to post
> tasks,
> > maybe it would be better to define an interface for posting tasks that
> > MessageLoop can implement.  Then a lot of code could be switched over to
> > that interface, making the code a bit more abstract.  Think of
> > IPC::Message::Sender as an example of this kind of abstraction.
> > -Darin
> >
> >
> > On Mon, Aug 3, 2009 at 8:23 PM, Albert J. Wong (王重傑) <
> ajw...@chromium.org>
> > wrote:
> >>
> >> I've noticed that most public functions on MessageLoop are non-virtual.
> >>  How bad would it be to make PostTask, and its variants, virtual?  Are
> the
> >> perf implications or similar that would be bad?
> >> I'd like to be able to use gmock to mock out a message loop so I can
> test
> >> if my code knows to stop posting tasks.  However, not having the message
> >> loop be virtual makes this hard.
> >> Thanks,
> >> Albert
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: Make PostTask virtual?

[Marc-Antoine Ruel]

I'm slightly against. No real reason :) except that it'll definitely
bloat the WPO build.

M-A

On Tue, Aug 4, 2009 at 2:37 AM, Darin Fisher wrote:
> MessageLoop is not designed to be subclassed.  Call me a minimalist, but I
> think it damages slightly the readability of the code to have methods marked
> virtual that do not need to be.  That said, I love mocking.  Since a lot of
> code doesn't actually need a MessageLoop so much as a place to post tasks,
> maybe it would be better to define an interface for posting tasks that
> MessageLoop can implement.  Then a lot of code could be switched over to
> that interface, making the code a bit more abstract.  Think of
> IPC::Message::Sender as an example of this kind of abstraction.
> -Darin
>
>
> On Mon, Aug 3, 2009 at 8:23 PM, Albert J. Wong (王重傑) 
> wrote:
>>
>> I've noticed that most public functions on MessageLoop are non-virtual.
>>  How bad would it be to make PostTask, and its variants, virtual?  Are the
>> perf implications or similar that would be bad?
>> I'd like to be able to use gmock to mock out a message loop so I can test
>> if my code knows to stop posting tasks.  However, not having the message
>> loop be virtual makes this hard.
>> Thanks,
>> Albert
>>
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---