[chromium-dev] FYI: Linux interactive_ui_tests a bit hosed

[John Abd-El-Malek]

This is related to bug 25997.  The tests are inherently flakey because
singeltons aren't released between runs, so cached MessageLoop pointers are
bogus.  Sometimes they're ok when the order of construction/destruction of
MessageLoop pointers is the same.  But if that changes, or other memory
allocations change, the tests start failing.

Just wanted to send a heads up since I spent a day debugging this last week,
and now they're failing again.

--~--~-~--~~~---~--~~
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: FYI: Linux interactive_ui_tests a bit hosed

[Paweł Hajdan Jr .]

I think that the right fix is to switch interactive_ui_tests to
browser_tests launcher (jcampan did some great work to make the launcher
more flexible, it may be quite simple to do the switch now - if there are no
UI tests in interactive_ui_tests).

I also suggest bumping the priority of http://crbug.com/25997 to P1 and
possibly marking it with FlakyTest label.

On Mon, Nov 2, 2009 at 09:37, John Abd-El-Malek  wrote:

> This is related to bug 25997.  The tests are inherently flakey because
> singeltons aren't released between runs, so cached MessageLoop pointers are
> bogus.  Sometimes they're ok when the order of construction/destruction of
> MessageLoop pointers is the same.  But if that changes, or other memory
> allocations change, the tests start failing.
>
> Just wanted to send a heads up since I spent a day debugging this last
> week, and now they're failing again.
>
> >
>

--~--~-~--~~~---~--~~
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: Compiler warning with Arch Linux and make

[Alexander Teinum]

Success.

Adding 'remove_webcore_debug_symbols' to include.gypi probably solved
my problem (although I did a debug build now). This is the first time
that I have had success compiling Chromium in Arch Linux with make.
And it's also the first time that I have gotten a debug build working
in Arch Linux.

I don't know if it makes any difference, but I built with V=1.

On Sat, Oct 31, 2009 at 3:55 PM, Alexander Teinum  wrote:
> I'm trying to compile Chromium on 64-bit Arch Linux.
>
> It did work fine with SCons in release mode, but it seems like make is
> going to replace SCons from what I have read in the recent
> discussions. I have had a lot of pain compiling Chromium in general,
> because of gperf, generated code, strict aliasing etc. I have still
> not found a solution to those problems. But it did compile with SCons
> when mode was set to release.
>
> I have created ~/.gyp/include.gypi, pasted in the settings from the
> wiki, and set these variables:
>
> export GYP_GENERATORS=make
> export GYP_DEFINES=target_arch=x64
>
> And finally:
>
> gclient sync
> make chrome BUILDTYPE=Release
>
> Here's what happens with any recent, green build:
>
>  CXX(target) out/Release/obj.target/renderer/chrome/renderer/localized_error.o
>  CXX(target) 
> out/Release/obj.target/renderer/chrome/renderer/notification_provider.o
>  CXX(target) 
> out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper.o
>  CXX(target) 
> out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper_linux.o
>  CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_process.o
>  CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_thread.o
> cc1plus: warnings being treated as errors
> In file included from ./chrome/renderer/renderer_webkitclient_impl.h:9,
>                 from chrome/renderer/render_thread.cc:45:
> ./chrome/renderer/websharedworkerrepository_impl.h:10: error:
> declaration ‘struct WebKit::WebSharedWorker’ does not declare anything
> make: *** [out/Release/obj.target/renderer/chrome/renderer/render_thread.o]
> Error 1
>
> Can anyone point me in the right direction?
>
> --
> Best regards,
>
> Alexander Teinum
>



-- 
Best regards/Med vennlig hilsen,

Alexander Teinum

--~--~-~--~~~---~--~~
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: [FYI] Build errors while building Chromium with gcc 4.4.

[Joel Stanley]

2009/11/2 Hironori Bono (坊野 博典) :
> 1. Creating a file "~/.gyp/inclulde.gypi'.
> 2. Adding a following lines to the file.
>
>  {
>'variables': {
>  'no_strict_aliasing': 1
>}
>  }

If you're only building chrome, not the unit_tests target, you can
instead define gcc_version to 44.  This is picked up in v8.gyp to
enable the appropriate flags, but leaves strict aliasing on for the
rest of chrome.

 {
   'variables': {
 'gcc_version': 44,
   }
 }

I figure this is a better option as regressions will be caught as they
are introduced.

Joel

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

[chromium-dev] Compiler warning with Arch Linux and make

[Alexander Teinum]

I'm trying to compile Chromium on 64-bit Arch Linux.

It did work fine with SCons in release mode, but it seems like make is
going to replace SCons from what I have read in the recent
discussions. I have had a lot of pain compiling Chromium in general,
because of gperf, generated code, strict aliasing etc. I have still
not found a solution to those problems. But it did compile with SCons
when mode was set to release.

I have created ~/.gyp/include.gypi, pasted in the settings from the
wiki, and set these variables:

export GYP_GENERATORS=make
export GYP_DEFINES=target_arch=x64

And finally:

gclient sync
make chrome BUILDTYPE=Release

Here's what happens with any recent, green build:

  CXX(target) out/Release/obj.target/renderer/chrome/renderer/localized_error.o
  CXX(target) 
out/Release/obj.target/renderer/chrome/renderer/notification_provider.o
  CXX(target) 
out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper.o
  CXX(target) 
out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper_linux.o
  CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_process.o
  CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_thread.o
cc1plus: warnings being treated as errors
In file included from ./chrome/renderer/renderer_webkitclient_impl.h:9,
 from chrome/renderer/render_thread.cc:45:
./chrome/renderer/websharedworkerrepository_impl.h:10: error:
declaration ‘struct WebKit::WebSharedWorker’ does not declare anything
make: *** [out/Release/obj.target/renderer/chrome/renderer/render_thread.o]
Error 1

Can anyone point me in the right direction?

-- 
Best regards,

Alexander Teinum

--~--~-~--~~~---~--~~
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 much RAM needed to get past linking? (Linux)

[Akira]

Hi,
I was building on Fedora 10 and was able to compile but the
linking stage (see below) consumes more and more memory- the 500Mb of
remaining memory, then another 1Gb of swap- before being killed.


.
Compiling /home/akira/chromium/src/sconsbuild/Debug/obj/chrome/chrome/
app/chrome_exe_main_gtk.o
Compiling /home/akira/chromium/src/sconsbuild/Debug/obj/chrome/chrome/
app/chrome_dll_main.o
Linking /home/akira/chromium/src/sconsbuild/Debug/chrome
collect2: ld terminated with signal 9 [Killed]
scons: *** [/home/akira/chromium/src/sconsbuild/Debug/chrome] Error 1
scons: building terminated because of errors.


I've tried setting the number of scons jobs to be limited to 1
just in case that could help (by 'export SCONSFLAGS="-j 1"') but no
change.

Could other linux users tell me the amount of physical memory on
their machines? I want to find out the minimum successful case.

Regards,

Akira

--~--~-~--~~~---~--~~
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 much RAM needed to get past linking? (Linux)

[Adam Langley]

On Fri, Oct 30, 2009 at 9:10 AM, Akira  wrote:
>    I was building on Fedora 10 and was able to compile but the
> linking stage (see below) consumes more and more memory- the 500Mb of
> remaining memory, then another 1Gb of swap- before being killed.

Are you using gold?

http://code.google.com/p/chromium/wiki/LinuxFasterBuilds#Linking_using_gold

If not, that's the single biggest win for linking size and speed. I
know Evan builds on his laptop using gold, but I don't know the exact
specs.


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: Compiler warning with Arch Linux and make

[Evan Martin]

On Sun, Nov 1, 2009 at 8:01 AM, Alexander Teinum  wrote:
> Success.

That's great!  If you have any notes that would be useful to other
Arch users, please update the instructions on the wiki at
  http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites
(There's a section with distro-specific notes.)

> Adding 'remove_webcore_debug_symbols' to include.gypi probably solved
> my problem (although I did a debug build now). This is the first time
> that I have had success compiling Chromium in Arch Linux with make.
> And it's also the first time that I have gotten a debug build working
> in Arch Linux.

It is possible that your compile problem was a temporary problem that
was fixed.  Our tree tends to break and be repaired pretty rapidly, so
frequently you can run "gclient sync" and discover your problems have
been fixed.

> I don't know if it makes any difference, but I built with V=1.

That shouldn't matter.

--~--~-~--~~~---~--~~
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: Compiler warning with Arch Linux and make

[Craig Schlenter]

As Evan notes, things move quickly :)

What made the difference here is that Joel fixed that error and you
must have updated your tree.

--Craig

On Sun, Nov 1, 2009 at 5:01 PM, Alexander Teinum  wrote:
>
> Success.
>
> Adding 'remove_webcore_debug_symbols' to include.gypi probably solved
> my problem (although I did a debug build now). This is the first time
> that I have had success compiling Chromium in Arch Linux with make.
> And it's also the first time that I have gotten a debug build working
> in Arch Linux.
>
> I don't know if it makes any difference, but I built with V=1.
>
> On Sat, Oct 31, 2009 at 3:55 PM, Alexander Teinum  wrote:
>> I'm trying to compile Chromium on 64-bit Arch Linux.
>>
>> It did work fine with SCons in release mode, but it seems like make is
>> going to replace SCons from what I have read in the recent
>> discussions. I have had a lot of pain compiling Chromium in general,
>> because of gperf, generated code, strict aliasing etc. I have still
>> not found a solution to those problems. But it did compile with SCons
>> when mode was set to release.
>>
>> I have created ~/.gyp/include.gypi, pasted in the settings from the
>> wiki, and set these variables:
>>
>> export GYP_GENERATORS=make
>> export GYP_DEFINES=target_arch=x64
>>
>> And finally:
>>
>> gclient sync
>> make chrome BUILDTYPE=Release
>>
>> Here's what happens with any recent, green build:
>>
>>  CXX(target) 
>> out/Release/obj.target/renderer/chrome/renderer/localized_error.o
>>  CXX(target) 
>> out/Release/obj.target/renderer/chrome/renderer/notification_provider.o
>>  CXX(target) 
>> out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper.o
>>  CXX(target) 
>> out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper_linux.o
>>  CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_process.o
>>  CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_thread.o
>> cc1plus: warnings being treated as errors
>> In file included from ./chrome/renderer/renderer_webkitclient_impl.h:9,
>>                 from chrome/renderer/render_thread.cc:45:
>> ./chrome/renderer/websharedworkerrepository_impl.h:10: error:
>> declaration ‘struct WebKit::WebSharedWorker’ does not declare anything
>> make: *** [out/Release/obj.target/renderer/chrome/renderer/render_thread.o]
>> Error 1
>>
>> Can anyone point me in the right direction?
>>
>> --
>> Best regards,
>>
>> Alexander Teinum
>>
>
>
>
> --
> Best regards/Med vennlig hilsen,
>
> Alexander Teinum
>
> >
>

--~--~-~--~~~---~--~~
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 much RAM needed to get past linking? (Linux)

[Evan Martin]

On Fri, Oct 30, 2009 at 10:10 AM, Akira  wrote:
>    I was building on Fedora 10 and was able to compile but the
> linking stage (see below) consumes more and more memory- the 500Mb of
> remaining memory, then another 1Gb of swap- before being killed.

Are you using gold (the new binutils linker)?  gold is significantly
faster and smaller.
If this problem is caused by using the old linker, we should update
the build instructions to just say that we require gold.

--~--~-~--~~~---~--~~
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 much RAM needed to get past linking? (Linux)

[Paweł Hajdan Jr .]

If you have less than 1 GB of RAM, I wouldn't even try to link the biggest
binaries. 2 GB of RAM should be sufficient, although with 4 and more it's
better. And you will notice the change after switching to gold.

On Mon, Nov 2, 2009 at 18:58, Adam Langley  wrote:

>
> On Fri, Oct 30, 2009 at 9:10 AM, Akira  wrote:
> >I was building on Fedora 10 and was able to compile but the
> > linking stage (see below) consumes more and more memory- the 500Mb of
> > remaining memory, then another 1Gb of swap- before being killed.
>
> Are you using gold?
>
> http://code.google.com/p/chromium/wiki/LinuxFasterBuilds#Linking_using_gold
>
> If not, that's the single biggest win for linking size and speed. I
> know Evan builds on his laptop using gold, but I don't know the exact
> specs.
>
>
> 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: FYI: Linux interactive_ui_tests a bit hosed

[John Abd-El-Malek]

(CCing today's sheriffs + Jay)

I was thinking of marking the bug to P1, except that won't change much if no
one has the time to work on it now.

I think to keep tree green, the entire test should be disabled until
singletons are cleared between each test, or it's switched to browser_tests
launcher.

On Mon, Nov 2, 2009 at 12:44 AM, Paweł Hajdan Jr.
wrote:

> I think that the right fix is to switch interactive_ui_tests to
> browser_tests launcher (jcampan did some great work to make the launcher
> more flexible, it may be quite simple to do the switch now - if there are no
> UI tests in interactive_ui_tests).
>
> I also suggest bumping the priority of http://crbug.com/25997 to P1 and
> possibly marking it with FlakyTest label.
>
> On Mon, Nov 2, 2009 at 09:37, John Abd-El-Malek  wrote:
>
>> This is related to bug 25997.  The tests are inherently flakey because
>> singeltons aren't released between runs, so cached MessageLoop pointers are
>> bogus.  Sometimes they're ok when the order of construction/destruction of
>> MessageLoop pointers is the same.  But if that changes, or other memory
>> allocations change, the tests start failing.
>>
>> Just wanted to send a heads up since I spent a day debugging this last
>> week, and now they're failing again.
>>
>> >>
>>
>

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

[chromium-dev] compile fails on Ubuntu 9.04

[Paweł Hajdan Jr .]

I'm getting this compile error when compiling on Ubuntu 9.04 (scons):

Compiling
/home/ph/chromium/src/sconsbuild/Debug/obj/libxslt/libxslt/libxslt/xsltutils.o
Generating version information
Creating library /home/ph/chromium/src/sconsbuild/Debug/lib/libxslt.a
Indexing /home/ph/chromium/src/sconsbuild/Debug/lib/libxslt.a
Compiling
/home/ph/chromium/src/sconsbuild/Debug/obj/base/linux_versioninfo/file_version_info_linux.o
scons: ***
[/home/ph/chromium/src/sconsbuild/Debug/obj/yasm/genmacro/source/patched-yasm/tools/genmacro/genmacro.o]
Source
`/home/ph/chromium/src/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.c'
not found, needed by target
`/home/ph/chromium/src/sconsbuild/Debug/obj/yasm/genmacro/source/patched-yasm/tools/genmacro/genmacro.o'.
scons: building terminated because of errors.

This is the first time I'm compiling Chrome on that system (it's inside a
virtual machine). Do you have some idea how to fix the problem? I've run
install-build-deps.sh.

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

[chromium-dev] Chromium security UI choices

[Mike Hearn]

Hiya,

I'm not sure if chromium-dev is the right place for this discussion as
it's a bit vague. Please don't hesitate to redirect me if not.

I'm concerned about the way Chromium displays SSL security indicators,
which this blog post reminded me about:

   http://chrome.blogspot.com/2009/10/are-you-seeing-red.html

There have been a few studies of SSL usability and the conclusions are
that Chrome-style UI does not work. For example see Dhamija, Tygar and
Hearst:

   http://portal.acm.org/citation.cfm?id=1124861

Specific issues raised are:

1) Terms like "certificate" are not understood and ignored. Bad cert
errors are clicked through.

2) Use of a lock icon as a positive security indicator is easily
forged by putting a lock picture in the web page itself. Users do not
understand what parts of the browser UI are trustable and which are
not.

3) Use of colored address bars is easily confused with the aesthetic
choices of the website designer.

4) Visual complexity is used as a metric for "how hard it is to copy",
eg favicons or animations in the web page make things look authentic

5) Many users don't look for security indicators at all and have a
poor or non-existent understanding of what the elements of a URL mean.

I don't have any great ideas about this, but it seems like something
Chrome could do better much than the competition.

Possibilities that come to mind are:

- Showing some permanent status indicator of "insecurity" that visibly
changes, eg with a very noticeable animation, when tab status changes.

- Replacing the entire contents of the URL bar with the organization
name when an EV cert is present rather than displaying both.

- Use of "cheap" negative trust indicators, for instance if a page
matches the regex "Bank of America" and is not the well known site a
small bar or bubble could appear that says "This website is not owned
by Bank of America". This would obviously have a high false positive
rate, but that's OK because it simply asserts a negative rather than a
positive. Obviously the real regexs would be based on the contents of
the actual BoA website rather than a simple phrase.

What do you think? Should I take this to chromium-discuss?

thanks -mike
--~--~-~--~~~---~--~~
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: compile fails on Ubuntu 9.04

[Mark Mentovai]

Paweł Hajdan Jr. wrote:
> scons: *** 
> [/home/ph/chromium/src/sconsbuild/Debug/obj/yasm/genmacro/source/patched-yasm/tools/genmacro/genmacro.o]
> Source 
> `/home/ph/chromium/src/third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.c'
>  not found, needed by target 
> `/home/ph/chromium/src/sconsbuild/Debug/obj/yasm/genmacro/source/patched-yasm/tools/genmacro/genmacro.o'.
> scons: building terminated because of errors.

That file, third_party/yasm/source/patched-yasm/tools/genmacro/genmacro.c,
should be part of the checkout.  gclient should have brought it in via
the DEPS entry for src/third_party/yasm/source/patched-yasm.  If you
don't have that file, start looking at how things were checked out,
and maybe try a "gclient sync --force".

Mark

--~--~-~--~~~---~--~~
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: Chromium security UI choices

[Peter Kasting]

+CC Ian Fette, our security PM.

None of the issues you raise are new; we've considered them for a couple of
years.

In general I agree that positive security indicators are designed around the
idea that users should be alarmed by something's _absence_, which doesn't
work well with how people process things.  Unfortunately, the negative
security indicators suffer from the problem that they will appear
near-constantly and users will quickly tune them out.

My personal opinion is that much of the problem stems from the false
conflation of "SSL" and "secure" in past and present browser UIs.  I don't
think SSL is either comprehensible or relevant enough to users that we
should do things like color address bars and display lock icons.  Instead,
it should be one element in a larger equation of "is this site trustworthy".
 Note that when you click on the Chrome lock icon we do show you a couple of
different pieces of information to help you decide, but this could be
better.

I applaud Mozilla for having tried to tackle this a bit in their UI.  I
think it is superior to ours.

On Mon, Nov 2, 2009 at 12:23 PM, Mike Hearn  wrote:

> 3) Use of colored address bars is easily confused with the aesthetic
> choices of the website designer.
>

The fact that we color our address bar is a continual pet peeve of mine.  I
have pushed for its removal since its inception.  I will happily champion
patches to get rid of it.

Colored address bars overstate the importance of an HTTPS connection, reduce
readability, and confuse people.  It's no accident that basically all other
vendors have steadily moved away from coloring the whole bar.

4) Visual complexity is used as a metric for "how hard it is to copy",
> eg favicons or animations in the web page make things look authentic
>

This isn't really a point that's relevant to Chrome itself, but to web page
authors.

5) Many users don't look for security indicators at all and have a
> poor or non-existent understanding of what the elements of a URL mean.
>

I do think our host-versus-everything-else coloring in the address bar helps
with phishing URLs even if users can't articulate what the different colored
sections are.

- Showing some permanent status indicator of "insecurity" that visibly
> changes, eg with a very noticeable animation, when tab status changes.
>

I believe this will just add visual noise people will tune out.

- Replacing the entire contents of the URL bar with the organization
> name when an EV cert is present rather than displaying both.
>

This suffers from a number of problems, especially with editing URLs (there
are fixes to make the real URL "magically" appear when you focus the address
bar, but they feel gross), as well as obscuring your location on a site.

- Use of "cheap" negative trust indicators, for instance if a page
> matches the regex "Bank of America" and is not the well known site a
> small bar or bubble could appear that says "This website is not owned
> by Bank of America". This would obviously have a high false positive
> rate, but that's OK because it simply asserts a negative rather than a
> positive.


In addition to the "false positives make users ignore the metric" obvious
problems, this implicitly has false negatives since we can't do this for
every site on the web and if users grow to trust it they are at higher risk
when on pages for which we don't provide this.

Sadly, good UI for security is extremely difficult.

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] [Mac] Make sure you're working on M4 P1 bugs

[Mike Pinkerton]

Our goal for this Friday is to be able to count our Mac P1 M4 release
blocker bugs on one hand (we're in the 20s now).

To that end, everyone should have their P1 list practically at zero by
the end of this week. If you are not going to be able to reach this,
let me (or other triage folk) know ASAP so that we can get you some
help. Letting us know on Friday doesn't do much good.

Email if you have any questions!

-- 
Mike Pinkerton
Mac Weenie
pinker...@google.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: Chromium security UI choices

[John Munro]

> I do think our host-versus-everything-else coloring in the address bar helps
> with phishing URLs even if users can't articulate what the different colored
> sections are.

Would this be a good time to revisit this issue:

http://code.google.com/p/chromium/issues/detail?id=1971

Both Firefox and IE highlight the domain and not the subdomain to help
the user spot phishing like http://yourbank.com.badsite.com/ but
Chrome does not.

John
--~--~-~--~~~---~--~~
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: Chromium security UI choices

[Peter Kasting]

On Mon, Nov 2, 2009 at 1:10 PM, John Munro  wrote:

> > I do think our host-versus-everything-else coloring in the address bar
> helps
> > with phishing URLs even if users can't articulate what the different
> colored
> > sections are.
>
> Would this be a good time to revisit this issue:
>
> http://code.google.com/p/chromium/issues/detail?id=1971


No, there really hasn't been anything new that would change the decision
there.

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: Chromium security UI choices

[Erik Kay]

On Mon, Nov 2, 2009 at 11:23 AM, Mike Hearn  wrote:
> - Use of "cheap" negative trust indicators, for instance if a page
> matches the regex "Bank of America" and is not the well known site a
> small bar or bubble could appear that says "This website is not owned
> by Bank of America". This would obviously have a high false positive
> rate, but that's OK because it simply asserts a negative rather than a
> positive. Obviously the real regexs would be based on the contents of
> the actual BoA website rather than a simple phrase.

The malware and phishing system does a pretty good job of detecting
phishing sites like this, which we get notified of via SafeBrowsing,
which we then wind up putting a full red page road block in the way
when the user tries to navigate to them, so I don't think there's much
else we should be doing on this particular issue.

Erik

--~--~-~--~~~---~--~~
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: Chromium security UI choices

[Mike Hearn]

> The malware and phishing system does a pretty good job of detecting
> phishing sites like this, which we get notified of via SafeBrowsing

SafeBrowsing is a great system, but it ultimately relies on savvy
users telling us that a site is phishing. Some scams are sufficiently
good that the majority of users don't notice. For instance the paper I
linked found that some phishing attacks had a greater than 90% success
rate.

Anecdotally, I've manually reported two Facebook related phishing scam
sites (by the same people) that didn't enter SafeBrowsing for multiple
days, probably because they were very sophisticated and not enough
users reported them as phishing.

I agree that the biggest problem with negative indicators is false
positives, though given that a good phish needs to be very close to
the real website, I suspect a regex/phrase based approach could be
pretty well tuned. Phishers would of course tweak their site until the
warnings did not trigger, but they'd have to deviate significantly
from the real site, which should lower their success rate with high
profile targets like banks or facebook.

I disagree that the padlock animation would be adding visual noise,
the existing static padlock is already visual noise - people don't
understand it, so replacing it with something more noticeable that is
harder to forge can only increase its effectiveness.

It also provides an opportunity to educate the user a bit - if the
padlock animation includes the words "Secure" or "verified to be
yourbank.com" or whatever, they don't have to remain on the screen
permanently ... they could fade out after a few seconds in such a way
that it's obvious where to click to learn more or get them back (eg a
bubble). That way the meaning of the padlock becomes more obvious and
it doesn't rely on people getting the (fairly ropey) analogy.
--~--~-~--~~~---~--~~
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: Chromium security UI choices

[Peter Kasting]

On Mon, Nov 2, 2009 at 2:28 PM, Mike Hearn  wrote:

> I disagree that the padlock animation would be adding visual noise,
>

I wasn't commenting about the animation, rather the presence of an indicator
on "normal" sites.

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: Chromium security UI choices

[Mike Hearn]

[repost with my actual signup address]

> Ah, I see. Yeah, I agree, that would clutter Chrome a bit.
>
> I'm not sure what direction to look in then. Things like SafeBrowsing
> suffer from the imperfect protection problem, but they are still worth
> doing. Only showing indicators when the site identity is strongly
> verified requires the user to pro-actively think about security, which
> we know doesn't happen.
>
> I think replacing the contents of the URL bar does still have promise.
> 99% of the time it's full of unreadable junk anyway, so it feels like
> the lowest hanging fruit for both cleaning up browser UI and improving
> security in one go.
>

--~--~-~--~~~---~--~~
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: readability extension (experience writeup)

[Evan Martin]

On Sat, Oct 31, 2009 at 3:41 PM, Aaron Boodman  wrote:
>>  - The docs are behind the code (had to read the code once or twice to
>> figure out what was going wrong).
>
> Were you using trunk or dev?

I was using dev.  I think I just searched on Google and clicked
through to whichever docs I found -- I didn't realize there were two
sets.  Should we always point users to trunk until extensions are in
beta?

But yes, the trunk docs look great, and I see they've also addressed
my prior complaint about organization.

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

[chromium-dev] refactoring and git

[Drew Wilson]

Hi all,

I'm doing some refactoring in the chromium worker code, and I got the
following review feedback:

"small request: can the files that were branched from existing files be "svn
copy'd" instead of copying manually and "svn added"?  This will preserve
history
and will make it easier to see what changed in the review."

Is there a way to do this with git? I do want to make my reviewers happy :)

-atw

--~--~-~--~~~---~--~~
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: refactoring and git

[Evan Martin]

On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson  wrote:
> I'm doing some refactoring in the chromium worker code, and I got the
> following review feedback:
> "small request: can the files that were branched from existing files be "svn
> copy'd" instead of copying manually and "svn added"?  This will preserve
> history
> and will make it easier to see what changed in the review."
> Is there a way to do this with git? I do want to make my reviewers happy :)

Git has an ...odd... way of thinking about renames.  The pieces you
need to know are:
1) Does git believe you did a rename?  Consult "git diff -M -C --stat
origin..." and see if it prints renames.
2) If no, ping me off-list and I'll help you out.
3) If yes, Rietveld should be able to display the diff properly.
However, this code is relatively untested (we have to convert the Git
renames into SVN-style "renames" -- SVN doesn't actually support true
renames, oddly enough) so it could be wrong.  In that case, also ping
me off-list.  :)

--~--~-~--~~~---~--~~
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: Chromium security UI choices

[Adam Barth]

On Mon, Nov 2, 2009 at 11:23 AM, Mike Hearn  wrote:
> I'm concerned about the way Chromium displays SSL security indicators,
> which this blog post reminded me about:
>
>   http://chrome.blogspot.com/2009/10/are-you-seeing-red.html
>
> There have been a few studies of SSL usability and the conclusions are
> that Chrome-style UI does not work. For example see Dhamija, Tygar and
> Hearst:
>
>   http://portal.acm.org/citation.cfm?id=1124861

I agree that our certificate error UI can be improved.  If you have
concrete suggestions, the best way to make your case is to write an
academic paper and conduct a user study that shows how the new UI
out-performs the current UI.  Failing that, putting together a nice
set of mocks and a coherent argument are good ways to make your case.

One thing that we are doing in Chrome 4 is implementing Strict
Transport Security, which is a security feature that lets
high-security sites opt out of these error pages:

http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html

Adam

--~--~-~--~~~---~--~~
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: Inheritance in gyp configurations

[王重傑]

On Sun, Nov 1, 2009 at 3:26 PM, Bradley Nelson wrote:

>   1) Do you support multiple inheritance?  I notice the "inherit_from" is
>> specified as an array.  That's scaryish.
>>
> Multiple inheritance is supported, not sure it's wise to use, but well gyp
> has lots of features like that :-)
> I almost didn't support it, but concluded that, for instance 64-bit, might
> have a common set of configuration properties that you'd want to mix-in to a
> given config.
>
>
>>   2) If you do have multiple inheritance, how are conflicts handled? Are
>> they just rejected, or is there a pre-defined name resolution order?  What
>> would you do with diamond shapes?
>>
> Names are resolved based on the order in which parent classes are listed
> after 'inherit_from'. Parent classes are applied depth first, and only the
> first instance of a parent gets applied. So for example:
>
>Base
>   /\\
> A  B   C
>   \ //
> D
>
> Names are picked in this order: D, C, B, A, Base.
>
> I'm not wedded to this arrangement (in fact I'm generally skeptical of
> multiple inheritance).
> I definitely think that in practice diamond inheritance should be avoided,
> but I can imagine some cases were it might make sense.
> I think in general we should try to have a single primary tree and mix-ins
> for simple self contained features.
>

So, I'm tempted to go two routes...none great.
  a) disallow multiple inheritance initially.  Until someone demonstrates a
need, don't add it.
  b) validate the full inheritance tree to ensure there are no name
collisions.  I think this becomes less trivial because of the conditional
inherit below.  Though, I guess this static checking phase could also reject
conditional inherits (which I'm a bit of a fan of).

(a) Feels like the best initial route IMO.  Going (b) sounds nice in theory,
but in other systems that I've used which reject collisions, it makes
configuration maintenance pretty annoying.

In the end, what I think would really help is actually a config differ.
 Basically, so I can do
   gyp printtree all.gyp
   gyp printtree all.gyp_with_changes

and then diff the output, after various bits.  Don't know if something like
this already exists.

-Albert


  3) Is there a way to reference "super", or various ancestors?
>>
> No.
> This gets implemented as merging (similar to target_defaults), so nothing
> is left of the ancestors from the point of view of their descendants.
>
>
>>   4) How does this interact with late-resolution variables?
>>
> Late resolution variables are expanded after inheritance.
> There are serious limitations on what can happen in a configuration,
> however, so I'm hard pressed to imagine a case where you'd be able to use
> late-resolution in the context of a configuration.
>
>
>>   5) How about conditionals?  Can we conditionally inherit?
>>
> Conditionals are expanded before inheritance is applied, so you could in
> principle make it conditional.
> This is already being used in a related context (the Purify configuration
> only exists for windows).
> It might make sense with inheritance, but probably would be a bad idea.
> It's supported largely as a side effect of normal gyp expansion.
>
> If you feel strongly, we could take it out. I'm on the fence as to whether
> its dangerous in the unusual context in which it applies to gyp.
> Let me know. :-)
>
> -BradN
>
>
>
>> -Albert
>>
>>
>> On Thu, Oct 29, 2009 at 5:42 PM, Bradley Nelson wrote:
>>
>>> configurations can now inherit from one or more other configurations, and
>>> configurations which are not fully expressed should be marked 'abstract': 1,
>>>
>>> So something like this:
>>>
>>> 'configurations': {
>>>   'Common: {
>>>  'abstract': 1,
>>>  # common settings
>>>   },
>>>   'Debug': {
>>>  'inherit_from': ['Common'],
>>>  # Debug specific
>>>   },
>>>   'Release': {
>>>  'inherit_from': ['Common'],
>>>  # Release specific
>>>   },
>>> },
>>>
>>> -BradN
>>>
>>> On Thu, Oct 29, 2009 at 5:37 PM, Nick Carter  wrote:
>>>
 What does the syntax look like?

  - nick

 On Thu, Oct 29, 2009 at 3:22 PM, Bradley Nelson 
 wrote:

> Hi All,
>
> I've just rolled out an enhancement to gyp to support inheritance in
> configurations.
> This shouldn't have any noticeable effect other than reducing the
> repetition needed for things like Purify/notcmalloc.
>
> I've tested it as best I can, but please let me know if you experience
> anything strange with Debug vs Release or with Purify/notcmalloc.
>
> This was primarily meant as a baby step towards supporting x64
> configurations in gyp on windows, but I thought I'd let this part soak
> first.
>
> -BradN
>
>
>
>

>>>
>>> >>>
>>>
>>
>

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

[chromium-dev] Re: readability extension (experience writeup)

[Kathy]

> I was using dev.  I think I just searched on Google and clicked
> through to whichever docs I found -- I didn't realize there were two
> sets.  Should we always point users to trunk until extensions are in
> beta?

I don't think we can, since the generated API docs need to match
whatever the user's most likely to be using (in this case, dev; in the
future, beta).

However... We should advertise somewhere that you can look at
different versions of the doc. Maybe in an "about this doc" section at
the bottom of the front page, or maybe in the sidenav.

> But yes, the trunk docs look great, and I see they've also addressed
> my prior complaint about organization.

Cool. It's great to hear that.

-k-
--~--~-~--~~~---~--~~
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: Inheritance in gyp configurations

[Mark Mentovai]

We've got the "gypd" (d = debug) sorta-generator format as an option,
alongside xcode, msvs, make, etc.  It dumps the dicts it receives as
.gypd files next to your .gyp files, so you can see what would be fed
to a generator.  You might need to feed it some -D because it's not
tied to an OS by default.

Albert J. Wong (王重傑) wrote:
> On Sun, Nov 1, 2009 at 3:26 PM, Bradley Nelson 
> wrote:
>>>
>>>   1) Do you support multiple inheritance?  I notice the "inherit_from" is
>>> specified as an array.  That's scaryish.
>>
>> Multiple inheritance is supported, not sure it's wise to use, but well gyp
>> has lots of features like that :-)
>> I almost didn't support it, but concluded that, for instance 64-bit, might
>> have a common set of configuration properties that you'd want to mix-in to a
>> given config.
>>
>>>
>>>   2) If you do have multiple inheritance, how are conflicts handled? Are
>>> they just rejected, or is there a pre-defined name resolution order?  What
>>> would you do with diamond shapes?
>>
>> Names are resolved based on the order in which parent classes are listed
>> after 'inherit_from'. Parent classes are applied depth first, and only the
>> first instance of a parent gets applied. So for example:
>>    Base
>>       /\    \
>>     A  B   C
>>       \ /    /
>>         D
>> Names are picked in this order: D, C, B, A, Base.
>> I'm not wedded to this arrangement (in fact I'm generally skeptical of
>> multiple inheritance).
>> I definitely think that in practice diamond inheritance should be avoided,
>> but I can imagine some cases were it might make sense.
>> I think in general we should try to have a single primary tree and mix-ins
>> for simple self contained features.
>
> So, I'm tempted to go two routes...none great.
>   a) disallow multiple inheritance initially.  Until someone demonstrates a
> need, don't add it.
>   b) validate the full inheritance tree to ensure there are no name
> collisions.  I think this becomes less trivial because of the conditional
> inherit below.  Though, I guess this static checking phase could also reject
> conditional inherits (which I'm a bit of a fan of).
> (a) Feels like the best initial route IMO.  Going (b) sounds nice in theory,
> but in other systems that I've used which reject collisions, it makes
> configuration maintenance pretty annoying.
> In the end, what I think would really help is actually a config differ.
>  Basically, so I can do
>    gyp printtree all.gyp
>    gyp printtree all.gyp_with_changes
> and then diff the output, after various bits.  Don't know if something like
> this already exists.
> -Albert
>
>>>   3) Is there a way to reference "super", or various ancestors?
>>
>> No.
>> This gets implemented as merging (similar to target_defaults), so nothing
>> is left of the ancestors from the point of view of their descendants.
>>
>>>
>>>   4) How does this interact with late-resolution variables?
>>
>> Late resolution variables are expanded after inheritance.
>> There are serious limitations on what can happen in a configuration,
>> however, so I'm hard pressed to imagine a case where you'd be able to use
>> late-resolution in the context of a configuration.
>>
>>>
>>>   5) How about conditionals?  Can we conditionally inherit?
>>
>> Conditionals are expanded before inheritance is applied, so you could in
>> principle make it conditional.
>> This is already being used in a related context (the Purify configuration
>> only exists for windows).
>> It might make sense with inheritance, but probably would be a bad idea.
>> It's supported largely as a side effect of normal gyp expansion.
>> If you feel strongly, we could take it out. I'm on the fence as to whether
>> its dangerous in the unusual context in which it applies to gyp.
>> Let me know. :-)
>> -BradN
>>
>>>
>>> -Albert
>>>
>>> On Thu, Oct 29, 2009 at 5:42 PM, Bradley Nelson 
>>> wrote:

 configurations can now inherit from one or more other configurations,
 and configurations which are not fully expressed should be marked
 'abstract': 1,
 So something like this:

 'configurations': {
   'Common: {
      'abstract': 1,
      # common settings
   },
   'Debug': {
      'inherit_from': ['Common'],
      # Debug specific
   },
   'Release': {
      'inherit_from': ['Common'],
      # Release specific
   },
 },
 -BradN
 On Thu, Oct 29, 2009 at 5:37 PM, Nick Carter  wrote:
>
> What does the syntax look like?
>  - nick
>
> On Thu, Oct 29, 2009 at 3:22 PM, Bradley Nelson 
> wrote:
>>
>> Hi All,
>> I've just rolled out an enhancement to gyp to support inheritance in
>> configurations.
>> This shouldn't have any noticeable effect other than reducing the
>> repetition needed for things like Purify/notcmalloc.
>> I've tested it as best I can, but please let me know if you experience
>> anything strange with Debug vs Release or with Purify/notcmalloc.
>>>

[chromium-dev] Re: Inheritance in gyp configurations

[Bradley Nelson]

S,o as it happens, I just had someone on nacl make the first use of multiple
inheritance this morning.
He hasn't checked it in yet, but the use case is:

'Common': {
  # bunch of global stuff
  'defines': [
# bunch of 32-bit defines.
  ],
},
'Debug': {
  # bunch of general debug stuff assumes 32-bit
  'inherit_from': ['Common'],
},
'Release': {
  # bunch of general release stuff assumes 32-bit
  'inherit_from': ['Common'],
},
'Common_x64': {
  # Customizations to change 32-bit -> 64-bit
  'abstract': 1,
  'defines!': [
# bunch of 32-bit defines
  ],
  'defines': [
 # bunch of 64-bit defines
  ],
},
'Debug_x64': {
  'inherit_from': ['Debug', 'Common_x64'],
},
'Release_x64': {
  'inherit_from': ['Release', 'Common_x64'],
},

This use case seems reasonable enough.
It might fit into something like (b), but at least as currently conceived,
'Common_x64' has overrides of stuff in 'Common'.
It might be possible to refactor Common and Common_x64 to avoid collisions,
maybe pull out all the 32-bit stuff into Common_x86 and leave Common with
truly common stuff. On the other hand, the current arrangement allowed a
fairly small modification while 64-bit is being experimented with.
Suggestions?

-BradN


On Mon, Nov 2, 2009 at 3:12 PM, Mark Mentovai  wrote:

> We've got the "gypd" (d = debug) sorta-generator format as an option,
> alongside xcode, msvs, make, etc.  It dumps the dicts it receives as
> .gypd files next to your .gyp files, so you can see what would be fed
> to a generator.  You might need to feed it some -D because it's not
> tied to an OS by default.
>
> Albert J. Wong (王重傑) wrote:
> > On Sun, Nov 1, 2009 at 3:26 PM, Bradley Nelson 
> > wrote:
> >>>
> >>>   1) Do you support multiple inheritance?  I notice the "inherit_from"
> is
> >>> specified as an array.  That's scaryish.
> >>
> >> Multiple inheritance is supported, not sure it's wise to use, but well
> gyp
> >> has lots of features like that :-)
> >> I almost didn't support it, but concluded that, for instance 64-bit,
> might
> >> have a common set of configuration properties that you'd want to mix-in
> to a
> >> given config.
> >>
> >>>
> >>>   2) If you do have multiple inheritance, how are conflicts handled?
> Are
> >>> they just rejected, or is there a pre-defined name resolution order?
>  What
> >>> would you do with diamond shapes?
> >>
> >> Names are resolved based on the order in which parent classes are listed
> >> after 'inherit_from'. Parent classes are applied depth first, and only
> the
> >> first instance of a parent gets applied. So for example:
> >>Base
> >>   /\\
> >> A  B   C
> >>   \ //
> >> D
> >> Names are picked in this order: D, C, B, A, Base.
> >> I'm not wedded to this arrangement (in fact I'm generally skeptical of
> >> multiple inheritance).
> >> I definitely think that in practice diamond inheritance should be
> avoided,
> >> but I can imagine some cases were it might make sense.
> >> I think in general we should try to have a single primary tree and
> mix-ins
> >> for simple self contained features.
> >
> > So, I'm tempted to go two routes...none great.
> >   a) disallow multiple inheritance initially.  Until someone demonstrates
> a
> > need, don't add it.
> >   b) validate the full inheritance tree to ensure there are no name
> > collisions.  I think this becomes less trivial because of the conditional
> > inherit below.  Though, I guess this static checking phase could also
> reject
> > conditional inherits (which I'm a bit of a fan of).
> > (a) Feels like the best initial route IMO.  Going (b) sounds nice in
> theory,
> > but in other systems that I've used which reject collisions, it makes
> > configuration maintenance pretty annoying.
> > In the end, what I think would really help is actually a config differ.
> >  Basically, so I can do
> >gyp printtree all.gyp
> >gyp printtree all.gyp_with_changes
> > and then diff the output, after various bits.  Don't know if something
> like
> > this already exists.
> > -Albert
> >
> >>>   3) Is there a way to reference "super", or various ancestors?
> >>
> >> No.
> >> This gets implemented as merging (similar to target_defaults), so
> nothing
> >> is left of the ancestors from the point of view of their descendants.
> >>
> >>>
> >>>   4) How does this interact with late-resolution variables?
> >>
> >> Late resolution variables are expanded after inheritance.
> >> There are serious limitations on what can happen in a configuration,
> >> however, so I'm hard pressed to imagine a case where you'd be able to
> use
> >> late-resolution in the context of a configuration.
> >>
> >>>
> >>>   5) How about conditionals?  Can we conditionally inherit?
> >>
> >> Conditionals are expanded before inheritance is applied, so you could in
> >> principle make it conditional.
> >> This is already being used in a related context (the Purify
> configuration
> >> only exists for windows).
> >> It might make sense with inheritance, but probably would

[chromium-dev] Re: browser/sync test fixit next week [Nov 2 - 6]

[Tim Steele]

Just a reminder, this is happening now!

On Fri, Oct 30, 2009 at 1:14 PM, Tim Steele  wrote:

> Hello!
>
> A heads-up that folks working on sync will be holding a test fixit next
> week, Nov 2 - 6.  The motivation is to improve test coverage of our code, as
> there are many more chunks without any unit-test coverage whatsoever than
> there should be.  The sync integration tests do tickle *most *of the code,
> but these take a lot more time and effort to run and debug, can't run on the
> public buildbot (yet!), and they also need TLC themselves because they have
> flakiness issues.  We have a list of things to 
> tackle,
> some of the "add tests here!" variety, and some are "make this thing more
> testable".  Some require a pretty strong understanding of all the pieces in
> the system, and might not be suitable for a first-time dive into the sync
> engine :). But there is more generic low hanging fruit available as well!
>
> We are going to try to focus exclusively on these issues next week, which
> are filed under 'Feature-Sync' and 'Fixit'. [barring any emergencies of
> course, knock on wood!]
>
>  Here is the list again:
> http://code.google.com/p/chromium/issues/list?can=2&q=Feature-Sync+fixit.
>  We may add more today/early next week, so make sure to check back!
> If you need a hand getting started or a bug you are interested in is
> unclear, folks on the cc-list or myself would be happy to try and shed some
> light for you.
>
> And remember, debugging sucks. Testing rocks!
> Tim
>

--~--~-~--~~~---~--~~
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: Chromium security UI choices

[Evan Stade]

I now have a new response ready for the next "click to select all" thread:

"the best way to make your case is to write an academic paper and
conduct a user study that shows how the new UI out-performs the
current UI."

-- Evan Stade

--~--~-~--~~~---~--~~
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: Chromium security UI choices

[Adam Barth]

I'm sorry if my email came off as dismissive.  I really would like to
see some serious study of user interfaces for certificate errors.  I
think everyone agrees that the current designs can be improved.  We
even know how to measure success (e.g.,
http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf).
What we don't know is how to design something measurably better.

Adam


On Mon, Nov 2, 2009 at 6:19 PM, Evan Stade  wrote:
> I now have a new response ready for the next "click to select all" thread:
>
> "the best way to make your case is to write an academic paper and
> conduct a user study that shows how the new UI out-performs the
> current UI."
>
> -- Evan Stade
>

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

[chromium-dev] Changes to using threads in the browser process

[John Abd-El-Malek]

Over the last week, I've been making some changes to how threads are used in
the browser process, with the goal of simplifying cross-thread access and
improving stability.

*The problem*
We were using a number of patterns that were problematic:

1) using ChromeThread::GetMessageLoop
  -this isn't safe, since it could return a valid pointer, but since the
caller isn't holding on to a lock anymore, the target MessageLoop could be
destructed while it's being used

2) caching of MessageLoop pointers in order to use them later for PostTask
and friends
  -this was more efficient previously (more on that later) since using
ChromeThread::GetMessageLoop involved a lock
  -but it spread logic about the order of thread destruction all over the
code.  Code that moved from the IO thread to the file thread and back, in
order to avoid doing disk access on the IO thread, ended up having to do an
extra hop through the UI thread on the way back to the IO thread since the
file thread outlives the Io thread.  Of course, most code learnt this the
hard way, after doing the straight forward IO->file->IO thread hop and
updating the code after seeing reliability or user crashes
  -it made the browser shutdown fragile and hence difficult to update

3) file thread hops using RefCountedThreadSafe objects which have
non-trivial destructors
  -to reduce jank, frequently an object on the UI or IO thread would execute
some code on the file thread, then post the result back to the original
thread.  We make this easy using RefCountedThreadSafe and NewRunnableMethod
so this pattern happened often, but it's not always safe: NewRunnableMethod
holds an extra reference on the object to ensure that it doesn't invoke a
method on a deleted object.  But it's quite possible that before the file
thread's stack unwinds and it releases the extra reference, that the
response task on the original thread executed and released its own
additional reference.  The file thread is then left with the remaining
reference and the object gets destructed there.  While for most objects this
is ok, many have non-trivial destructors, with the worst being ones that
register with the per-thread NotificationService.  Dangling pointers would
be left behind and tracking these crashes from ChromeBot or the crash dumps
has wasted several days at least for me.

4) having browser code take different code paths if a thread didn't exist
  -this could be either deceptively harmless  (i.e. execute synchronously
when it was normally asynchronous), when in fact it makes shutdown slower
because disk access is moved to the UI thread
  -it could lead to data loss, if tasks are silently not posted because the
code assumes this only happens in unit tests, when it could occur on browser
shutdown as well


*The solution*
1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask,
DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed
if the target thread is known to outlive the current thread.  The four
static methods have the same signature as the ones from MessageLoop, with
the addition of the first parameter to indicate the target thread.

ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task);

3: If your object must be destructed on a specific thread, use a trait from
ChromeThread:

class Foo : public base::RefCountedThreadSafe

4: I've removed all the special casing and always made the objects in the
browser code behave in one way.  If you're writing a unit test and need to
use an object that goes to a file thread (where before it would proceed
synchronously), you just need:

ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current());
foo->StartAsyncTaskOnFileThread();
MessageLoop::current()->RunAllPending();

There are plenty of examples now in the tests.


*Gotchas*
-PostTask will silently delete a task if the thread doesn't exist.  This is
done to avoid having all the code that uses it have special cases if the
target thread exists or not, and to make Valgrind happy.  As usual, the task
for DeleteSoon/ReleaseSoon doesn't do anything in its destructor, so this
won't cause unexpected behavior with them.  But be wary of posted Task
objects which have non-trivial destructors or smart pointers as members.
 I'm still on the fence about this, since while the latter is theoretical
now, it could lead to problems in the future.  I might change it so that the
tasks are not deleted when I'm ready for more Valgrind fun.

If you absolutely must know if a task was posted or not, you can check the
return value of PostTask and friends.  But note that even if the task was
posted successfully, there's no guarantee that it will run because the
target thread could already have a QuitTask queued up.

g_browser->io_thread() and file_thread() are still around (the former for
IPC code, and the latter for Linux proxy code which is in net and so can't
use ChromeThread).  Don't use them unless absolutely necessary.


*The Catch*
Ensuring we don't fall back into our o

[chromium-dev] Re: Changes to using threads in the browser process

[Huan Ren]

Cool! I could compare the builds before and after these changes to see
what difference it makes. Of course it also prevents future issues.

Huan

On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek  wrote:
> Over the last week, I've been making some changes to how threads are used in
> the browser process, with the goal of simplifying cross-thread access and
> improving stability.
> The problem
> We were using a number of patterns that were problematic:
> 1) using ChromeThread::GetMessageLoop
>   -this isn't safe, since it could return a valid pointer, but since the
> caller isn't holding on to a lock anymore, the target MessageLoop could be
> destructed while it's being used
> 2) caching of MessageLoop pointers in order to use them later for PostTask
> and friends
>   -this was more efficient previously (more on that later) since using
> ChromeThread::GetMessageLoop involved a lock
>   -but it spread logic about the order of thread destruction all over the
> code.  Code that moved from the IO thread to the file thread and back, in
> order to avoid doing disk access on the IO thread, ended up having to do an
> extra hop through the UI thread on the way back to the IO thread since the
> file thread outlives the Io thread.  Of course, most code learnt this the
> hard way, after doing the straight forward IO->file->IO thread hop and
> updating the code after seeing reliability or user crashes
>   -it made the browser shutdown fragile and hence difficult to update
> 3) file thread hops using RefCountedThreadSafe objects which have
> non-trivial destructors
>   -to reduce jank, frequently an object on the UI or IO thread would execute
> some code on the file thread, then post the result back to the original
> thread.  We make this easy using RefCountedThreadSafe and NewRunnableMethod
> so this pattern happened often, but it's not always safe: NewRunnableMethod
> holds an extra reference on the object to ensure that it doesn't invoke a
> method on a deleted object.  But it's quite possible that before the file
> thread's stack unwinds and it releases the extra reference, that the
> response task on the original thread executed and released its own
> additional reference.  The file thread is then left with the remaining
> reference and the object gets destructed there.  While for most objects this
> is ok, many have non-trivial destructors, with the worst being ones that
> register with the per-thread NotificationService.  Dangling pointers would
> be left behind and tracking these crashes from ChromeBot or the crash dumps
> has wasted several days at least for me.
> 4) having browser code take different code paths if a thread didn't exist
>   -this could be either deceptively harmless  (i.e. execute synchronously
> when it was normally asynchronous), when in fact it makes shutdown slower
> because disk access is moved to the UI thread
>   -it could lead to data loss, if tasks are silently not posted because the
> code assumes this only happens in unit tests, when it could occur on browser
> shutdown as well
>
> The solution
> 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask,
> DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed
> if the target thread is known to outlive the current thread.  The four
> static methods have the same signature as the ones from MessageLoop, with
> the addition of the first parameter to indicate the target thread.
> ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task);
> 3: If your object must be destructed on a specific thread, use a trait from
> ChromeThread:
> class Foo : public base::RefCountedThreadSafe ChromeThread::DeleteOnIOThread>
> 4: I've removed all the special casing and always made the objects in the
> browser code behave in one way.  If you're writing a unit test and need to
> use an object that goes to a file thread (where before it would proceed
> synchronously), you just need:
> ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current());
> foo->StartAsyncTaskOnFileThread();
> MessageLoop::current()->RunAllPending();
> There are plenty of examples now in the tests.
>
> Gotchas
> -PostTask will silently delete a task if the thread doesn't exist.  This is
> done to avoid having all the code that uses it have special cases if the
> target thread exists or not, and to make Valgrind happy.  As usual, the task
> for DeleteSoon/ReleaseSoon doesn't do anything in its destructor, so this
> won't cause unexpected behavior with them.  But be wary of posted Task
> objects which have non-trivial destructors or smart pointers as members.
>  I'm still on the fence about this, since while the latter is theoretical
> now, it could lead to problems in the future.  I might change it so that the
> tasks are not deleted when I'm ready for more Valgrind fun.
> If you absolutely must know if a task was posted or not, you can check the
> return value of PostTask and friends.  But note that even if the task was
> posted successfully, th

[chromium-dev] Re: Changes to using threads in the browser process

[John Abd-El-Malek]

That sounds interesting, but there are still two changes remaining and other
unrelated changes have gone in in the meantime, so it wouldn't be an apple
to apple comparison.  I can let you know when I'm done though (when the bug
is marked fixed).

On Mon, Nov 2, 2009 at 10:09 PM, Huan Ren  wrote:

> Cool! I could compare the builds before and after these changes to see
> what difference it makes. Of course it also prevents future issues.
>
> Huan
>
> On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek 
> wrote:
> > Over the last week, I've been making some changes to how threads are used
> in
> > the browser process, with the goal of simplifying cross-thread access and
> > improving stability.
> > The problem
> > We were using a number of patterns that were problematic:
> > 1) using ChromeThread::GetMessageLoop
> >   -this isn't safe, since it could return a valid pointer, but since the
> > caller isn't holding on to a lock anymore, the target MessageLoop could
> be
> > destructed while it's being used
> > 2) caching of MessageLoop pointers in order to use them later for
> PostTask
> > and friends
> >   -this was more efficient previously (more on that later) since using
> > ChromeThread::GetMessageLoop involved a lock
> >   -but it spread logic about the order of thread destruction all over the
> > code.  Code that moved from the IO thread to the file thread and back, in
> > order to avoid doing disk access on the IO thread, ended up having to do
> an
> > extra hop through the UI thread on the way back to the IO thread since
> the
> > file thread outlives the Io thread.  Of course, most code learnt this the
> > hard way, after doing the straight forward IO->file->IO thread hop and
> > updating the code after seeing reliability or user crashes
> >   -it made the browser shutdown fragile and hence difficult to update
> > 3) file thread hops using RefCountedThreadSafe objects which have
> > non-trivial destructors
> >   -to reduce jank, frequently an object on the UI or IO thread would
> execute
> > some code on the file thread, then post the result back to the original
> > thread.  We make this easy using RefCountedThreadSafe and
> NewRunnableMethod
> > so this pattern happened often, but it's not always
> safe: NewRunnableMethod
> > holds an extra reference on the object to ensure that it doesn't invoke a
> > method on a deleted object.  But it's quite possible that before the file
> > thread's stack unwinds and it releases the extra reference, that the
> > response task on the original thread executed and released its own
> > additional reference.  The file thread is then left with the remaining
> > reference and the object gets destructed there.  While for most objects
> this
> > is ok, many have non-trivial destructors, with the worst being ones that
> > register with the per-thread NotificationService.  Dangling pointers
> would
> > be left behind and tracking these crashes from ChromeBot or the crash
> dumps
> > has wasted several days at least for me.
> > 4) having browser code take different code paths if a thread didn't exist
> >   -this could be either deceptively harmless  (i.e. execute synchronously
> > when it was normally asynchronous), when in fact it makes shutdown slower
> > because disk access is moved to the UI thread
> >   -it could lead to data loss, if tasks are silently not posted because
> the
> > code assumes this only happens in unit tests, when it could occur on
> browser
> > shutdown as well
> >
> > The solution
> > 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask,
> > DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are
> grabbed
> > if the target thread is known to outlive the current thread.  The four
> > static methods have the same signature as the ones from MessageLoop, with
> > the addition of the first parameter to indicate the target thread.
> > ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task);
> > 3: If your object must be destructed on a specific thread, use a trait
> from
> > ChromeThread:
> > class Foo : public base::RefCountedThreadSafe > ChromeThread::DeleteOnIOThread>
> > 4: I've removed all the special casing and always made the objects in the
> > browser code behave in one way.  If you're writing a unit test and need
> to
> > use an object that goes to a file thread (where before it would proceed
> > synchronously), you just need:
> > ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current());
> > foo->StartAsyncTaskOnFileThread();
> > MessageLoop::current()->RunAllPending();
> > There are plenty of examples now in the tests.
> >
> > Gotchas
> > -PostTask will silently delete a task if the thread doesn't exist.  This
> is
> > done to avoid having all the code that uses it have special cases if the
> > target thread exists or not, and to make Valgrind happy.  As usual, the
> task
> > for DeleteSoon/ReleaseSoon doesn't do anything in its destructor, so this
> > won't cause unexpected behavior with them.  But be war

[chromium-dev] Compiling error after I did a 'gclient sync'

[n179911]

Hi,

I have tried syncing up chromium HEAD by doing this (since i use git
for chromium and webkit).
$ git pull (update chromium)
$ gclient sync
$ tools/sync-webkit-git.py (update webkit)

But i got the following errors when I compile it. It appears the
method 'CanvasRenderingContext3D::attachShader' is called with the
wrong number of parameters.
Does anyone know how to fix it?

Thank you.

chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:90:
error: no matching function for call to
'WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*&,
WebCore::CanvasShader*&)'
../html/canvas/CanvasRenderingContext3D.h:64: note: candidates are:
void WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*,
WebCore::CanvasShader*, WebCore::ExceptionCode&)
/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:101:
error: no matching function for call to
'WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*&,
unsigned int&, WebCore::String&)'
../html/canvas/CanvasRenderingContext3D.h:65: note: candidates are:
void 
WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*,
long unsigned int, const WebCore::String&, WebCore::ExceptionCode&)
/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:111:
error: no matching function for call to
'WebCore::CanvasRenderingContext3D::bindBuffer(unsigned int&,
WebCore::CanvasBuffer*&)'
../html/canvas/CanvasRenderingContext3D.h:66: note: candidates are:
void WebCore::CanvasRenderingContext3D::bindBuffer(long unsigned int,
WebCore::CanvasBuffer*, WebCore::ExceptionCode&)

--~--~-~--~~~---~--~~
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: refactoring and git

[Paweł Hajdan Jr .]

That's a good news. Can that info be put somewhere in the UsingGit wiki
page?

On Mon, Nov 2, 2009 at 23:56, Evan Martin  wrote:

>
> On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson  wrote:
> > I'm doing some refactoring in the chromium worker code, and I got the
> > following review feedback:
> > "small request: can the files that were branched from existing files be
> "svn
> > copy'd" instead of copying manually and "svn added"?  This will preserve
> > history
> > and will make it easier to see what changed in the review."
> > Is there a way to do this with git? I do want to make my reviewers happy
> :)
>
> Git has an ...odd... way of thinking about renames.  The pieces you
> need to know are:
> 1) Does git believe you did a rename?  Consult "git diff -M -C --stat
> origin..." and see if it prints renames.
> 2) If no, ping me off-list and I'll help you out.
> 3) If yes, Rietveld should be able to display the diff properly.
> However, this code is relatively untested (we have to convert the Git
> renames into SVN-style "renames" -- SVN doesn't actually support true
> renames, oddly enough) so it could be wrong.  In that case, also ping
> me off-list.  :)
>
> >
>

--~--~-~--~~~---~--~~
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: Compiling error after I did a 'gclient sync'

[Chase Phillips]

On Mon, Nov 2, 2009 at 10:27 PM, n179911  wrote:

>
> Hi,
>
> I have tried syncing up chromium HEAD by doing this (since i use git
> for chromium and webkit).
> $ git pull (update chromium)
> $ gclient sync
> $ tools/sync-webkit-git.py (update webkit)
>

Hi Samuel,

The error you're seeing might be caused by incorrectly generated build
files.  Try this order, instead:

$ git pull
$ tools/sync-webkit-git.py
$ gclient sync

Then build.

Chase


> But i got the following errors when I compile it. It appears the
> method 'CanvasRenderingContext3D::attachShader' is called with the
> wrong number of parameters.
> Does anyone know how to fix it?
>
> Thank you.
>
>
> chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:90:
> error: no matching function for call to
> 'WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*&,
> WebCore::CanvasShader*&)'
>../html/canvas/CanvasRenderingContext3D.h:64: note: candidates are:
> void
> WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*,
> WebCore::CanvasShader*, WebCore::ExceptionCode&)
>
> /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:101:
> error: no matching function for call to
>
> 'WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*&,
> unsigned int&, WebCore::String&)'
> ../html/canvas/CanvasRenderingContext3D.h:65: note: candidates are:
> void
> WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*,
> long unsigned int, const WebCore::String&, WebCore::ExceptionCode&)
>
> /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:111:
> error: no matching function for call to
> 'WebCore::CanvasRenderingContext3D::bindBuffer(unsigned int&,
> WebCore::CanvasBuffer*&)'
> ../html/canvas/CanvasRenderingContext3D.h:66: note: candidates are:
> void WebCore::CanvasRenderingContext3D::bindBuffer(long unsigned int,
> WebCore::CanvasBuffer*, WebCore::ExceptionCode&)
>
> >
>

--~--~-~--~~~---~--~~
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: Compiling error after I did a 'gclient sync'

[Kenneth Russell]

On Mon, Nov 2, 2009 at 10:27 PM, n179911  wrote:
>
> Hi,
>
> I have tried syncing up chromium HEAD by doing this (since i use git
> for chromium and webkit).
> $ git pull (update chromium)
> $ gclient sync
> $ tools/sync-webkit-git.py (update webkit)
>
> But i got the following errors when I compile it. It appears the
> method 'CanvasRenderingContext3D::attachShader' is called with the
> wrong number of parameters.
> Does anyone know how to fix it?
>
> Thank you.
>
> chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:90:
> error: no matching function for call to
> 'WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*&,
> WebCore::CanvasShader*&)'
>        ../html/canvas/CanvasRenderingContext3D.h:64: note: candidates are:
> void WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*,
> WebCore::CanvasShader*, WebCore::ExceptionCode&)
> /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:101:
> error: no matching function for call to
> 'WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*&,
> unsigned int&, WebCore::String&)'
> ../html/canvas/CanvasRenderingContext3D.h:65: note: candidates are:
> void 
> WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*,
> long unsigned int, const WebCore::String&, WebCore::ExceptionCode&)
> /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:111:
> error: no matching function for call to
> 'WebCore::CanvasRenderingContext3D::bindBuffer(unsigned int&,
> WebCore::CanvasBuffer*&)'
> ../html/canvas/CanvasRenderingContext3D.h:66: note: candidates are:
> void WebCore::CanvasRenderingContext3D::bindBuffer(long unsigned int,
> WebCore::CanvasBuffer*, WebCore::ExceptionCode&)

It looks like upstream WebKit changes have broken our WebGL
implementation again. The reason you're running into this is probably
that you synced a more recent version of WebKit than is described in
the DEPS file. Your best bet to get things compiling again quickly is
to set ENABLE_3D_CANVAS=0 in src/build/features_override.gypi, run
"gclient runhooks --force", and rebuild.

-Ken

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