[chromium-dev] Re: Clobbering

[Jeremy Orlow]

They were both WebKit deps rolls.  The latter one was caused by an .idl file
that changed.
The former, I don't know off the top of my head.  Here's the chromium
review: http://codereview.chromium.org/165278  Here are the files that
changed: http://trac.webkit.org/changeset?new=47...@trunk&old=46...@trunk
Here's the error visual studio gave:

DerivedSourcesAllInOne.cpp
C:\b\slave\win\build\src\chrome\Debug\obj\webcore\bindings/V8Document.cpp(1003)
: error C2039: 'v8ElementEventHandlerAccessorGetter' : is not a member
of 'WebCore::V8Custom'

C:\b\slave\win\build\src\third_party\WebKit\WebCore\bindings\v8\custom\V8CustomBinding.h(94)
: see declaration of 'WebCore::V8Custom'





On Mon, Aug 10, 2009 at 11:17 PM, Bradley Nelson wrote:

> We currently have a hack of sorts in mind (well an issue filed on gyp) that
> would cover a larger class of settings changes (the worst handled by vstudio
> directly). The idea is to have gyp generate a text file full of settings
> garp which would be an additional dependency of each project.
> There are of course other dependency flaws (sgk is working on a long
> running validation build that would look for missing links in the chain)
> that are just due to mistakes in the gyp files.
>
> I would be curious which kind of dependency issue these latest ones were
> (can someone point me at the CLs?, been on nacl/o3d buildbot stuff of late).
>
> -BradN
>
>  On Mon, Aug 10, 2009 at 11:00 PM, Jeremy Orlow wrote:
>
>>  On Mon, Aug 10, 2009 at 10:45 PM, Aaron Boodman  wrote:
>>
>>> Such a system does not help when people sync your change. We should
>>> invest the effort we would expend building this system fixing the
>>> dependency issues.
>>
>>
>> gclient could be made to obey it as well.  But I agree, it's a hack.
>>
>>
>>> Barring that, we have a hack that we do where for resource files we
>>> make a whitespace change to the corresponding .gyp. We could automate
>>> this by having a presubmit check that enforces this.
>>
>>
>> Better than nothing.
>>
>> We also have the hack for grd files that deletes all the associated .h
>> files.  Something like that might work here as well.
>>
>> How hard would it be to make the system actually understand the
>> dependencies?  Is visual studio really just too dumb to understand?
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Clobbering

[Bradley Nelson]

We currently have a hack of sorts in mind (well an issue filed on gyp) that
would cover a larger class of settings changes (the worst handled by vstudio
directly). The idea is to have gyp generate a text file full of settings
garp which would be an additional dependency of each project.
There are of course other dependency flaws (sgk is working on a long running
validation build that would look for missing links in the chain) that are
just due to mistakes in the gyp files.

I would be curious which kind of dependency issue these latest ones were
(can someone point me at the CLs?, been on nacl/o3d buildbot stuff of late).

-BradN

On Mon, Aug 10, 2009 at 11:00 PM, Jeremy Orlow  wrote:

> On Mon, Aug 10, 2009 at 10:45 PM, Aaron Boodman  wrote:
>
>> Such a system does not help when people sync your change. We should
>> invest the effort we would expend building this system fixing the
>> dependency issues.
>
>
> gclient could be made to obey it as well.  But I agree, it's a hack.
>
>
>> Barring that, we have a hack that we do where for resource files we
>> make a whitespace change to the corresponding .gyp. We could automate
>> this by having a presubmit check that enforces this.
>
>
> Better than nothing.
>
> We also have the hack for grd files that deletes all the associated .h
> files.  Something like that might work here as well.
>
> How hard would it be to make the system actually understand the
> dependencies?  Is visual studio really just too dumb to understand?
>
> >
>

--~--~-~--~~~---~--~~
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: Clobbering

[Jeremy Orlow]

On Mon, Aug 10, 2009 at 10:45 PM, Aaron Boodman  wrote:

> Such a system does not help when people sync your change. We should
> invest the effort we would expend building this system fixing the
> dependency issues.


gclient could be made to obey it as well.  But I agree, it's a hack.


> Barring that, we have a hack that we do where for resource files we
> make a whitespace change to the corresponding .gyp. We could automate
> this by having a presubmit check that enforces this.


Better than nothing.

We also have the hack for grd files that deletes all the associated .h
files.  Something like that might work here as well.

How hard would it be to make the system actually understand the
dependencies?  Is visual studio really just too dumb to understand?

--~--~-~--~~~---~--~~
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: Clobbering

[Aaron Boodman]

Such a system does not help when people sync your change. We should
invest the effort we would expend building this system fixing the
dependency issues.

Barring that, we have a hack that we do where for resource files we
make a whitespace change to the corresponding .gyp. We could automate
this by having a presubmit check that enforces this.

- a

On Mon, Aug 10, 2009 at 10:16 PM, Jeremy Orlow wrote:
> We really need a better way to submit patches that we know require a
> clobber.  Today alone, there were 2 WebKit deps rolls that we _knew_ would
> need a clobber.  Both ended up closing the tree for a bit.
> What if we added an optional flag to the CL descriptions that tells the bots
> that a clobber is necessary?  Maybe just CLOBBER=blah where blah is the
> platforms that require it split by commas and/or spaces?  So, for example,
> my CL might look like:
> """
> This is a really nice CL, but it touches files that confuse the dependency
> tracking system on Windows and linux.
> TEST=none
> BUG=none
> CLOBBER=win, linux
> """
> Would this be terribly hard?  Any major downsides?
> J
> >
>

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

[chromium-dev] Clobbering

[Jeremy Orlow]

We really need a better way to submit patches that we know require a
clobber.  Today alone, there were 2 WebKit deps rolls that we _knew_ would
need a clobber.  Both ended up closing the tree for a bit.
What if we added an optional flag to the CL descriptions that tells the bots
that a clobber is necessary?  Maybe just CLOBBER=blah where blah is the
platforms that require it split by commas and/or spaces?  So, for example,
my CL might look like:

"""
This is a really nice CL, but it touches files that confuse the dependency
tracking system on Windows and linux.

TEST=none
BUG=none
CLOBBER=win, linux
"""

Would this be terribly hard?  Any major downsides?

J

--~--~-~--~~~---~--~~
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: gyp failing while triggering gclient sync in linux with git

[Bradley Nelson]

Not that I know of. Too bad really...-BradN


On Thu, Aug 6, 2009 at 10:56 PM, Mohamed Mansour  wrote:

> What is stopping us doing "Massive" line endings commit for all the files
> in our repository in src/chrome.
> +1 on the presubmit check! Is there a way to force Visual Studio
> "Solutions" or "Projects" to always save line endings in LF generated via
> gyp.
>
> -- Mohamed Mansour
>
>
>
> On Fri, Aug 7, 2009 at 1:48 AM, Bradley Nelson wrote:
>
>> Yeah we should certainly handle this better.This was a known thing, but
>> I've called it out in this gyp issue:
>> http://code.google.com/p/gyp/issues/detail?id=38
>>
>> I do like have consistent line endings, but the error message leaves
>> something to be desired (not to mention being different on each platform
>> :-).
>> Shouldn't be a big deal to fix.
>>
>> -BradN
>>
>>
>> On Thu, Aug 6, 2009 at 10:39 PM, Evan Martin  wrote:
>>
>>> I am a little surprised that Python's "eval" isn't line-ending agnostic.
>>> This thread
>>>
>>> http://mail.python.org/pipermail/pythonmac-sig/2004-September/011638.html
>>> suggests it doesn't like \r even on Windows and offers a simple
>>> workaround when reading the file:
>>>  '\n'.join(s.splitlines())
>>>
>>> On Thu, Aug 6, 2009 at 9:28 PM, Bradley Nelson
>>> wrote:
>>> > Yes Mohamed, please do. Which files had the dos line endings?
>>> > We should really add a presubmit check...
>>> > -BradN
>>> >
>>> > On Thu, Aug 6, 2009 at 9:22 PM, Mohamed Mansour <
>>> m0.interact...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Ah thank you Dan! It worked! I guess I should commit the line ending
>>> then?
>>> >> -- Mohamed Mansour
>>> >>
>>> >>
>>> >> On Fri, Aug 7, 2009 at 12:17 AM, Dan Kegel  wrote:
>>> >>>
>>> >>> Please check to make sure the python scripts have UNIX
>>> >>> line endings, not DOS ones.
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> > >>> >
>>> >
>>>
>>
>>
>

--~--~-~--~~~---~--~~
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: build error, libavcodec.so.52

[王重傑]

On the bright side, now you only download the binaries that make sense for
your platform. :)
-Albert


On Mon, Aug 10, 2009 at 5:18 PM, Andrew Scherkus wrote:

> We shuffled these around on Friday such that these binaries now live in
> /deps/third_party/ffmpeg and are pulling in via DEPS.
> Try:
> rm -rf src/third_party/ffmpeg/binaries
> rm .gclient_entries
> gclient sync --force
>
> On Mon, Aug 10, 2009 at 5:04 PM, Paweł Hajdan Jr.  > wrote:
>
>> Just got this error:
>> scons: *** [/chromium/src/sconsbuild/Debug/libavcodec.so.52] Source
>> `/chromium/src/sconsbuild/Debug/obj/third_party/ffmpeg/binaries/chromium/libavcodec.so.52'
>> not found, needed by target
>> `/chromium/src/sconsbuild/Debug/libavcodec.so.52'.
>>
>> I'll try to workaround it, but it looks like a bug. I did gclient sync
>> recently (which ran gyp).
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: build error, libavcodec.so.52

[Andrew Scherkus]

We shuffled these around on Friday such that these binaries now live in
/deps/third_party/ffmpeg and are pulling in via DEPS.
Try:
rm -rf src/third_party/ffmpeg/binaries
rm .gclient_entries
gclient sync --force

On Mon, Aug 10, 2009 at 5:04 PM, Paweł Hajdan Jr.
wrote:

> Just got this error:
> scons: *** [/chromium/src/sconsbuild/Debug/libavcodec.so.52] Source
> `/chromium/src/sconsbuild/Debug/obj/third_party/ffmpeg/binaries/chromium/libavcodec.so.52'
> not found, needed by target
> `/chromium/src/sconsbuild/Debug/libavcodec.so.52'.
>
> I'll try to workaround it, but it looks like a bug. I did gclient sync
> recently (which ran gyp).
>
> >
>

--~--~-~--~~~---~--~~
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: build error, libavcodec.so.52

[Paweł Hajdan Jr .]

Looks like gclient sync --force fixed that. I think something confused git
while switching old branches.

On Mon, Aug 10, 2009 at 17:04, Paweł Hajdan Jr. wrote:

> Just got this error:
> scons: *** [/chromium/src/sconsbuild/Debug/libavcodec.so.52] Source
> `/chromium/src/sconsbuild/Debug/obj/third_party/ffmpeg/binaries/chromium/libavcodec.so.52'
> not found, needed by target
> `/chromium/src/sconsbuild/Debug/libavcodec.so.52'.
>
> I'll try to workaround it, but it looks like a bug. I did gclient sync
> recently (which ran gyp).
>

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

[chromium-dev] build error, libavcodec.so.52

[Paweł Hajdan Jr .]

Just got this error:
scons: *** [/chromium/src/sconsbuild/Debug/libavcodec.so.52] Source
`/chromium/src/sconsbuild/Debug/obj/third_party/ffmpeg/binaries/chromium/libavcodec.so.52'
not found, needed by target
`/chromium/src/sconsbuild/Debug/libavcodec.so.52'.

I'll try to workaround it, but it looks like a bug. I did gclient sync
recently (which ran gyp).

--~--~-~--~~~---~--~~
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: Why does Chromium on mac have a theme switch UI in the preferences?

[Aaron Boodman]

On Mon, Aug 10, 2009 at 11:09 AM, Avi Drissman wrote:
> On Mon, Aug 10, 2009 at 1:31 PM, Aaron Boodman  wrote:
>>
>> > Incidentally, two other asks:
>> > * When "installing" a theme, give the user a way to switch back to the
>> > previous theme (e.g. an infobar).  We currently have an option to switch
>> > back to the default theme, which is also useful, in different cases.
>>
>> We have a bug open on this. It requires some changes to the themes
>> service. I think that Avi is working on this.
>
> I am? Please assign the bug, then, because I was unaware of it.

FYI, just so interested parties know the resolution, the work I was
thinking of Avi was working on, but it i done now. We can now
implement the undo UI, I will create a bug on myself.

- 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: Stack traces on layout test crashes

[Ojan Vafai]

On Mon, Aug 10, 2009 at 1:39 PM, Nicolas Sylvain wrote:

> On Mon, Aug 10, 2009 at 10:35 AM, Jeremy Orlow wrote:
>
>> On Mon, Aug 10, 2009 at 9:59 AM, Ojan Vafai  wrote:
>>
>>> On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow wrote:
>>>
  On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain >>> > wrote:

> 2. The show stopper for any implementation of this feature is that the
> machines running the layout tests don't have the pdbs for test_shell. 
> Since
> the binary is built on another machine, it was too slow to copy the pdbs
> from one machine to another. If you guys think it's important, and can 
> take
> the ~30-60 more seconds to cycle the bots, then we can copy them too, and
> the feature would work.
>

 I'm not really sure what the right answer is.  It sure would be nice if
 we didn't need to use a tool to decode the call stacks of crashed layout
 tests.  I kind of feel like an additional 30-60 seconds isn't going to be a
 big deal on these bots, but maybe it is.  What do people think?

>>>
>>> A minute is a really long amount of time to add for the bots to cycle.
>>> Our goal historically has been 5 minutes for a full cycle. The tree is
>>> generally so much greener and easier to keep that way when we have fast
>>> cycle times. If there is a way to do it that doesn't require hitting the
>>> critical path, I think we should seriously consider it.
>>>
>>
>> K.  I'll assume that's not an option when I look into this, then.
>>
> We might be able to speed it up. We can try it and see how much slower it
> gets.
>

I'm all for trying the easy thing and seeing what the cost is. If it turns
out to be expensive, we can try other things.

Also, if getting a 1 minute hit on build cycle times is the only
(reasonable) way to accomplish this, then I *do* think it's worth it. This
is really valuable. Would be great if we could get stacktraces and keep the
same(ish) cycle times though. :)

Ojan

--~--~-~--~~~---~--~~
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: Do we have any existing code for reading/writing INI files?

[Brett Wilson]

On Mon, Aug 10, 2009 at 3:28 PM, Daniel Cowx wrote:
>
> Just wondering if there's any code kicking around somewhere in the
> codebase for reading/writing INI files?

No, we don't deal with ini files at all to my knowledge. We use JSON
for that type of thing. What do you need it for?

Brett

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

[chromium-dev] Re: How not to spend the day getting depot_tools, cygwin & svn to play nicely...

[Andrew Scherkus]

This thread couldn't have been more appropriately timed.  I ran into the
Error 34 issue again checking out a fresh client :\

Never again...

http://codereview.chromium.org/164281

On Mon, Aug 10, 2009 at 11:17 AM, Jens Alfke  wrote:

>
> On Aug 7, 2009, at 5:25 PM, Peter Kasting wrote:
>
> Yep.  You MUST have the depot_tools svn ahead of the cygwin svn and use
> only that to check out Chromium.  I thought we noted this somewhere...
>
>
> Thanks for the tip. I'm just going through this setup right now, though it
> sounds like I'll be OK since I installed depot_tools and checked out
> Chromium before I installed Cygrin.
>
> I'll update the wiki 
> page
> .
>
> —Jens
>
> >
>

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

[chromium-dev] Do we have any existing code for reading/writing INI files?

[Daniel Cowx]

Just wondering if there's any code kicking around somewhere in the
codebase for reading/writing INI 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: Why does Chromium on mac have a theme switch UI in the preferences?

[Aaron Boodman]

On Mon, Aug 10, 2009 at 12:25 AM,
stourw...@googlemail.com wrote:
> As a user I don't mind going back to the gallery each time I want to
> change theme (and my mood will make me change themes regularly), but
> what is frustrating is that everytime I go back to one that I've tried
> in the past it redownloads the file again rather than using the .crx
> that is already present.  Maybe the themes/extensions shouldn't be
> downloaded into the main download folder and checked to see if already
> present.

We're going to fix this so that they don't go to the downloads folder.

> Can themes auto-update?

Yes!

- 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: Stack traces on layout test crashes

[Viet-Trung Luu]

I hereby hang my head in shame. :-( (Should have noticed the "new 
members moderated" bit)


--~--~-~--~~~---~--~~
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: Stack traces on layout test crashes

[Viet-Trung Luu]

[I can't seem to get this reply to chromium-dev. Maybe it didn't like 
the Chinese characters in Albert's name? I hope N duplicates don't 
eventually show up on the list.]

Here's a slightly improved (well, much improved, in that it doesn't 
crash[*]) version, again if anyone wants to mess with it:

 http://codereview.chromium.org/165224

(pardon the ugly code). Unfortunately, it fails miserably at resolving 
many "symbols" (my implementation falls back to dladdr(), which provides 
really crappy symbols), since proper symbols aren't actually generated 
for most Objective-C methods (at least in the system libraries). For 
those, you have to search in the __OBJC segment ... which I'm not quite 
keen enough to do right now.

[*] The image isn't mapped into memory contiguously starting from the 
base address; the symtab and string table should usually end up in the 
__LINKEDIT segment, so you have to figure out appropriate addresses. You 
also have the joy of figuring out whether you're dealing with relocated 
or unrelocated addresses (hmmm -- maybe my abbreviation "rel" == 
"relative" == "unrelocated" isn't so great), for some reason. Ugh.

- Trung

Albert J. Wong wrote:
> FYI, the code in debug_util.h will generate a stack trace, but symbol 
> resolution doesn't work on mac.  Last I messed with it (~4 months ago), 
> mac didn't work because most of the symbols are private.  Mark Mentovai 
> suggested trying to reimplement dladdr, but I could never get it 
> working.  Here's the uploaded code if anyone to mess with it:
> 
>http://codereview.chromium.org/164228
> 
> On windows and linux, assuming you actually have symbols generated 
> (which I don't think you do for windows on the build bots), getting a 
> trace should be as simple as creating one of those StackTrace objects in 
> debug_util.h, and calling PrintBacktrace or OutputToStream on it.  The 
> hard part is knowing when to create the object, and making sure you're 
> on the right thread.  Also, these functions do some heap allocations so 
> using them in a crash handler might be a bit unsafe...but if it's 
> crashing, and there's already no way to get a core or something, making 
> it crash harder isn't going to matter.
> 
> -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: Why does Chromium on mac have a theme switch UI in the preferences?

[stourw...@googlemail.com]

As a user I don't mind going back to the gallery each time I want to
change theme (and my mood will make me change themes regularly), but
what is frustrating is that everytime I go back to one that I've tried
in the past it redownloads the file again rather than using the .crx
that is already present.  Maybe the themes/extensions shouldn't be
downloaded into the main download folder and checked to see if already
present.

Can themes auto-update?

--~--~-~--~~~---~--~~
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: Why does Chromium on mac have a theme switch UI in the preferences?

[Brian Rakowski]

Yes, I wholeheartedly agree that these are gallery features. We should
remove them from options/prefs panels.

On Mon, Aug 10, 2009 at 11:09 AM, Avi Drissman  wrote:

> On Mon, Aug 10, 2009 at 1:31 PM, Aaron Boodman  wrote:
>
>> > Incidentally, two other asks:
>> > * When "installing" a theme, give the user a way to switch back to the
>> > previous theme (e.g. an infobar).  We currently have an option to switch
>> > back to the default theme, which is also useful, in different cases.
>>
>> We have a bug open on this. It requires some changes to the themes
>> service. I think that Avi is working on this.
>>
>
> I am? Please assign the bug, then, because I was unaware of it.
>
> Avi
>
>
> >
>

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

[chromium-dev] Re: Hyperlink-like UI element

[Evan Stade]

I agree that Get Themes ought to be a link. There are other links in
the options menu (Learn More, Manage Certificates), so I think this
was just an oversight.

-- Evan Stade



On Mon, Aug 10, 2009 at 11:14 AM, Jens Alfke wrote:
>
> The use of blue-underlined links for actions, as opposed to
> navigation, is unfortunately common in a number of Google's web UIs
> (like Sites and Docs.) I'm not sure what the official position is on
> it at Google, or among the web UI design community at large, but I
> personally think it's a very bad idea.
>
> —Jens
> >
>

--~--~-~--~~~---~--~~
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: Stack traces on layout test crashes

[Viet-Trung Luu]

Here's a slightly improved (well, much improved, in that it doesn't 
crash[*]) version, again if anyone wants to mess with it:

 http://codereview.chromium.org/165224

(pardon the ugly code). Unfortunately, it fails miserably at resolving 
many "symbols" (my implementation falls back to dladdr(), which provides 
really crappy symbols), since proper symbols aren't actually generated 
for most Objective-C methods (at least in the system libraries). For 
those, you have to search in the __OBJC segment ... which I'm not quite 
keen enough to do right now.

[*] The image isn't mapped into memory contiguously starting from the 
base address; the symtab and string table should usually end up in the 
__LINKEDIT segment, so you have to figure out appropriate addresses. You 
also have the joy of figuring out whether you're dealing with relocated 
or unrelocated addresses (hmmm -- maybe my abbreviation "rel" == 
"relative" == "unrelocated" isn't so great), for some reason. Ugh.

- Trung

Albert J. Wong (王重傑) wrote:
> FYI, the code in debug_util.h will generate a stack trace, but symbol 
> resolution doesn't work on mac.  Last I messed with it (~4 months ago), 
> mac didn't work because most of the symbols are private.  Mark Mentovai 
> suggested trying to reimplement dladdr, but I could never get it 
> working.  Here's the uploaded code if anyone to mess with it:
> 
>http://codereview.chromium.org/164228
> 
> On windows and linux, assuming you actually have symbols generated 
> (which I don't think you do for windows on the build bots), getting a 
> trace should be as simple as creating one of those StackTrace objects in 
> debug_util.h, and calling PrintBacktrace or OutputToStream on it.  The 
> hard part is knowing when to create the object, and making sure you're 
> on the right thread.  Also, these functions do some heap allocations so 
> using them in a crash handler might be a bit unsafe...but if it's 
> crashing, and there's already no way to get a core or something, making 
> it crash harder isn't going to matter.
> 
> -Albert
> 
> 
> On Sat, Aug 8, 2009 at 11:12 AM, Jeremy Orlow  > wrote:
> 
> I'll take a look.
> 
> If anyone has ideas on how to implement this (beyond looking at
> base/debug_util.h) please let me know! The last time I messed around
> with programatic stack traces was 5+ years ago. :-)
> 
> 
> On Sat, Aug 8, 2009 at 7:53 AM, Dimitri Glazkov
> mailto:dglaz...@chromium.org>> wrote:
> 
> Somebody please run with this! :)
> 
> :DG<
> 
> On Fri, Aug 7, 2009 at 8:45 PM, Darin Fisher > wrote:
>  > On Fri, Aug 7, 2009 at 8:39 PM, Ojan Vafai  > wrote:
>  >>
>  >> On Fri, Aug 7, 2009 at 8:45 PM, Jeremy Orlow
> mailto:jor...@chromium.org>> wrote:
>  >>>
>  >>> Has anyone ever looked into printing out stack traces when
> layout tests
>  >>> crash?  Of the couple layout test crashes I've
> investigated, I think most
>  >>> could have been solved just by having a stack trace.  I'm
> not really sure
>  >>> what's involved or if anyone's looked into this, which is
> why I'm asking.
>  >>>  This could be especially helpful for flaky tests that crash.
>  >>
>  >> I don't remember anyone having looked into this. I agree
> that this would
>  >> make tracking down and fixing these issues immensely easier,
> especially for
>  >> tests that only sometimes crash.
>  >> Ojan
>  >
>  > I've wanted this for a very long time.  I think there might
> be a bug on it.
>  >  At any rate, we now have a nice utility in base/debug_util.h
> that can
>  > provide a stack trace.  I would love to see crash stacks on
> the buildbot.
>  >  It would probably help us eliminate a lot of flakiness!
>  > -Darin
>  > >
>  >
> 
> 
> 
> 
> 
> 
> > 


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

[chromium-dev] Re: Stack traces on layout test crashes

[viettrungluu]

[Still didn't make it to chromium-dev -- trying yet again. Sorry for
any dupes.]

Here's a slightly improved (well, much improved, in that it doesn't
crash[*]) version, again if anyone wants to mess with it:

http://codereview.chromium.org/165224

(pardon the ugly code). Unfortunately, it fails miserably at resolving
many "symbols" (my implementation falls back to dladdr(), which
provides really crappy symbols), since proper symbols aren't actually
generated for most Objective-C methods (at least in the system
libraries). For those, you have to search in the __OBJC segment ...
which I'm not quite keen enough to do right now.

[*] The image isn't mapped into memory contiguously starting from the
base address; the symtab and string table should usually end up in the
__LINKEDIT segment, so you have to figure out appropriate addresses.
You also have the joy of figuring out whether you're dealing with
relocated or unrelocated addresses (hmmm -- maybe my abbreviation
"rel" == "relative" == "unrelocated" isn't so great), for some reason.
Ugh.

- Trung

On Aug 8, 2:42 pm, Albert J. Wong (王重傑)  wrote:
> FYI, the code in debug_util.h will generate a stack trace, but symbol
> resolution doesn't work on mac.  Last I messed with it (~4 months ago), mac
> didn't work because most of the symbols are private.  Mark Mentovai
> suggested trying to reimplement dladdr, but I could never get it working.
> Here's the uploaded code if anyone to mess with it:
>
>    http://codereview.chromium.org/164228
>
> On windows and linux, assuming you actually have symbols generated (which I
> don't think you do for windows on the build bots), getting a trace should be
> as simple as creating one of those StackTrace objects in debug_util.h, and
> calling PrintBacktrace or OutputToStream on it.  The hard part is knowing
> when to create the object, and making sure you're on the right thread.
> Also, these functions do some heap allocations so using them in a crash
> handler might be a bit unsafe...but if it's crashing, and there's already no
> way to get a core or something, making it crash harder isn't going to
> matter.
>
> -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: How not to spend the day getting depot_tools, cygwin & svn to play nicely...

[Jens Alfke]

On Aug 7, 2009, at 5:25 PM, Peter Kasting wrote:

> Yep.  You MUST have the depot_tools svn ahead of the cygwin svn and  
> use only that to check out Chromium.  I thought we noted this  
> somewhere...

Thanks for the tip. I'm just going through this setup right now,  
though it sounds like I'll be OK since I installed depot_tools and  
checked out Chromium before I installed Cygrin.

I'll update the wiki page.

—Jens
--~--~-~--~~~---~--~~
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: Hyperlink-like UI element

[Jens Alfke]

The use of blue-underlined links for actions, as opposed to  
navigation, is unfortunately common in a number of Google's web UIs  
(like Sites and Docs.) I'm not sure what the official position is on  
it at Google, or among the web UI design community at large, but I  
personally think it's a very bad idea.

—Jens
--~--~-~--~~~---~--~~
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: Why does Chromium on mac have a theme switch UI in the preferences?

[Avi Drissman]

On Mon, Aug 10, 2009 at 1:31 PM, Aaron Boodman  wrote:

> > Incidentally, two other asks:
> > * When "installing" a theme, give the user a way to switch back to the
> > previous theme (e.g. an infobar).  We currently have an option to switch
> > back to the default theme, which is also useful, in different cases.
>
> We have a bug open on this. It requires some changes to the themes
> service. I think that Avi is working on this.
>

I am? Please assign the bug, then, because I was unaware of it.

Avi

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

[chromium-dev] Re: Stack traces on layout test crashes

[Nicolas Sylvain]

On Mon, Aug 10, 2009 at 10:35 AM, Jeremy Orlow  wrote:

> On Mon, Aug 10, 2009 at 9:59 AM, Ojan Vafai  wrote:
>
>> On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow wrote:
>>
>>>  On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain 
>>> wrote:
>>>
 2. The show stopper for any implementation of this feature is that the
 machines running the layout tests don't have the pdbs for test_shell. Since
 the binary is built on another machine, it was too slow to copy the pdbs
 from one machine to another. If you guys think it's important, and can take
 the ~30-60 more seconds to cycle the bots, then we can copy them too, and
 the feature would work.

>>>
>>> I'm not really sure what the right answer is.  It sure would be nice if
>>> we didn't need to use a tool to decode the call stacks of crashed layout
>>> tests.  I kind of feel like an additional 30-60 seconds isn't going to be a
>>> big deal on these bots, but maybe it is.  What do people think?
>>>
>>
>> A minute is a really long amount of time to add for the bots to cycle. Our
>> goal historically has been 5 minutes for a full cycle. The tree is generally
>> so much greener and easier to keep that way when we have fast cycle times.
>> If there is a way to do it that doesn't require hitting the critical path, I
>> think we should seriously consider it.
>>
>
> K.  I'll assume that's not an option when I look into this, then.
>
We might be able to speed it up. We can try it and see how much slower it
gets.

see test_shell_switches.cc
There is already a :
const wchar_t kCrashDumps[] = L"crash-dumps";  // Enable crash dumps

It is using breakpad. I think it should work.

Nicolas

--~--~-~--~~~---~--~~
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: Stack traces on layout test crashes

[Jeremy Orlow]

On Mon, Aug 10, 2009 at 9:59 AM, Ojan Vafai  wrote:

> On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow  wrote:
>
>> On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain wrote:
>>
>>> 2. The show stopper for any implementation of this feature is that the
>>> machines running the layout tests don't have the pdbs for test_shell. Since
>>> the binary is built on another machine, it was too slow to copy the pdbs
>>> from one machine to another. If you guys think it's important, and can take
>>> the ~30-60 more seconds to cycle the bots, then we can copy them too, and
>>> the feature would work.
>>>
>>
>> I'm not really sure what the right answer is.  It sure would be nice if we
>> didn't need to use a tool to decode the call stacks of crashed layout tests.
>>  I kind of feel like an additional 30-60 seconds isn't going to be a big
>> deal on these bots, but maybe it is.  What do people think?
>>
>
> A minute is a really long amount of time to add for the bots to cycle. Our
> goal historically has been 5 minutes for a full cycle. The tree is generally
> so much greener and easier to keep that way when we have fast cycle times.
> If there is a way to do it that doesn't require hitting the critical path, I
> think we should seriously consider it.
>

K.  I'll assume that's not an option when I look into this, then.

--~--~-~--~~~---~--~~
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: Why does Chromium on mac have a theme switch UI in the preferences?

[Peter Kasting]

On Mon, Aug 10, 2009 at 10:31 AM, Aaron Boodman  wrote:

> I think that building this into the gallery makes a lot of sense. And
> I realized that by "preview" you all might mean "a picture of what
> this looks like", before you click anything. Similar to what is on the
> current gallery pages.


Precisely.

>  Perhaps have both?
>
> I'd rather it be just "undo" alone. We have an emergency "exit back to
> default" theme hidden in the prefs. Maybe it could also be in the
> gallery.


Sounds fine.

Thanks, glad we converged a bit :)

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] Re: Why does Chromium on mac have a theme switch UI in the preferences?

[Aaron Boodman]

On Mon, Aug 10, 2009 at 10:05 AM, Peter Kasting wrote:
> [Edit: right as I was going to send this, I see you seem to be thinking
> along similar lines.]
> You're right that a dropdown with the names of every theme the user has ever
> used is both unwieldy and unhelpful.  How about this:
> We replace the Options buttons with a page with the 5 MRU themes (perhaps
> "that have been used for more than 1 minute") and the default theme, each
> with a name, a thumbnail, and perhaps a link to the container page; and a
> link to the main theme gallery called "pick another theme" or "get more
> themes" or something.  Click on a theme and it changes the current theme
> instantly, but doesn't reorder the list until you close the page.
> Or, instead of building this list in locally, we could build it in to the
> themes gallery.  When you go there these MRU themes (and the default) are
> right on the first page.  This can also help when you're trying to set up
> another machine with the theme you like and need to remember what it is.
> I hope you can understand why having the MRU themes at your fingertips can
> be convenient even if there is some way (the history page?) to try and find
> past themes.

I think that building this into the gallery makes a lot of sense. And
I realized that by "preview" you all might mean "a picture of what
this looks like", before you click anything. Similar to what is on the
current gallery pages.

> Incidentally, two other asks:
> * When "installing" a theme, give the user a way to switch back to the
> previous theme (e.g. an infobar).  We currently have an option to switch
> back to the default theme, which is also useful, in different cases.

We have a bug open on this. It requires some changes to the themes
service. I think that Avi is working on this.

>  Perhaps have both?

I'd rather it be just "undo" alone. We have an emergency "exit back to
default" theme hidden in the prefs. Maybe it could also be in the
gallery.

> * Don't leave crud (.crx files, anything in downloads directory, files in
> the user profile) on disk for previously installed themes.  Clean them up.
>  (Low priority.)

It actually deletes them as of right now. You're remembering the way
it used to behave.

However, they still show up on the downloads page. There is a bug open on that.

- 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: Why does Chromium on mac have a theme switch UI in the preferences?

[Mohamed Mansour]

How would this be done if installing a theme doesn't require any
authentication? If we are going this approach, it means the user should be
logged in to manage his/her own themes? I like this approach as well... but
why not just do this:
Create a chrome://themes/ page where we asynchronously fetch the theme data
from the remote website, that way, we can control how that page is rendered
with prefs (currently installed theme, last 5 installed themes, etc ) we
could even make that chrome://themes/ page fetch themes from different
sources (not only from Google) via syndication. Just a thought.

Later on, we could even have the chrome://themes/ page create custom colours
for themes (once again, easily done by altering the prefs) if the user
wants. Add tints, etc ... Many, many people on the forums want custom
colours. (Similar to GMail)

-- Mohamed Mansour


On Mon, Aug 10, 2009 at 1:13 PM, Amanda Walker  wrote:

> On Mon, Aug 10, 2009 at 1:05 PM, Peter Kasting wrote:
>
>> Or, instead of building this list in locally, we could build it in to the
>> themes gallery.  When you go there these MRU themes (and the default) are
>> right on the first page.  This can also help when you're trying to set up
>> another machine with the theme you like and need to remember what it is.
>>
>
> +1.  This also helps frame the UX as "pick", not "install".
>
> --Amanda
>
>
>
> >
>

--~--~-~--~~~---~--~~
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: Why does Chromium on mac have a theme switch UI in the preferences?

[Amanda Walker]

On Mon, Aug 10, 2009 at 1:05 PM, Peter Kasting  wrote:

> Or, instead of building this list in locally, we could build it in to the
> themes gallery.  When you go there these MRU themes (and the default) are
> right on the first page.  This can also help when you're trying to set up
> another machine with the theme you like and need to remember what it is.
>

+1.  This also helps frame the UX as "pick", not "install".

--Amanda

--~--~-~--~~~---~--~~
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: Why does Chromium on mac have a theme switch UI in the preferences?

[Peter Kasting]

[Edit: right as I was going to send this, I see you seem to be thinking
along similar lines.]

You're right that a dropdown with the names of every theme the user has ever
used is both unwieldy and unhelpful.  How about this:

We replace the Options buttons with a page with the 5 MRU themes (perhaps
"that have been used for more than 1 minute") and the default theme, each
with a name, a thumbnail, and perhaps a link to the container page; and a
link to the main theme gallery called "pick another theme" or "get more
themes" or something.  Click on a theme and it changes the current theme
instantly, but doesn't reorder the list until you close the page.

Or, instead of building this list in locally, we could build it in to the
themes gallery.  When you go there these MRU themes (and the default) are
right on the first page.  This can also help when you're trying to set up
another machine with the theme you like and need to remember what it is.

I hope you can understand why having the MRU themes at your fingertips can
be convenient even if there is some way (the history page?) to try and find
past themes.

Incidentally, two other asks:

* When "installing" a theme, give the user a way to switch back to the
previous theme (e.g. an infobar).  We currently have an option to switch
back to the default theme, which is also useful, in different cases.
 Perhaps have both?

* Don't leave crud (.crx files, anything in downloads directory, files in
the user profile) on disk for previously installed themes.  Clean them up.
 (Low priority.)

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] Re: Why does Chromium on mac have a theme switch UI in the preferences?

[Ben Goodger (Google)]

Seems like all of this can be done on the page. The nice property of
the page is that there's room to show a preview of the theme, which in
many cases is more memorable than the name.

-Ben

On Mon, Aug 10, 2009 at 10:02 AM, Aaron Boodman wrote:
>
> On Mon, Aug 10, 2009 at 9:24 AM, Steve Vandebogart wrote:
>> Undoubtedly, there will be hundreds of themes, finding the same one
>> you were using last week before you decided to try a different one
>> will be a daunting task.  From a usability perspective, it seems to me
>> that keeping around a small set of recently used themes makes sense.
>
> That seems better. I'm a lot more interested in a "recently used
> themes" or "previously used themes" (in the style of the history page)
> chrome://themes/ page than having the dropdown in the options menu.
>
> On the same page, we could combine the theme customization controls
> (tinting, etc).
>
> - 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: Why does Chromium on mac have a theme switch UI in the preferences?

[Aaron Boodman]

On Mon, Aug 10, 2009 at 9:24 AM, Steve Vandebogart wrote:
> Undoubtedly, there will be hundreds of themes, finding the same one
> you were using last week before you decided to try a different one
> will be a daunting task.  From a usability perspective, it seems to me
> that keeping around a small set of recently used themes makes sense.

That seems better. I'm a lot more interested in a "recently used
themes" or "previously used themes" (in the style of the history page)
chrome://themes/ page than having the dropdown in the options menu.

On the same page, we could combine the theme customization controls
(tinting, etc).

- 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: Stack traces on layout test crashes

[Ojan Vafai]

On Mon, Aug 10, 2009 at 3:12 AM, Jeremy Orlow  wrote:

> On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain wrote:
>
>> 2. The show stopper for any implementation of this feature is that the
>> machines running the layout tests don't have the pdbs for test_shell. Since
>> the binary is built on another machine, it was too slow to copy the pdbs
>> from one machine to another. If you guys think it's important, and can take
>> the ~30-60 more seconds to cycle the bots, then we can copy them too, and
>> the feature would work.
>>
>
> I'm not really sure what the right answer is.  It sure would be nice if we
> didn't need to use a tool to decode the call stacks of crashed layout tests.
>  I kind of feel like an additional 30-60 seconds isn't going to be a big
> deal on these bots, but maybe it is.  What do people think?
>

A minute is a really long amount of time to add for the bots to cycle. Our
goal historically has been 5 minutes for a full cycle. The tree is generally
so much greener and easier to keep that way when we have fast cycle times.
If there is a way to do it that doesn't require hitting the critical path, I
think we should seriously consider it.

Ojan

--~--~-~--~~~---~--~~
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 not to spend the day getting depot_tools, cygwin & svn to play nicely...

[Andrew Scherkus]

My experience with this is that it's either all-or-nothing when it comes to
using cygwin tools.  My main git-svn checkout was created using cygwin
svn+python, so I now need to comment out the lines in gclient that tries to
run the .bat file :\

Overall I think I'm happier with my all-cygwin client.. it keeps the
carriage returns away, which also makes git much happier.

On Fri, Aug 7, 2009 at 5:25 PM, Peter Kasting  wrote:

> On Fri, Aug 7, 2009 at 5:13 PM, Rafael Weinstein wrote:
>
>> Cygwin svn was doing something horrible (probably permissions-related) to
>> my third_party/python_24 that caused the python binary not to run. The
>> visible symptom was that my build generated a ton of cryptic "Error 24"s
>> from Cmd.exe.
>>
>> The solution was to use the windows svn binaries.
>>
>
> Yep.  You MUST have the depot_tools svn ahead of the cygwin svn and use
> only that to check out Chromium.  I thought we noted this somewhere...
>
>
>> 1) Download depot_tools
>> 2) Run gclient for the first time from command.exe (so you get the windows
>> binaries)
>> 3) Put /cygdrive/path/to/depot_tools as the FIRST component of you cygwin
>> path (from .profile or .bashrc)
>>
>
> Easier steps than these (maybe): Copy over a depot_tools folder from your
> previous machine (if applicable), ensure it's ahead of /usr/bin via
> .bash_profile or whatever.
>
> 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] Re: Why does Chromium on mac have a theme switch UI in the preferences?

[Aaron Boodman]

On Mon, Aug 10, 2009 at 8:50 AM, Avi Drissman wrote:
> Right now there's no real control over themes. Once they're installed,
> they're permanently installed; there's no easy way to remove them

We should completely drop the concept of theme "installation". We can
do this by changing the language around themes in the UI. For example,
instead of "get themes", the button could read "pick new theme".

There can only be one theme active at a time, so whether the themes
are still on your computer when you switch away from them is sorta
irrelevant. From a cleanliness perspective, I would like to remove
them, but the fact that you currently can't remove a theme after you
switch away from it should not be an issue for most people.

> (chrome://extensions used to list them so they could be removed, but now you
> can't even do that). So why not let the user switch?

I'm not saying the user shouldn't be able to switch. I'm saying why
have two ways to switch, one that is inferior to the other.

> Assuming that the themes gallery will be the only source of themes and that
> the users would just have to go there is silly. The "Get Themes" button is
> only a suggestion, and while we have themes that we think are nice, there
> will be third-party providers.

Of course, but if you want to reinstall one of those themes, you can
just go back to the page you originally got it from. Why is it useful
to have a list of every theme you have ever picked in the options
menu? Like others have said, I expect this list to get long and there
is no way to manage it.

> If you don't think the popup does an adequate job of showing
> previews/management, you are absolutely correct. I'd love a chrome://themes
> page that
> - showed installed themes
> - allowed switching themes

It sounds like you want something almost like "favorite themes" - a
list that can be managed. I can see some minor utility in this above
just going back to the web page that has the theme you want and
picking it again, but it seems pretty thin. I don't believe it is
worth the implementation, maintenance, and simplicity costs to
implement it.

> -- with previews

Why do we need a separate concept of "preview" when you can just
install a theme, and if you don't like it switch back to the one you
had before. If the infobar said (and did) "undo" instead of "back to
default", doesn't this meet the need?

> -- with deinstall buttons

Why does it matter to uninstall a theme that you aren't using?
Particularly if we automatically delete theme resources when they are
switched away from?

> - allowed tinting for themes (which I've heard only Cole talk about but no
> one else mention)

Once we have this, you're right that we'll need some UI around it. I'd
prefer to wait until we know what the needs.

- 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: Why does Chromium on mac have a theme switch UI in the preferences?

[Avi Drissman]

On Mon, Aug 10, 2009 at 7:46 AM, Mohamed Mansour  wrote:

> I have been told that once you installed a new theme, the old theme will
> not be archived (stored on the system), so switching themes would be harder
> when the CL comes in.
>

That isn't the case today; that may be the case in the future.


> I thought you guys are picky when it comes to options
>

This one's mine, so I'll take the blame/praise as it goes.

Right now there's no real control over themes. Once they're installed,
they're permanently installed; there's no easy way to remove them
(chrome://extensions used to list them so they could be removed, but now you
can't even do that). So why not let the user switch?

Assuming that the themes gallery will be the only source of themes and that
the users would just have to go there is silly. The "Get Themes" button is
only a suggestion, and while we have themes that we think are nice, there
will be third-party providers.

If you don't think the popup does an adequate job of showing
previews/management, you are absolutely correct. I'd love a chrome://themes
page that
- showed installed themes
-- with previews
-- with deinstall buttons
- allowed switching themes
- allowed tinting for themes (which I've heard only Cole talk about but no
one else mention)

Until then I figured that throwing a picker into prefs would be something
useful.

Avi

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

[chromium-dev] Re: Hyperlink-like UI element

[Scott Violet]

On Sun, Aug 9, 2009 at 2:41 PM, Peter Kasting wrote:
> On Sun, Aug 9, 2009 at 4:43 AM, Caleb Eggensperger 
> wrote:
>>
>> I associate a button with doing something and a link with navigating
>> somewhere. But a link is used to remove a bookmark (from the menu you
>> get when you press the star button), and a button is used for the "Get
>> Themes" in the options box. Is there a rule here that I'm not seeing,
>> or were these just overlooked?
>
> The link in the bookmark bubble has been raised as an issue before.  One
> problem with a button is that (a) it's technically hard to put there and

That was true at one point, but no more. If you bring up the bookmark
bubble you'll see it already has a couple of buttons.

  -Scott

--~--~-~--~~~---~--~~
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: Stack traces on layout test crashes

[Dimitri Glazkov]

>> 2. The show stopper for any implementation of this feature is that the
>> machines running the layout tests don't have the pdbs for test_shell. Since
>> the binary is built on another machine, it was too slow to copy the pdbs
>> from one machine to another. If you guys think it's important, and can take
>> the ~30-60 more seconds to cycle the bots, then we can copy them too, and
>> the feature would work.
>
> I'm not really sure what the right answer is.  It sure would be nice if we
> didn't need to use a tool to decode the call stacks of crashed layout tests.
>  I kind of feel like an additional 30-60 seconds isn't going to be a big
> deal on these bots, but maybe it is.  What do people think?

We should probably implement a suppression mechanism here as well, so
that the crashes due to current work in progress (Mac plugins,
workers, etc.) don't take any time. This should minimize the impact.

:DG<

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

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

[Caleb Eggensperger]

I think that maybe a viable interim workaround to flash's
vulnerability problems would be to implement something like flashblock
by default. There would have to be some "always show flash on
*.google.com" whitelisting option (maybe automatically whitelist
bookmarked sites?), and it would have to be an infobar style
notification, since not all instances of flash are large
enough/visible. But this would basically solve the problem of
malicious flash on untrusted websites while not significantly
hindering legitimate uses of flash.

Is something like this in progress or would it be considered?

On Mon, Aug 10, 2009 at 05:50, Amanda Walker wrote:
> On Mon, Aug 10, 2009 at 12:32 AM, PhistucK  wrote:
>>
>> Obviously, but since there is a website (what started this thread) and
>> people do run into issues (Help forums) with such a thing, is a specific
>> solution for Flash, at least, coming up soon? People getting infected while
>> using Chrome is... really, really, not optimal.
>
> Oh, agreed.  But a sandbox for plugins that removes Adobe's ability to let
> Flash update itself with security fixes doesn't really solve this problem
> either (which is what some of the discussion earlier in the thread was
> about).  Right now, as I understand it, this vulnerability affects all
> browsers, not just Chrome--saying that a plugin vendor is in a better
> position to fix problems within a plugin isn't meant as a cop-out, it's just
> a description of where the problem lies.  Any sandbox is just one line of
> defense.
> The underlying problem is that the current spec for browser plugins (NPAPI)
> effectively gives a plugin all of the capabilities of an application.
>  Flash, since it's a programming environment in its own right, uses those
> capabilities to deliver value to users.  For example, Gmail uses a small
> Flash application that improves the user experience for attaching files to
> email messages--but also depends on Flash's ability to access the file
> system.  A video chat widget written in Flash needs access to the I/O
> subsystem in order to access the webcam.  Acrobat (at least in recent
> versions) allows embedded Javascript, which expands the capabilities of
> Acrobat but also provides new places for potentially malicious code to live.
> The fact that these capabilities are used for genuinely useful stuff as well
> as security exploits is what makes sandboxing plugins difficult.  We could
> turn off file system access, but then all sorts of "file upload" widgets
> would break, as well as Flash's own update facility.  We could turn off
> access to other I/O devices, but then webcam and video chat would break.
> The real solution is to improve the plugin runtime environment so that
> plugins don't need to talk to the OS directly for these sorts of things.
>  There is active work going on in places like the HTML5 working group,
> Mozilla's plugin wiki and mailing lists, etc. to make this happen, and we're
> contributing to that work.  All of us, browser and plugin writers alike, are
> painfully aware of the problems here.  And while we don't have a spot fix
> for this particular malicious website, it does serve as a good example of
> why that work is necessary.
> --Amanda
>
> >
>



-- 
Caleb Eggensperger
 http://calebegg.com/

--~--~-~--~~~---~--~~
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)

[Amanda Walker]

On Mon, Aug 10, 2009 at 12:32 AM, PhistucK  wrote:

> Obviously, but since there is a website (what started this thread) and
> people do run into issues (Help forums) with such a thing, is a specific
> solution for Flash, at least, coming up soon? People getting infected while
> using Chrome is... really, really, not optimal.
>

Oh, agreed.  But a sandbox for plugins that removes Adobe's ability to let
Flash update itself with security fixes doesn't really solve this problem
either (which is what some of the discussion earlier in the thread was
about).  Right now, as I understand it, this vulnerability affects all
browsers, not just Chrome--saying that a plugin vendor is in a better
position to fix problems within a plugin isn't meant as a cop-out, it's just
a description of where the problem lies.  Any sandbox is just one line of
defense.

The underlying problem is that the current spec for browser plugins (NPAPI)
effectively gives a plugin all of the capabilities of an application.
 Flash, since it's a programming environment in its own right, uses those
capabilities to deliver value to users.  For example, Gmail uses a small
Flash application that improves the user experience for attaching files to
email messages--but also depends on Flash's ability to access the file
system.  A video chat widget written in Flash needs access to the I/O
subsystem in order to access the webcam.  Acrobat (at least in recent
versions) allows embedded Javascript, which expands the capabilities of
Acrobat but also provides new places for potentially malicious code to live.

The fact that these capabilities are used for genuinely useful stuff as well
as security exploits is what makes sandboxing plugins difficult.  We could
turn off file system access, but then all sorts of "file upload" widgets
would break, as well as Flash's own update facility.  We could turn off
access to other I/O devices, but then webcam and video chat would break.

The real solution is to improve the plugin runtime environment so that
plugins don't need to talk to the OS directly for these sorts of things.
 There is active work going on in places like the HTML5 working group,
Mozilla's plugin wiki and mailing lists, etc. to make this happen, and we're
contributing to that work.  All of us, browser and plugin writers alike, are
painfully aware of the problems here.  And while we don't have a spot fix
for this particular malicious website, it does serve as a good example of
why that work is necessary.

--Amanda

--~--~-~--~~~---~--~~
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: Why does Chromium on mac have a theme switch UI in the preferences?

[Mohamed Mansour]

When people change themes regularly, I believe their intension is to try out
themes. When "theme preview" is going to come in, that would be simpler. A
person isn't going to change themes every day, if they want to change
themes, they could just goto the UI and change to any theme they please.
I believe a drop down for a list of themes is a waste of space for the
options panel, people wont use that frequently. I have been told that once
you installed a new theme, the old theme will not be archived (stored on the
system), so switching themes would be harder when the CL comes in.

I thought you guys are picky when it comes to options, and introducing a
themes drop down is actually a useless control which will be rarely used.
There are many other areas where I would like to have options which actually
makes more sense compared to this.

Aaron, I believe the themes page could use a "currently installed theme"
that way the user would know what theme he/she installed. It was possible by
visiting chrome://extensions/, but now its removed from that page.

-- Mohamed Mansour


On Mon, Aug 10, 2009 at 1:46 AM, PhistucK  wrote:

> But people like to change themes periodically and also, to choose from
> themes they have already installed and new themes, you (currently) cannot
> incorporate both of them in the theme gallery.
> I saw that happening with regular, non techy users - all of the time (not
> in Chrome, obviously, since they did not have an option up until now, but
> with tons of other programs).
> They choose one, they choose another, they select from their collection
> again and also look for new ones.
> So these should either be combined (existing and total in one page), or an
> option to select a theme should be present, in my opinion.
>
> ☆PhistucK
>
>
>
> On Mon, Aug 10, 2009 at 08:19, Aaron Boodman  wrote:
>
>>
>> On Sun, Aug 9, 2009 at 5:51 PM, Peter Kasting wrote:
>> > FWIW, I'd prefer if all the ports have this.
>> > There are three reasons for this, one of them silly:
>> > (1) Shows themes you've gotten from sources other than the gallery (I
>> don't
>> > know if this is possible at this moment, but it will be someday, right?)
>>
>> No, why is it useful to see themes you've previously installed? I
>> mean, why is it anymore than seeing any other webpage you've
>> previously visited. We already have mechanisms to find things you
>> visited previously. Why does themes need it's own?
>>
>> > (2) Limited to the set of themes you've actually shown interest in by
>> using.
>> >  Think about if the gallery had several thousand themes (the way Firefox
>> has
>> > several thousand Personas).
>>
>> I don't even buy that this would work. You can't tell which themes you
>> like by looking at the picture. I suspect it is more typical to
>> actually try it on for size before deciding it is hideous/awesome.
>>
>> > (3) Usable while offline/unable to access gallery (silly reason).
>>
>> You're right, silly.
>>
>> > The first two are sufficient reasons to me that I've been surprised to
>> not
>> > see this kind of a switch in the WIndows UI.
>>
>> Funny, you recently argued in a different thread (about a different
>> feature request) that the cost for following a link is basically nil,
>> so there shouldn't be any separate UI other than that ;-).
>>
>> Agree right now that installing a theme is slightly higher cost than
>> following a link. But it shouldn't be.
>>
>> On Sun, Aug 9, 2009 at 9:02 PM, PhistucK wrote:
>> > Seeing as there is currently no UI for it other than actually installing
>> a
>> > theme again, I would say the theme selection dropdown is kind of a
>> needed
>> > element.
>>
>> We should change the word "install" to "pick". Why should there be a
>> different UI for re-picking a theme than there is for the initial
>> pick?
>>
>> On Sun, Aug 9, 2009 at 10:04 PM, Caleb Eggensperger
>> wrote:
>> > It would be nice for the UI for "installing" a theme to be the same as
>> > for choosing it again. Maybe the themes directory could have an
>> > "already installed" section, although I think the fact that I've
>> > installed a theme and moved on to another means I'm less interested in
>> > using it again.
>> >
>> > A dropdown would become kinda unmanageable with a large number of
>> > themes, unless there's a way to remove them, and not nearly as usable
>> > as the themes directory is now. What if I can't remember what "legal
>> > pad" looks like?
>>
>> Good points!
>>
>> On Sun, Aug 9, 2009 at 10:13 PM, PhistucK wrote:
>> > I meant it would be nice as a temporary solution, until a
>> chrome://themes
>> > page or something comes up.
>> > And per your wondering - when you mouse over\select a theme with the
>> > keyboard arrows (but no mouse click, nor Enter key press is made), a
>> preview
>> > can be shown, or the whole theme can change.
>> > That would have to make the theme transitioning faster and more fluid,
>> of
>> > course, but that is the intention anyway, so this could be step one.
>> > If you do not

[chromium-dev] Re: Stack traces on layout test crashes

[Jeremy Orlow]

On Sun, Aug 9, 2009 at 9:07 AM, Nicolas Sylvain wrote:

> Some things to consider:
> 1. On windows, breakpad used to be wired in test_shell. And I'm pretty sure
> we used to archive crash dumps for the layout tests too.  It should not be
> hard to do that again. Huan also write a nice script to dump to stdio the
> crashing stacks of all crashes that happened in a buildbot run.  It only
> runs on "chromium xp" for now, but there is no reason why we could not make
> it work for the layout tests. See
> http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/6491/steps/Process%20Dumps/logs/stdio
>  for
> example.
>

I like the idea of leveraging breakpad for crash dumps if possible.  It
seems like that's the best plan and the debug_util code and/or Viet-Trung's
code would be a backup plan if that proved too complicated/hacky.


> 2. The show stopper for any implementation of this feature is that the
> machines running the layout tests don't have the pdbs for test_shell. Since
> the binary is built on another machine, it was too slow to copy the pdbs
> from one machine to another. If you guys think it's important, and can take
> the ~30-60 more seconds to cycle the bots, then we can copy them too, and
> the feature would work.
>

I'm not really sure what the right answer is.  It sure would be nice if we
didn't need to use a tool to decode the call stacks of crashed layout tests.
 I kind of feel like an additional 30-60 seconds isn't going to be a big
deal on these bots, but maybe it is.  What do people think?

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