[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API

[Yaar Schnitman]

I really like this feature. Some comments inside the doc.
Is registerContentHandler also in the works?

--~--~-~--~~~---~--~~
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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Darin Fisher]

Thanks for taking on this feature!

Some comments:
> ChromeClientChromium will implement the
> runJavaScriptRegisterProtocolHandler method in the
> ChromeClientImpl class in webkit/glue/chrome_client_impl.h.

Are you sure you need to add this method to ChromeClientChromium?  That
interface is only to be used when the method doesn't exist on ChromeClient.

Only supporting a whitelist of schemes sounds best to me.  What does Firefox
allow?

Before you venture too far into the implementation, I'd like to see what the
proposed WebKit API changes will be.  This would be a good thing to add to
your design doc.

Thanks,
-Darin


On Thu, Sep 24, 2009 at 12:51 PM,  wrote:

>
> I've shared a document with you:
>
> [HTML5] registerProtocolHandler API
>
> http://docs.google.com/Doc?docid=0AVgZ1iILHLkdZGQ0bjd6cTVfMGdqZmpiNGZr&hl=en&invite=CI6z8vgG
>
> It's not an attachment -- it's stored online at Google Docs. To open this
> document, just click the link above.
>
>
> This is a design document for the worked needed to resolve
> http://crbug.com/11359 beyond the webkit implementation.
>
> Please feel free to comment inline or in this thread.  I look forward to
> your critics and suggestions.
>
> >
>

--~--~-~--~~~---~--~~
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: SVN hangs updating third_party/WebKit

[Jian Li]

Could we document this in the dev wiki? I forgot to run this when I
installed my new machine :(

On Fri, Sep 25, 2009 at 8:52 PM, Mohamed Mansour  wrote:

> Thanks! That worked for me on "Windows 7 64bit"!
>  -Mohamed
>
>
>
> On Fri, Sep 25, 2009 at 8:39 PM, David Levin  wrote:
>
>> For windows (vista 64bit?), if you hit gclient hangs in general while
>> sync'ing:
>>
>> Run this command (from an Administrator command prompt): netsh
>> interface tcp set global autotuninglevel=disabled
>>
>> Hopefully, it will be fixed for you as it seems to be for me.
>>
>> Reference:
>> http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx
>>
>> 
>>
>> 
>>
>> On Fri, Sep 25, 2009 at 5:22 PM, Nico Weber  wrote:
>>
>>>
>>>
>>> http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba
>>>
>>> I had the impression that removing that folder once is enough, though
>>> I didn't try it more than once yet.
>>>
>>> On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson
>>>  wrote:
>>> > At first I thought it was a fluke but now it just happened again. Is
>>> anyone
>>> > else seeing this?
>>> > I do a gclient sync and it takes forever, showing this output and looks
>>> > hung:
>>> >
>>> >  running 'svn update E:\code\src\third_party\WebKit --revision
>>> > 27219' in
>>> >  'E:\code'
>>> > I wait and wait and wait and wait and nothing happens. I tried FileMon
>>> and
>>> > couldn't see any files being accessed. Re-running gclient sync just
>>> hangs
>>> > again in the same spot.
>>> > The only workaround I know is to delete that folder and try again. That
>>> was
>>> > fine for the first time this happens, but is getting more exponentially
>>> more
>>> > frustrating with each time I have to do that. :s
>>> > Anyone seen this?
>>> > -F
>>> > >
>>> >
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: SVN hangs updating third_party/WebKit

[Mohamed Mansour]

Thanks! That worked for me on "Windows 7 64bit"!
 -Mohamed


On Fri, Sep 25, 2009 at 8:39 PM, David Levin  wrote:

> For windows (vista 64bit?), if you hit gclient hangs in general while
> sync'ing:
>
> Run this command (from an Administrator command prompt): netsh
> interface tcp set global autotuninglevel=disabled
>
> Hopefully, it will be fixed for you as it seems to be for me.
>
> Reference:
> http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx
>
> 
>
> 
>
> On Fri, Sep 25, 2009 at 5:22 PM, Nico Weber  wrote:
>
>>
>>
>> http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba
>>
>> I had the impression that removing that folder once is enough, though
>> I didn't try it more than once yet.
>>
>> On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson
>>  wrote:
>> > At first I thought it was a fluke but now it just happened again. Is
>> anyone
>> > else seeing this?
>> > I do a gclient sync and it takes forever, showing this output and looks
>> > hung:
>> >
>> >  running 'svn update E:\code\src\third_party\WebKit --revision
>> > 27219' in
>> >  'E:\code'
>> > I wait and wait and wait and wait and nothing happens. I tried FileMon
>> and
>> > couldn't see any files being accessed. Re-running gclient sync just
>> hangs
>> > again in the same spot.
>> > The only workaround I know is to delete that folder and try again. That
>> was
>> > fine for the first time this happens, but is getting more exponentially
>> more
>> > frustrating with each time I have to do that. :s
>> > Anyone seen this?
>> > -F
>> > >
>> >
>>
>>
>>
>
> >
>

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

[chromium-dev] buildbot failure in Chromium on Linux Builder (Views dbg), revision 27319

[buildbot]

Automatically closing tree for "compile" on "Linux Builder (Views dbg)"

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28Views%20dbg%29/builds/1278

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28Views%20dbg%29

--=>  Automatically closing tree for "compile" on "Linux Builder (Views dbg)"  
<=--

Revision: 27319
Blame list: fin...@chromium.org

Buildbot waterfall: http://build.chromium.org/

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

Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)

[Ben Goodger (Google)]

BTW I should note what I mean by "Uber Page Info Window".

For some time, we've talked about improving the page info window in
Chrome. Right now it shows only the security information for a SSL
page. In the future we'd like to extend this to show other
information. The idea is there'd be a few tabs showing things like:

- general page info in addition to security info
- web capabilities/permissions used by the page, along with the
ability to control these, including the effect of any active blacklist
- media attached to the page, which a convenient way to download
- eventually an additional surface for extensions to add tabs/features
based on content-script scanning of the page

The idea anyway is for any web capability there'd be a toggle in here.
We also envisage some kind of app/extension page where one can visit
the properties/capabilities for an individual installed app/extension
too.

Anyway any time the notion of site-specific capability control comes
up, the response from the UX team tends to be "uber page info window".
It's on our list, we just have been busy with other stuff.

I mocked this some years ago in Firefox as a bottom bar
http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window
but I am not advocating that approach necessarily.

-Ben

On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google)  wrote:
> On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow  wrote:
>> I had the same thoughts.  Does Firefox not implement anything like this?
>> Another question that this brings up: how could a user un-register something
>> even if the web site doesn't do anything to make it possible?  In other
>> words, we might need some piece of UI to remove registrations even beyond
>> having an API for it.
>
> Uber page info dialog.
>
> -Ben
>

--~--~-~--~~~---~--~~
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: SVN hangs updating third_party/WebKit

[Finnur Thorarinsson]

Yes, I am on Vista 64 bit. I'll try this next time I hit this. Thanks for
the pointer.

On Fri, Sep 25, 2009 at 17:39, David Levin  wrote:

> For windows (vista 64bit?), if you hit gclient hangs in general while
> sync'ing:
>
> Run this command (from an Administrator command prompt): netsh
> interface tcp set global autotuninglevel=disabled
>
> Hopefully, it will be fixed for you as it seems to be for me.
>
> Reference:
> http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx
>
> 
>
> 
>
> On Fri, Sep 25, 2009 at 5:22 PM, Nico Weber  wrote:
>
>>
>>
>> http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba
>>
>> I had the impression that removing that folder once is enough, though
>> I didn't try it more than once yet.
>>
>> On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson
>>  wrote:
>> > At first I thought it was a fluke but now it just happened again. Is
>> anyone
>> > else seeing this?
>> > I do a gclient sync and it takes forever, showing this output and looks
>> > hung:
>> >
>> >  running 'svn update E:\code\src\third_party\WebKit --revision
>> > 27219' in
>> >  'E:\code'
>> > I wait and wait and wait and wait and nothing happens. I tried FileMon
>> and
>> > couldn't see any files being accessed. Re-running gclient sync just
>> hangs
>> > again in the same spot.
>> > The only workaround I know is to delete that folder and try again. That
>> was
>> > fine for the first time this happens, but is getting more exponentially
>> more
>> > frustrating with each time I have to do that. :s
>> > Anyone seen this?
>> > -F
>> > >
>> >
>>
>> >>
>>
>

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

[chromium-dev] Re: how to trigger a non-success status for URLRequest in unittests?

[Andrew Scherkus]

I'm not familiar with the code either, but if people are fine making
URLRequest::status() virtual, you can use gmock and be done.  I have a hunch
there might be some push back :)

If you're really interested in deterministic results, the longer way looks
like you'd call RegisterRequestInterceptor() with a special URLRequestJob
subclass that would modify a URLRequest instance to your liking.  In fact
url_request_test_job.h might be what you're looking for.

Andrew

On Fri, Sep 25, 2009 at 7:02 PM, Jenn Braithwaite (胡慧鋒) wrote:

> Hi,
> I want my unittest to result in my URLRequest getting a non-success status.
>  How do I do that?
>
> When I use "http://localhost/foo";  as my URL, I get a non-success status
> with os_error = -102 when testing on Vista64, but I don't know if this will
> guarantee me a non-success status all the time on all platforms.  Is there a
> more definitive technique to do what I want?
>
> Thanks,
> Jenn
>
> >
>

--~--~-~--~~~---~--~~
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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Ben Goodger (Google)]

On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow  wrote:
> I had the same thoughts.  Does Firefox not implement anything like this?
> Another question that this brings up: how could a user un-register something
> even if the web site doesn't do anything to make it possible?  In other
> words, we might need some piece of UI to remove registrations even beyond
> having an API for it.

Uber page info dialog.

-Ben

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

[chromium-dev] Re: how to trigger a non-success status for URLRequest in unittests?

[Evan Martin]

Perhaps you could use an invalid scheme on the URL?  (Just guessing;
I'm not familiar with this code.)

On Fri, Sep 25, 2009 at 7:02 PM, Jenn Braithwaite (胡慧鋒)
 wrote:
> Hi,
> I want my unittest to result in my URLRequest getting a non-success status.
>  How do I do that?
> When I use "http://localhost/foo";  as my URL, I get a non-success status
> with os_error = -102 when testing on Vista64, but I don't know if this will
> guarantee me a non-success status all the time on all platforms.  Is there a
> more definitive technique to do what I want?
> Thanks,
> Jenn
> >
>

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

[chromium-dev] how to trigger a non-success status for URLRequest in unittests?

[胡慧鋒]

Hi,
I want my unittest to result in my URLRequest getting a non-success status.
 How do I do that?

When I use "http://localhost/foo";  as my URL, I get a non-success status
with os_error = -102 when testing on Vista64, but I don't know if this will
guarantee me a non-success status all the time on all platforms.  Is there a
more definitive technique to do what I want?

Thanks,
Jenn

--~--~-~--~~~---~--~~
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 isn't shutting down cleanly

[Jim Roskind]

+1

On Wed, Sep 23, 2009 at 5:52 AM, progame  wrote:

>
> sounds like this issue http://crbug.com/20451
>
> On Sep 22, 8:39 pm, Daniel Cowx  wrote:
> > Can someone please provide a bit of insight into how to solve the
> > following problem:
> >
> > 1. Open Chromium > Options > Show saved passwords
> > 2. Click the "Remove All button"
> >
> > Now, *before* you click "Yes" or "No", close the main browser window
> > (e.g. by clicking the X in the upper right corner).  When you do this,
> > all windows disappear, but the main browser process remains running.
> > It looks like this is due to a nested invocation of MessageLoop::Run()
> > (via chrome\browser\views\confirm_message_box_dialog.cc) and the fact
> > that Quit is only exiting the most recent invocation.
> >
> > How can we cleanly quit the application in this case?
> >
> > Cheers,
> > Daniel
> >
>

--~--~-~--~~~---~--~~
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: buildbot failure in Chromium on XP Tests, revision 27312

[Nico Weber]

Looks like a grid change wasn't picked up, should go away after clobbering.

On Fri, Sep 25, 2009 at 6:33 PM,  wrote:

>  http://build.chromium.org/buildbot/waterfall/
>
> Automatically closing tree for "unit_tests" on "XP Tests"
>
>
> http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568
>
> Revision: 27309, 27310, 27312
> Blame list: dpra...@google.com,m...@chromium.org,thes...@chromium.org
>
>  XP Tests
> Build 
> 12568
> svnkill
> stdio
>   update
> scripts
> stdio
> taskkill
> stdio
> update
> stdio
>   extract
> build
> stdio
>   Start
> Crash Handler
> stdio
> ipc_tests
> stdio
> installer_util_unittests
> stdio
> mini_installer_test
> stdio
> unit_tests
> 16 disabled
> failed 1
> stdio
> Test
>
> Changed by: *thes...@chromium.org*
> Changed at: *Fri 25 Sep 2009 18:08:17*
> Branch: *src*
> Revision: *27309*
>
> Changed files:
>
>- *tools/valgrind/memcheck/suppressions.txt*
>
> Comments:
>
> Widen a valgrind suppression yet again.
>
> BUG=22932
> TEST=none
> TBR=stuartmorgan
> Review URL: http://codereview.chromium.org/243015
>
>  Changed by: *dpra...@google.com*
> Changed at: *Fri 25 Sep 2009 18:08:59*
> Branch: *src*
> Revision: *27310*
>
> Changed files:
>
>- *webkit/tools/layout_tests/test_expectations.txt*
>
> Comments:
>
> Fix comments in test expectations. Also, the description in my previous
> change to this file was wrong, the new values for expectations are
> 'TEXT', 'IMAGE', and 'IMAGE+TEXT' ('BOTH' is not a valid value).
>
>   R=ojan
>   BUG=none
>   TEST=none
>
> Review URL: http://codereview.chromium.org/245019
>
>  Changed by: *...@chromium.org*
> Changed at: *Fri 25 Sep 2009 18:13:07*
> Branch: *src*
> Revision: *27312*
>
> Changed files:
>
>- *chrome/app/generated_resources.grd*
>- *chrome/browser/views/download_item_view.cc*
>- *chrome/browser/download/download_shelf.cc*
>- *chrome/browser/download/download_shelf.h*
>
> Comments:
>
> Remove the context menu item 'Remove from shelf' from download shelf
>
> BUG=23078
> TEST=No more menu item on download item
>
> Review URL: http://codereview.chromium.org/246004
>
>
> >
>
>

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

[chromium-dev] buildbot failure in Chromium on XP Tests, revision 27312

[buildbot]

Automatically closing tree for "unit_tests" on "XP Tests"

http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12568

http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests

--=>  Automatically closing tree for "unit_tests" on "XP Tests"  <=--

Revision: 27309, 27310, 27312
Blame list: dpra...@google.com,m...@chromium.org,thes...@chromium.org

Buildbot waterfall: http://build.chromium.org/

--~--~-~--~~~---~--~~
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: new values for failures in test_expectations.txt

[Marc-Antoine Ruel]

On Fri, Sep 25, 2009 at 9:12 PM, Dirk Pranke  wrote:
>
> Hi all,
>
> If you don't run layout_tests or ever need to modify
> test_expecations.txt, you can ignore this ...

As a reminder, every build sheriff needs to be able to modify this.

M-A

> As discussed earlier this week, we've added the ability to indicate
> whether or not a test is expected to produce incorrect text output
> (either a bad render tree or bad simplified text output), incorrect
> images, or both. The keywords in test expectations are 'TEXT',
> 'IMAGE', and 'IMAGE+TEXT', respectively.
>
> Specifying a test expectation as 'FAIL' will continue to indicate any
> one of the above three choices might be happening. However, we
> intended to migrate all FAILs to one of the three choices. Once that
> is complete, we'll flip 'FAIL' to mean 'IMAGE+TEXT', and remove the
> 'IMAGE+TEXT' option. I expect this'll probably happen in the next week
> or two.
>
> Thanks, and let me know if you see any problems!
>
> -- Dirk
>
> >
>

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

[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API

[Jeremy Orlow]

On Fri, Sep 25, 2009 at 5:30 PM, Nick Baum  wrote:

> First of all, thanks for putting together this proposal, great to see
> progress on this!
> A few comments:
>
>- UI: I prefer the infobar, as per the arguments above. I don't think
>this will happen frequently enough to be annoying.
>- UI: Should there be user UI to manage this that doesn't require
>knowing a magic about:protocols url?
>- API: Is there an API to unregister from a protocol?
>- API: How does the page know it's registered? We should probably have
>a separate API for this, so sites can display a more prominent call to
>action when they're not registered.
>
> I had the same thoughts.  Does Firefox not implement anything like this?

Another question that this brings up: how could a user un-register something
even if the web site doesn't do anything to make it possible?  In other
words, we might need some piece of UI to remove registrations even beyond
having an API for it.

>
>- Misc: Should there be some way for native apps to register as
>protocol handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does
>the OS provide this?
>
> Cheers,
>
> -Nick
>
> On Fri, Sep 25, 2009 at 12:45 PM, Peter Kasting wrote:
>
>> On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) 
>> wrote:
>>
>>> We should only allow this UI to be invoked from a user gesture.
>>
>>
>> How does Gmail trigger this today?  Do they have a button in the Settings
>> you have to click?
>>
>> 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] new values for failures in test_expectations.txt

[Dirk Pranke]

Hi all,

If you don't run layout_tests or ever need to modify
test_expecations.txt, you can ignore this ...

As discussed earlier this week, we've added the ability to indicate
whether or not a test is expected to produce incorrect text output
(either a bad render tree or bad simplified text output), incorrect
images, or both. The keywords in test expectations are 'TEXT',
'IMAGE', and 'IMAGE+TEXT', respectively.

Specifying a test expectation as 'FAIL' will continue to indicate any
one of the above three choices might be happening. However, we
intended to migrate all FAILs to one of the three choices. Once that
is complete, we'll flip 'FAIL' to mean 'IMAGE+TEXT', and remove the
'IMAGE+TEXT' option. I expect this'll probably happen in the next week
or two.

Thanks, and let me know if you see any problems!

-- Dirk

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

[chromium-dev] Re: SVN hangs updating third_party/WebKit

[David Levin]

For windows (vista 64bit?), if you hit gclient hangs in general while
sync'ing:

Run this command (from an Administrator command prompt): netsh interface
tcp set global autotuninglevel=disabled

Hopefully, it will be fixed for you as it seems to be for me.

Reference:
http://blogs.technet.com/asiasupp/archive/2006/12/14/windows-vista-tcp-auto-tuning.aspx



On Fri, Sep 25, 2009 at 5:22 PM, Nico Weber  wrote:

>
>
> http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba
>
> I had the impression that removing that folder once is enough, though
> I didn't try it more than once yet.
>
> On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson
>  wrote:
> > At first I thought it was a fluke but now it just happened again. Is
> anyone
> > else seeing this?
> > I do a gclient sync and it takes forever, showing this output and looks
> > hung:
> >
> >  running 'svn update E:\code\src\third_party\WebKit --revision
> > 27219' in
> >  'E:\code'
> > I wait and wait and wait and wait and nothing happens. I tried FileMon
> and
> > couldn't see any files being accessed. Re-running gclient sync just hangs
> > again in the same spot.
> > The only workaround I know is to delete that folder and try again. That
> was
> > fine for the first time this happens, but is getting more exponentially
> more
> > frustrating with each time I have to do that. :s
> > Anyone seen this?
> > -F
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Nick Baum]

First of all, thanks for putting together this proposal, great to see
progress on this!
A few comments:

   - UI: I prefer the infobar, as per the arguments above. I don't think
   this will happen frequently enough to be annoying.
   - UI: Should there be user UI to manage this that doesn't require knowing
   a magic about:protocols url?
   - API: Is there an API to unregister from a protocol?
   - API: How does the page know it's registered? We should probably have a
   separate API for this, so sites can display a more prominent call to action
   when they're not registered.
   - Misc: Should there be some way for native apps to register as protocol
   handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does the OS
   provide this?

Cheers,

-Nick

On Fri, Sep 25, 2009 at 12:45 PM, Peter Kasting  wrote:

> On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) 
> wrote:
>
>> We should only allow this UI to be invoked from a user gesture.
>
>
> How does Gmail trigger this today?  Do they have a button in the Settings
> you have to click?
>
> 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: SVN hangs updating third_party/WebKit

[Nico Weber]

http://groups.google.com/group/chromium-dev/browse_thread/thread/64a19a5f78db8fba

I had the impression that removing that folder once is enough, though
I didn't try it more than once yet.

On Fri, Sep 25, 2009 at 5:18 PM, Finnur Thorarinsson
 wrote:
> At first I thought it was a fluke but now it just happened again. Is anyone
> else seeing this?
> I do a gclient sync and it takes forever, showing this output and looks
> hung:
>
>  running 'svn update E:\code\src\third_party\WebKit --revision
> 27219' in
>  'E:\code'
> I wait and wait and wait and wait and nothing happens. I tried FileMon and
> couldn't see any files being accessed. Re-running gclient sync just hangs
> again in the same spot.
> The only workaround I know is to delete that folder and try again. That was
> fine for the first time this happens, but is getting more exponentially more
> frustrating with each time I have to do that. :s
> Anyone seen this?
> -F
> >
>

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

[chromium-dev] SVN hangs updating third_party/WebKit

[Finnur Thorarinsson]

At first I thought it was a fluke but now it just happened again. Is anyone
else seeing this?
I do a gclient sync and it takes forever, showing this output and looks
hung:

 running 'svn update E:\code\src\third_party\WebKit --revision
27219' in
 'E:\code'

I wait and wait and wait and wait and nothing happens. I tried FileMon and
couldn't see any files being accessed. Re-running gclient sync just hangs
again in the same spot.

The only workaround I know is to delete that folder and try again. That was
fine for the first time this happens, but is getting more exponentially more
frustrating with each time I have to do that. :s

Anyone seen this?

-F

--~--~-~--~~~---~--~~
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 time doubled since May - what gives?

[Darin Fisher]

http://trac.webkit.org/changeset/48776

On Fri, Sep 25, 2009 at 3:57 PM, Darin Fisher  wrote:

> I'm fixing the RegisteredEventListener one.-Darin
>
>
> On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel wrote:
>
>>
>> Oh and a lot of warnings appeared recently. It is surprising how much
>> warnings slow down the build, probably due to stdout serialization.
>>
>> http://code.google.com/p/chromium/issues/detail?id=23039
>>
>> M-A
>>
>> On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel 
>> wrote:
>> > http://code.google.com/p/chromium/issues/detail?id=21266
>> >
>> > This is a real problem, I just haven't looked into this one in
>> > particular. Sometimes I just feel like renaming the dll...
>> >
>> > M-A
>> >
>> > On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour 
>> wrote:
>> >> Hey Ben, same here ... I see this additional message today (havn't seen
>> it
>> >> before)
>> >> 59>LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found
>> or
>> >> not built by the last incremental link; performing full link
>> >>
>> >> Changing one file used to take me 5 minutes to build. But now it takes
>> me
>> >> ~10-15 minutes.
>> >> -Mohamed
>> >>
>> >>
>> >> On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) <
>> b...@chromium.org>
>> >> wrote:
>> >>>
>> >>> I just ran a build here at home on my i7 workstation. It took 14
>> >>> minutes. This is the same system that would build in 7 minutes when I
>> >>> set it up in May.
>> >>>
>> >>> What gives? We need to figure this out ASAP.
>> >>>
>> >>> -Ben
>> >>>
>> >>>
>> >>
>> >>
>> >> >>
>> >>
>> >
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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 time doubled since May - what gives?

[Darin Fisher]

I'm fixing the RegisteredEventListener one.-Darin

On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel wrote:

>
> Oh and a lot of warnings appeared recently. It is surprising how much
> warnings slow down the build, probably due to stdout serialization.
>
> http://code.google.com/p/chromium/issues/detail?id=23039
>
> M-A
>
> On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel 
> wrote:
> > http://code.google.com/p/chromium/issues/detail?id=21266
> >
> > This is a real problem, I just haven't looked into this one in
> > particular. Sometimes I just feel like renaming the dll...
> >
> > M-A
> >
> > On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour 
> wrote:
> >> Hey Ben, same here ... I see this additional message today (havn't seen
> it
> >> before)
> >> 59>LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found
> or
> >> not built by the last incremental link; performing full link
> >>
> >> Changing one file used to take me 5 minutes to build. But now it takes
> me
> >> ~10-15 minutes.
> >> -Mohamed
> >>
> >>
> >> On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) <
> b...@chromium.org>
> >> wrote:
> >>>
> >>> I just ran a build here at home on my i7 workstation. It took 14
> >>> minutes. This is the same system that would build in 7 minutes when I
> >>> set it up in May.
> >>>
> >>> What gives? We need to figure this out ASAP.
> >>>
> >>> -Ben
> >>>
> >>>
> >>
> >>
> >> >>
> >>
> >
>
> >
>

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

[chromium-dev] buildbot failure in Chromium on Vista Tests (dbg)(1), revision 27259

[buildbot]

Automatically closing tree for "unit_tests" on "Vista Tests (dbg)(1)"

http://build.chromium.org/buildbot/waterfall/builders/Vista%20Tests%20%28dbg%29%281%29/builds/12964

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Vista%20Tests%20%28dbg%29%281%29

--=>  Automatically closing tree for "unit_tests" on "Vista Tests (dbg)(1)"  
<=--

Revision: 27259
Blame list: dglaz...@chromium.org

Buildbot waterfall: http://build.chromium.org/

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

[chromium-dev] buildbot failure in Chromium on XP Tests (dbg)(1), revision 27249

[buildbot]

Automatically closing tree for "unit_tests" on "XP Tests (dbg)(1)"

http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests%20%28dbg%29%281%29/builds/12686

http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests%20%28dbg%29%281%29

--=>  Automatically closing tree for "unit_tests" on "XP Tests (dbg)(1)"  <=--

Revision: 27249
Blame list: aba...@chromium.org

Buildbot waterfall: http://build.chromium.org/

--~--~-~--~~~---~--~~
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: buildbot failure in Chromium on Modules XP (dbg), revision 27248

[Paweł Hajdan Jr .]

Confirmed. It is flaky. I'm going to disable it when I have a while. Feel
free to disable it earlier.
On Fri, Sep 25, 2009 at 14:19, Eric Roman  wrote:

> Looks like FTPCacheURLCredentials is flaky; none of these changes touched
> that code...
>
>
> On Fri, Sep 25, 2009 at 2:14 PM,  wrote:
>
>>  http://build.chromium.org/buildbot/waterfall/
>>
>> Automatically closing tree for "net_unittests" on "Modules XP (dbg)"
>>
>>
>> http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013
>>
>> Revision: 27245, 27246, 27247, 27248
>> Blame list: ero...@chromium.org,ma...@chromium.org,m...@chromium.org,
>> sh...@chromium.org
>>
>>  Modules XP (dbg)
>> Build 
>> 16013
>> svnkill
>> stdio
>>   update
>> scripts
>> stdio
>> taskkill
>> stdio
>> update
>> stdio
>>   compile
>> base
>> stdio
>>   compile
>> net
>> stdio
>>   compile
>> sandbox
>> stdio
>> base_unittests
>> 2 disabled
>> stdio
>> net_unittests
>> 8 disabled
>> failed 1
>> stdio
>> FTPCacheURLCredentials
>>
>> Changed by: *ma...@chromium.org*
>> Changed at: *Fri 25 Sep 2009 14:03:57*
>> Branch: *src*
>> Revision: *27245*
>>
>> Changed files:
>>
>>- *chrome/test/testing_profile.cc*
>>
>> Comments:
>>
>> Coverity: initialize created_theme_provider_ in the other constructor.
>>
>> CID=6160
>> BUG=none
>> TEST=none
>>
>> Review URL: http://codereview.chromium.org/252002
>>
>>  Changed by: *ero...@chromium.org*
>> Changed at: *Fri 25 Sep 2009 14:04:37*
>> Branch: *src*
>> Revision: *27246*
>>
>> Changed files:
>>
>>- *net/data/proxy_resolver_v8_unittest/pac_library_unittest.js*
>>
>> Comments:
>>
>> Add an additional test for dnsDomainIs() to verify that it doesn't simply 
>> match any substring.
>> This is working correctly, but since it was failing in WinHTTP we should 
>> have a regression test.
>>
>> BUG=18511
>>
>> Review URL: http://codereview.chromium.org/245008
>>
>>  Changed by: *...@chromium.org*
>> Changed at: *Fri 25 Sep 2009 14:04:37*
>> Branch: *src*
>> Revision: *27247*
>>
>> Changed files:
>>
>>- *chrome/browser/gtk/browser_window_gtk.cc*
>>- *chrome/browser/gtk/browser_window_gtk.h*
>>- *chrome/browser/gtk/browser_titlebar.cc*
>>
>> Comments:
>>
>> Linux: work around browser windows that get stuck maximized by the WM.
>> BUG=22807
>> TEST=none
>>
>> Review URL: http://codereview.chromium.org/218040
>>
>>  Changed by: *sh...@chromium.org*
>> Changed at: *Fri 25 Sep 2009 14:05:27*
>> Branch: *src*
>> Revision: *27248*
>>
>> Changed files:
>>
>>- *chrome/browser/cocoa/autocomplete_text_field_cell.mm*
>>
>> Comments:
>>
>> [Mac] Fix depressed baseline in Omnibox.
>>
>> A previous change converted AutocompleteTextFieldCell to rely more on
>> -drawingRectForBounds: rather than tweaking the baseline in an ad-hoc
>> fashion in many places.  This adds a place I missed.
>> http://crbug.com/23096
>> TEST=Browse  to www.google.com.  When 
>> putting focus in the page the
>> url should stay at the same spot as when focus is in the Omnibox.
>>
>> Review URL: http://codereview.chromium.org/242010
>>
>>
>> >>
>>
>>
>

--~--~-~--~~~---~--~~
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: buildbot failure in Chromium on Modules XP (dbg), revision 27248

[Eric Roman]

Looks like FTPCacheURLCredentials is flaky; none of these changes touched
that code...

On Fri, Sep 25, 2009 at 2:14 PM,  wrote:

>  http://build.chromium.org/buildbot/waterfall/
>
> Automatically closing tree for "net_unittests" on "Modules XP (dbg)"
>
>
> http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013
>
> Revision: 27245, 27246, 27247, 27248
> Blame list: ero...@chromium.org,ma...@chromium.org,m...@chromium.org,
> sh...@chromium.org
>
>  Modules XP (dbg)
> Build 
> 16013
> svnkill
> stdio
>   update
> scripts
> stdio
> taskkill
> stdio
> update
> stdio
>   compile
> base
> stdio
>   compile
> net
> stdio
>   compile
> sandbox
> stdio
> base_unittests
> 2 disabled
> stdio
> net_unittests
> 8 disabled
> failed 1
> stdio
> FTPCacheURLCredentials
>
> Changed by: *ma...@chromium.org*
> Changed at: *Fri 25 Sep 2009 14:03:57*
> Branch: *src*
> Revision: *27245*
>
> Changed files:
>
>- *chrome/test/testing_profile.cc*
>
> Comments:
>
> Coverity: initialize created_theme_provider_ in the other constructor.
>
> CID=6160
> BUG=none
> TEST=none
>
> Review URL: http://codereview.chromium.org/252002
>
>  Changed by: *ero...@chromium.org*
> Changed at: *Fri 25 Sep 2009 14:04:37*
> Branch: *src*
> Revision: *27246*
>
> Changed files:
>
>- *net/data/proxy_resolver_v8_unittest/pac_library_unittest.js*
>
> Comments:
>
> Add an additional test for dnsDomainIs() to verify that it doesn't simply 
> match any substring.
> This is working correctly, but since it was failing in WinHTTP we should have 
> a regression test.
>
> BUG=18511
>
> Review URL: http://codereview.chromium.org/245008
>
>  Changed by: *...@chromium.org*
> Changed at: *Fri 25 Sep 2009 14:04:37*
> Branch: *src*
> Revision: *27247*
>
> Changed files:
>
>- *chrome/browser/gtk/browser_window_gtk.cc*
>- *chrome/browser/gtk/browser_window_gtk.h*
>- *chrome/browser/gtk/browser_titlebar.cc*
>
> Comments:
>
> Linux: work around browser windows that get stuck maximized by the WM.
> BUG=22807
> TEST=none
>
> Review URL: http://codereview.chromium.org/218040
>
>  Changed by: *sh...@chromium.org*
> Changed at: *Fri 25 Sep 2009 14:05:27*
> Branch: *src*
> Revision: *27248*
>
> Changed files:
>
>- *chrome/browser/cocoa/autocomplete_text_field_cell.mm*
>
> Comments:
>
> [Mac] Fix depressed baseline in Omnibox.
>
> A previous change converted AutocompleteTextFieldCell to rely more on
> -drawingRectForBounds: rather than tweaking the baseline in an ad-hoc
> fashion in many places.  This adds a place I missed.
> http://crbug.com/23096
> TEST=Browse  to www.google.com.  When 
> putting focus in the page the
> url should stay at the same spot as when focus is in the Omnibox.
>
> Review URL: http://codereview.chromium.org/242010
>
>
> >
>
>

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

[chromium-dev] buildbot failure in Chromium on Modules XP (dbg), revision 27248

[buildbot]

Automatically closing tree for "net_unittests" on "Modules XP (dbg)"

http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16013

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP%20%28dbg%29

--=>  Automatically closing tree for "net_unittests" on "Modules XP (dbg)"  <=--

Revision: 27245, 27246, 27247, 27248
Blame list: 
ero...@chromium.org,ma...@chromium.org,m...@chromium.org,sh...@chromium.org

Buildbot waterfall: http://build.chromium.org/

--~--~-~--~~~---~--~~
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: gclient hang

[Vitaly Repeshko]

On Fri, Sep 25, 2009 at 11:51 PM, Yaar Schnitman  wrote:
> No, symlinks would not work since upstream gyp files still depend on
> downstream gyps (skia, icu, etc). Working on it.

As a workaround it's possible to mount directories instead of symlinking them.

$ mkdir /chrome/src/third_party/WebKit
$ sudo mount --bind /upstream/WebKit /chrome/src/third_party/WebKit

> On Fri, Sep 25, 2009 at 12:45 PM, Andrew Scherkus 
> wrote:
>>
>> It also appears you can no longer use a symlink to point
>> /src/third_party/WebKit at a different checkout.  I think relative paths are
>> to blame but I haven't fully debugged the issue yet.
>>
>> On Fri, Sep 25, 2009 at 12:20 PM, Jeremy Orlow 
>> wrote:
>>>
>>> I
>>> updated http://sites.google.com/a/chromium.org/dev/developers/contributing-to-webkit
>>>
>>> On Fri, Sep 25, 2009 at 12:14 PM, Andrew Scherkus 
>>> wrote:

 For those that use third_party/WebKit as a full WebKit checkout, you'll
 need to add the following line to your .gclient:
  "src/third_party/WebKit/WebKit/chromium": None,
 Andrew

 On Fri, Sep 25, 2009 at 11:51 AM, Marc-Antoine Ruel
  wrote:
>
> Yep, I specified one directory too deep.
>
> On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton
>  wrote:
> > To get mine to work, I had to
> >
> >  rm -rf src/third_party/WebKit/WebKit
> >
> > just doing "chromium" wasn't enough to stop the hangs.
> >
> > On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel
> >  wrote:
> >>
> >> Your next gclient sync will probably hang. The easiest way to fix it
> >> is to:
> >>  rm -rf src/third_party/WebKit/WebKit/chromium
> >> or
> >>  rd /q /s src\third_party\WebKit\WebKit\chromium
> >>
> >> before syncing.
> >>
> >> Sorry for the trouble,
> >>
> >> M-A
> >>
> >> >>
> >>
> >
> >
> >
> > --
> > 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: Skipping reference_build ?

[Jeremy Orlow]

Sounds like we need a presubmit check.

On Fri, Sep 25, 2009 at 6:38 AM, Marc-Antoine Ruel wrote:

>
> It's too late for git but not for svn and tarballs. Please move them to
> DEPS.
>
> M-A
>
> On Thu, Sep 24, 2009 at 6:26 PM, Evan Martin  wrote:
> >
> > We have already scolded Alex about this, but it's too late now.
> >
> > Repeat PSA: plz to not be dumping large Windows binaries into the
> > tree.  We have DEPS for a reason.
> >
> > On Thu, Sep 24, 2009 at 3:20 PM, Michael 
> wrote:
> >>
> >> The src/chrome_frame/tools/test/reference_build directory takes ages
> >> to svn up, is there a way to skip it? I don't think I really need all
> >> those .dll and .exe files on Linux anyway...
> >> >
> >>
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: gclient hang

[Yaar Schnitman]

No, symlinks would not work since upstream gyp files still depend on
downstream gyps (skia, icu, etc). Working on it.

On Fri, Sep 25, 2009 at 12:45 PM, Andrew Scherkus wrote:

> It also appears you can no longer use a symlink to point
> /src/third_party/WebKit at a different checkout.  I think relative paths are
> to blame but I haven't fully debugged the issue yet.
>
>
> On Fri, Sep 25, 2009 at 12:20 PM, Jeremy Orlow wrote:
>
>> I updated
>> http://sites.google.com/a/chromium.org/dev/developers/contributing-to-webkit
>>
>>
>> On Fri, Sep 25, 2009 at 12:14 PM, Andrew Scherkus 
>> wrote:
>>
>>> For those that use third_party/WebKit as a full WebKit checkout, you'll
>>> need to add the following line to your .gclient:
>>>  "src/third_party/WebKit/WebKit/chromium": None,
>>>
>>> Andrew
>>>
>>>
>>> On Fri, Sep 25, 2009 at 11:51 AM, Marc-Antoine Ruel >> > wrote:
>>>

 Yep, I specified one directory too deep.

 On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton 
 wrote:
 > To get mine to work, I had to
 >
 >  rm -rf src/third_party/WebKit/WebKit
 >
 > just doing "chromium" wasn't enough to stop the hangs.
 >
 > On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel <
 mar...@chromium.org> wrote:
 >>
 >> Your next gclient sync will probably hang. The easiest way to fix it
 is to:
 >>  rm -rf src/third_party/WebKit/WebKit/chromium
 >> or
 >>  rd /q /s src\third_party\WebKit\WebKit\chromium
 >>
 >> before syncing.
 >>
 >> Sorry for the trouble,
 >>
 >> M-A
 >>
 >> >>
 >>
 >
 >
 >
 > --
 > 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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Peter Kasting]

On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) wrote:

> We should only allow this UI to be invoked from a user gesture.


How does Gmail trigger this today?  Do they have a button in the Settings
you have to click?

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: gclient hang

[Andrew Scherkus]

It also appears you can no longer use a symlink to point
/src/third_party/WebKit at a different checkout.  I think relative paths are
to blame but I haven't fully debugged the issue yet.

On Fri, Sep 25, 2009 at 12:20 PM, Jeremy Orlow  wrote:

> I updated
> http://sites.google.com/a/chromium.org/dev/developers/contributing-to-webkit
>
>
> On Fri, Sep 25, 2009 at 12:14 PM, Andrew Scherkus 
> wrote:
>
>> For those that use third_party/WebKit as a full WebKit checkout, you'll
>> need to add the following line to your .gclient:
>>  "src/third_party/WebKit/WebKit/chromium": None,
>>
>> Andrew
>>
>>
>> On Fri, Sep 25, 2009 at 11:51 AM, Marc-Antoine Ruel 
>> wrote:
>>
>>>
>>> Yep, I specified one directory too deep.
>>>
>>> On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton 
>>> wrote:
>>> > To get mine to work, I had to
>>> >
>>> >  rm -rf src/third_party/WebKit/WebKit
>>> >
>>> > just doing "chromium" wasn't enough to stop the hangs.
>>> >
>>> > On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel <
>>> mar...@chromium.org> wrote:
>>> >>
>>> >> Your next gclient sync will probably hang. The easiest way to fix it
>>> is to:
>>> >>  rm -rf src/third_party/WebKit/WebKit/chromium
>>> >> or
>>> >>  rd /q /s src\third_party\WebKit\WebKit\chromium
>>> >>
>>> >> before syncing.
>>> >>
>>> >> Sorry for the trouble,
>>> >>
>>> >> M-A
>>> >>
>>> >> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > 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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Ben Goodger (Google)]

We should only allow this UI to be invoked from a user gesture.

-Ben

On Fri, Sep 25, 2009 at 12:41 PM, Jeremy Orlow  wrote:
> What's to keep sites from spamming you?  What if they spam you and then
> later you decide you want to install it anyway?
> I guess I misunderstood the model of this feature.  Seeing the bit about the
> rss feeds made me think that an app would use this to advertise that you
> could install it.  I didn't realize that we were assuming the API would only
> be called after a user action.  To be honest, I much prefer the rss feed way
> of thinking about it.
> I'm not a UI guy, though.  :-)
> On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) 
> wrote:
>>
>> As a result, I think we should have a dialog here. It's similar to what
>> Firefox does, too.
>> -Ben
>>
>> On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski 
>> wrote:
>>>
>>> In general, we've been operating under the assumption that a
>>> user-initiated gesture ("click here to make gmail your mailto handler")
>>> results in a dialog. Non-user-initiated (site intitiated) results in an
>>> infobar. If you've denied the infobar this in the past, the site will have
>>> to get you to click on something in its UI to prompt you for this again.
>>>
>>> On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting 
>>> wrote:

 On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow 
 wrote:
>
> If you click no on an info bar, then how would you later change your
> mind?

 I don't know.  Maybe at that point the icon appears in the address bar.
 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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Jeremy Orlow]

What's to keep sites from spamming you?  What if they spam you and then
later you decide you want to install it anyway?
I guess I misunderstood the model of this feature.  Seeing the bit about the
rss feeds made me think that an app would use this to advertise that you
could install it.  I didn't realize that we were assuming the API would only
be called after a user action.  To be honest, I much prefer the rss feed way
of thinking about it.

I'm not a UI guy, though.  :-)

On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) wrote:

> As a result, I think we should have a dialog here. It's similar to what
> Firefox does, too.
> -Ben
>
> On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski wrote:
>
>> In general, we've been operating under the assumption that a
>> user-initiated gesture ("click here to make gmail your mailto handler")
>> results in a dialog. Non-user-initiated (site intitiated) results in an
>> infobar. If you've denied the infobar this in the past, the site will have
>> to get you to click on something in its UI to prompt you for this again.
>>
>>
>> On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting wrote:
>>
>>> On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow wrote:
>>>
 If you click no on an info bar, then how would you later change your
 mind?
>>>
>>>
>>> I don't know.  Maybe at that point the icon appears in the address bar.
>>>
>>> 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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Ben Goodger (Google)]

As a result, I think we should have a dialog here. It's similar to what
Firefox does, too.
-Ben

On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski  wrote:

> In general, we've been operating under the assumption that a user-initiated
> gesture ("click here to make gmail your mailto handler") results in a
> dialog. Non-user-initiated (site intitiated) results in an infobar. If
> you've denied the infobar this in the past, the site will have to get you to
> click on something in its UI to prompt you for this again.
>
>
> On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting wrote:
>
>> On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow wrote:
>>
>>> If you click no on an info bar, then how would you later change your
>>> mind?
>>
>>
>> I don't know.  Maybe at that point the icon appears in the address bar.
>>
>> 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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Brian Rakowski]

In general, we've been operating under the assumption that a user-initiated
gesture ("click here to make gmail your mailto handler") results in a
dialog. Non-user-initiated (site intitiated) results in an infobar. If
you've denied the infobar this in the past, the site will have to get you to
click on something in its UI to prompt you for this again.

On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting  wrote:

> On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow wrote:
>
>> If you click no on an info bar, then how would you later change your mind?
>
>
> I don't know.  Maybe at that point the icon appears in the address bar.
>
> 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: gclient hang

[Jeremy Orlow]

I updated
http://sites.google.com/a/chromium.org/dev/developers/contributing-to-webkit

On Fri, Sep 25, 2009 at 12:14 PM, Andrew Scherkus wrote:

> For those that use third_party/WebKit as a full WebKit checkout, you'll
> need to add the following line to your .gclient:
>  "src/third_party/WebKit/WebKit/chromium": None,
>
> Andrew
>
>
> On Fri, Sep 25, 2009 at 11:51 AM, Marc-Antoine Ruel 
> wrote:
>
>>
>> Yep, I specified one directory too deep.
>>
>> On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton 
>> wrote:
>> > To get mine to work, I had to
>> >
>> >  rm -rf src/third_party/WebKit/WebKit
>> >
>> > just doing "chromium" wasn't enough to stop the hangs.
>> >
>> > On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel 
>> wrote:
>> >>
>> >> Your next gclient sync will probably hang. The easiest way to fix it is
>> to:
>> >>  rm -rf src/third_party/WebKit/WebKit/chromium
>> >> or
>> >>  rd /q /s src\third_party\WebKit\WebKit\chromium
>> >>
>> >> before syncing.
>> >>
>> >> Sorry for the trouble,
>> >>
>> >> M-A
>> >>
>> >> >>
>> >>
>> >
>> >
>> >
>> > --
>> > 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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Peter Kasting]

On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow  wrote:

> If you click no on an info bar, then how would you later change your mind?


I don't know.  Maybe at that point the icon appears in the address bar.

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: gclient hang

[Andrew Scherkus]

For those that use third_party/WebKit as a full WebKit checkout, you'll need
to add the following line to your .gclient:
 "src/third_party/WebKit/WebKit/chromium": None,

Andrew

On Fri, Sep 25, 2009 at 11:51 AM, Marc-Antoine Ruel wrote:

>
> Yep, I specified one directory too deep.
>
> On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton 
> wrote:
> > To get mine to work, I had to
> >
> >  rm -rf src/third_party/WebKit/WebKit
> >
> > just doing "chromium" wasn't enough to stop the hangs.
> >
> > On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel 
> wrote:
> >>
> >> Your next gclient sync will probably hang. The easiest way to fix it is
> to:
> >>  rm -rf src/third_party/WebKit/WebKit/chromium
> >> or
> >>  rd /q /s src\third_party\WebKit\WebKit\chromium
> >>
> >> before syncing.
> >>
> >> Sorry for the trouble,
> >>
> >> M-A
> >>
> >> >>
> >>
> >
> >
> >
> > --
> > 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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Jeremy Orlow]

If you click no on an info bar, then how would you later change your mind?
I really liked the proposal because it'd just always be there.  Much like
the RSS feed UI.

It seems like we can either just keep adding infobars or make an investment
in training users what these icons mean.

On Fri, Sep 25, 2009 at 11:36 AM, Peter Kasting  wrote:

> On Fri, Sep 25, 2009 at 11:33 AM, Brian Rakowski wrote:
>
>> I'm concerned that the page actions style Omnibox icon is not sufficient
>> notification for users that this capability exists. I'll add this to the
>> list of features for UI team to create mocks for.
>
>
> I agree, I think I'd prefer an infobar for this.  (/cue Glen hating on
> infobars)
>
> 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: gclient hang

[Marc-Antoine Ruel]

Yep, I specified one directory too deep.

On Fri, Sep 25, 2009 at 2:50 PM, Mike Pinkerton  wrote:
> To get mine to work, I had to
>
>  rm -rf src/third_party/WebKit/WebKit
>
> just doing "chromium" wasn't enough to stop the hangs.
>
> On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel  
> wrote:
>>
>> Your next gclient sync will probably hang. The easiest way to fix it is to:
>>  rm -rf src/third_party/WebKit/WebKit/chromium
>> or
>>  rd /q /s src\third_party\WebKit\WebKit\chromium
>>
>> before syncing.
>>
>> Sorry for the trouble,
>>
>> M-A
>>
>> >>
>>
>
>
>
> --
> 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: gclient hang

[Mike Pinkerton]

To get mine to work, I had to

  rm -rf src/third_party/WebKit/WebKit

just doing "chromium" wasn't enough to stop the hangs.

On Fri, Sep 25, 2009 at 2:36 PM, Marc-Antoine Ruel  wrote:
>
> Your next gclient sync will probably hang. The easiest way to fix it is to:
>  rm -rf src/third_party/WebKit/WebKit/chromium
> or
>  rd /q /s src\third_party\WebKit\WebKit\chromium
>
> before syncing.
>
> Sorry for the trouble,
>
> M-A
>
> >
>



-- 
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] gclient hang

[Marc-Antoine Ruel]

Your next gclient sync will probably hang. The easiest way to fix it is to:
  rm -rf src/third_party/WebKit/WebKit/chromium
or
  rd /q /s src\third_party\WebKit\WebKit\chromium

before syncing.

Sorry for the trouble,

M-A

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

[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API

[Peter Kasting]

On Fri, Sep 25, 2009 at 11:33 AM, Brian Rakowski  wrote:

> I'm concerned that the page actions style Omnibox icon is not sufficient
> notification for users that this capability exists. I'll add this to the
> list of features for UI team to create mocks for.


I agree, I think I'd prefer an infobar for this.  (/cue Glen hating on
infobars)

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: [DESIGN DOC] registerProtocolHandler HTML5 API

[Brian Rakowski]

I'm concerned that the page actions style Omnibox icon is not sufficient
notification for users that this capability exists. I'll add this to the
list of features for UI team to create mocks for.

On Thu, Sep 24, 2009 at 12:51 PM,  wrote:

>
> I've shared a document with you:
>
> [HTML5] registerProtocolHandler API
>
> http://docs.google.com/Doc?docid=0AVgZ1iILHLkdZGQ0bjd6cTVfMGdqZmpiNGZr&hl=en&invite=CI6z8vgG
>
> It's not an attachment -- it's stored online at Google Docs. To open this
> document, just click the link above.
>
>
> This is a design document for the worked needed to resolve
> http://crbug.com/11359 beyond the webkit implementation.
>
> Please feel free to comment inline or in this thread.  I look forward to
> your critics and suggestions.
>
> >
>

--~--~-~--~~~---~--~~
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: Debugging CachedResource memory leak in test_shell

[Marshall Greenblatt]

On Fri, Sep 25, 2009 at 10:42 AM, Marshall Greenblatt <
magreenbl...@gmail.com> wrote:

> On Thu, Sep 24, 2009 at 5:14 PM, Michael Nordman wrote:
>
>> I think there may be more than one code path to CachedResource removal.
>> 1. See DocLoader. It has a DocumentResourceMap that contains cached
>> resources that have been loaded for its Document. The collection gets poked
>> at in the ~DocLoader to clean things up.
>>
>> 2. During CacheResource validation. See
>> CachedResource.clearResourceToRevalidate and deleteIfPossible.
>>
>>
> Thanks Mike, I've identified the problem :-)
>
> The Cache object is a singleton that never gets deleted, so any
> CachedResource objects in the Cache will be leaked (inCache returns true in
> deleteIfPossible) by both test_shell and chromium when the renderer exits.
> It's possible to force deletion of everything in the cache by calling:
>
> WebCore::cache()->setDisabled(true);
>
> Would it be useful to do this when test_shell and the renderer process
> exits or is it better to just let these objects leak?
>

I've created a bug to track this:  http://crbug.com/23081


>
> Thanks,
> Marshall
>
>
>>
>> On Thu, Sep 24, 2009 at 1:35 PM, Marshall Greenblatt <
>> magreenbl...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I'm trying to debug the leak of CachedResource objects in test_shell.
>>> Every time I browse to a page that contains an image or CSS file a new
>>> CachedResource object is created in Cache.cpp createResource().  However,
>>> none of these objects are ever freed.  Does anyone happen to know where/how
>>> the CachedResource objects should be freed so that I can figure out why
>>> they're getting lost?
>>>
>>> Thanks,
>>> Marshall
>>>
>>> >>>
>>>
>>
>

--~--~-~--~~~---~--~~
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 time doubled since May - what gives?

[Marc-Antoine Ruel]

A lot of the projects link half-of-the-world when not necessary. I'm
working on that right now.

M-A

On Fri, Sep 25, 2009 at 2:12 PM, Ben Goodger (Google)  wrote:
> I would be surprised if it were just the addition of code. Bear in
> mind the May 7 minute figure includes all of WebKit, and I don't think
> that's doubled in size since then? So it seems like it must be
> something more related to the build system itself.
>
> I don't think it's incremental linking, since my build was a clean build.
>
> -Ben
>
> On Fri, Sep 25, 2009 at 11:09 AM, Nick Carter  wrote:
>> I'll volunteer to fix any build issues created as a result of sync.
>> Building the protobuf compiler (protoc.exe) emits a bunch of warnings -- the
>> bulk are signed/unsigned warnings.  I'll put together a change to suppress
>> those.
>>  - nick
>>
>> On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel 
>> wrote:
>>>
>>> Oh and a lot of warnings appeared recently. It is surprising how much
>>> warnings slow down the build, probably due to stdout serialization.
>>>
>>> http://code.google.com/p/chromium/issues/detail?id=23039
>>>
>>> M-A
>>>
>>> On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel 
>>> wrote:
>>> > http://code.google.com/p/chromium/issues/detail?id=21266
>>> >
>>> > This is a real problem, I just haven't looked into this one in
>>> > particular. Sometimes I just feel like renaming the dll...
>>> >
>>> > M-A
>>> >
>>> > On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour 
>>> > wrote:
>>> >> Hey Ben, same here ... I see this additional message today (havn't seen
>>> >> it
>>> >> before)
>>> >> 59>LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found
>>> >> or
>>> >> not built by the last incremental link; performing full link
>>> >>
>>> >> Changing one file used to take me 5 minutes to build. But now it takes
>>> >> me
>>> >> ~10-15 minutes.
>>> >> -Mohamed
>>> >>
>>> >>
>>> >> On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google)
>>> >> 
>>> >> wrote:
>>> >>>
>>> >>> I just ran a build here at home on my i7 workstation. It took 14
>>> >>> minutes. This is the same system that would build in 7 minutes when I
>>> >>> set it up in May.
>>> >>>
>>> >>> What gives? We need to figure this out ASAP.
>>> >>>
>>> >>> -Ben
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> >>
>>> >>
>>> >
>>>
>>> >>>
>>
>>
>

--~--~-~--~~~---~--~~
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 time doubled since May - what gives?

[Peter Kasting]

On Fri, Sep 25, 2009 at 11:09 AM, Nick Carter  wrote:

> I'll volunteer to fix any build issues created as a result of sync.
> Building the protobuf compiler (protoc.exe) emits a bunch of warnings --
> the bulk are signed/unsigned warnings.  I'll put together a change to
> suppress those.
>

It would be nice if we could fix those instead of just suppressing them.

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: Build time doubled since May - what gives?

[Ben Goodger (Google)]

I would be surprised if it were just the addition of code. Bear in
mind the May 7 minute figure includes all of WebKit, and I don't think
that's doubled in size since then? So it seems like it must be
something more related to the build system itself.

I don't think it's incremental linking, since my build was a clean build.

-Ben

On Fri, Sep 25, 2009 at 11:09 AM, Nick Carter  wrote:
> I'll volunteer to fix any build issues created as a result of sync.
> Building the protobuf compiler (protoc.exe) emits a bunch of warnings -- the
> bulk are signed/unsigned warnings.  I'll put together a change to suppress
> those.
>  - nick
>
> On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel 
> wrote:
>>
>> Oh and a lot of warnings appeared recently. It is surprising how much
>> warnings slow down the build, probably due to stdout serialization.
>>
>> http://code.google.com/p/chromium/issues/detail?id=23039
>>
>> M-A
>>
>> On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel 
>> wrote:
>> > http://code.google.com/p/chromium/issues/detail?id=21266
>> >
>> > This is a real problem, I just haven't looked into this one in
>> > particular. Sometimes I just feel like renaming the dll...
>> >
>> > M-A
>> >
>> > On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour 
>> > wrote:
>> >> Hey Ben, same here ... I see this additional message today (havn't seen
>> >> it
>> >> before)
>> >> 59>LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found
>> >> or
>> >> not built by the last incremental link; performing full link
>> >>
>> >> Changing one file used to take me 5 minutes to build. But now it takes
>> >> me
>> >> ~10-15 minutes.
>> >> -Mohamed
>> >>
>> >>
>> >> On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google)
>> >> 
>> >> wrote:
>> >>>
>> >>> I just ran a build here at home on my i7 workstation. It took 14
>> >>> minutes. This is the same system that would build in 7 minutes when I
>> >>> set it up in May.
>> >>>
>> >>> What gives? We need to figure this out ASAP.
>> >>>
>> >>> -Ben
>> >>>
>> >>>
>> >>
>> >>
>> >> >>
>> >>
>> >
>>
>> >>
>
>

--~--~-~--~~~---~--~~
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 time doubled since May - what gives?

[Nick Carter]

I'll volunteer to fix any build issues created as a result of sync.
Building the protobuf compiler (protoc.exe) emits a bunch of warnings -- the
bulk are signed/unsigned warnings.  I'll put together a change to suppress
those.

 - nick

On Fri, Sep 25, 2009 at 6:34 AM, Marc-Antoine Ruel wrote:

>
> Oh and a lot of warnings appeared recently. It is surprising how much
> warnings slow down the build, probably due to stdout serialization.
>
> http://code.google.com/p/chromium/issues/detail?id=23039
>
> M-A
>
> On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel 
> wrote:
> > http://code.google.com/p/chromium/issues/detail?id=21266
> >
> > This is a real problem, I just haven't looked into this one in
> > particular. Sometimes I just feel like renaming the dll...
> >
> > M-A
> >
> > On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour 
> wrote:
> >> Hey Ben, same here ... I see this additional message today (havn't seen
> it
> >> before)
> >> 59>LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found
> or
> >> not built by the last incremental link; performing full link
> >>
> >> Changing one file used to take me 5 minutes to build. But now it takes
> me
> >> ~10-15 minutes.
> >> -Mohamed
> >>
> >>
> >> On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) <
> b...@chromium.org>
> >> wrote:
> >>>
> >>> I just ran a build here at home on my i7 workstation. It took 14
> >>> minutes. This is the same system that would build in 7 minutes when I
> >>> set it up in May.
> >>>
> >>> What gives? We need to figure this out ASAP.
> >>>
> >>> -Ben
> >>>
> >>>
> >>
> >>
> >> >>
> >>
> >
>
> >
>

--~--~-~--~~~---~--~~
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: Kiosk Mode for Chrome

[Jeremy Orlow]

No objections.
I think it's a good idea, you're not the only one who wants this, and it
seems like it can be done very cleanly.

On Fri, Sep 25, 2009 at 10:47 AM, Adam Barth  wrote:

> On Fri, Sep 25, 2009 at 10:43 AM, Mohamed Mansour 
> wrote:
> > I could submit a cleaner patch (which does it right) that introduces
> Kiosk
> > mode for Chrome. Are there any objections?
>
> None from me.  :)
>
> 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: Kiosk Mode for Chrome

[Adam Barth]

On Fri, Sep 25, 2009 at 10:43 AM, Mohamed Mansour  wrote:
> I could submit a cleaner patch (which does it right) that introduces Kiosk
> mode for Chrome. Are there any objections?

None from me.  :)

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: Kiosk Mode for Chrome

[Mohamed Mansour]

Hi Jeremy, ChromeFrame doesn't seem to work if you pass the URL in command
line for Internet Explorer. A simple example is visiting this page directly
(assuming you installed ChromeFrame)

   1. Open Internet Explorer
   2. Visit this http://haptisense.com/
   3. You will see the correct "After Browser" which is Chrome and "Original
   Browser" which is IE.

Now do this:

   1. cd "C:\Program Files\Internet Explorer"
   2. Type:  iexplorer.exe http://haptisense.com
   3. You will see the correct "Original Browser" but the "After Browser" is
   still IE (you can notice the Chrome renderer isn't replaced because there is
   IE right click and rendering is obviously IE)

Same thing happens to iexplorer.exe -k http://haptisense.com

The patch I submitted, does what I wanted to do for demo purposes, I
contribute to Chrome because I love everything about this browser, and
seeing the usage of IE in my day job is quite annoying (since our GIS web
apps are plotting horribly slow in comparison to Chrome if given a lot of
data).

I could submit a cleaner patch (which does it right) that introduces Kiosk
mode for Chrome. Are there any *objections*?

 -Mohamed


On Fri, Sep 25, 2009 at 12:51 PM, Jeremy Orlow  wrote:

> On Fri, Sep 25, 2009 at 5:30 AM, Mohamed Mansour  wrote:
>
>> I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode
>> flag is set. If the Kiosk mode is set ( iexplorer.exe -k
>> http://www.google.com ) it renders it as IE Renderer. It renders it fine
>> in a Chrome Frame if its not in Kiosk mode. That must be a bug :)
>
>
> wait, did you do '... -k cf:http://www.google.com'?  (Or does the Google
> home page use Chrome Frame?)
>
> (Not that I'm saying this is the right route.  It sounds like a command
> line flag for Chrome might be the best way to go!)
>
> For IE, kiosk mode has a context menu, but people usually apply the
>> registry tweak to remove context menu from IE if they need to.
>>
>> For Chromium, it would be nice if stuff like this would be an extension,
>> an extension should allow us to show/hide various parts of the UI. In the
>> meantime, I quickly compiled a custom Chromium so that my CEO and VP could
>> see the benefits of using Chrome instead of IE on some of our web products.
>>
>> Stuff that would be cool and would be very lightweight to include for
>> kiosk mode would be:
>> - No Status Bar- Full Screen (with no exit, only alt+f4 should work)
>> - No Context Menus (should be an option)
>> - Disable downloading of files.
>> - No tabs
>> - No opening files
>> - many more
>>
>> I would rather that be an extension (but there are currently no way to
>> actually block users to remove extensions, maybe blocking users entering a
>> url would suffice) but not possible currently.
>>
>>  -Mohamed
>>
>>
>>
>> On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi  wrote:
>>
>>>
>>>
>>> On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher wrote:
>>>
 Chrome Frame is a good option, but you'd still need a way to turn off
 some features.  For example, a kiosk probably doesn't want to have a 
 context
 menu.
>>>
>>>
>>> Chrome Frame can/will offer control over the context menu. This is
>>> exactly the kind of customization Chrome Frame can offer. Too bad we don't
>>> have Linux, Mac versions yet, but we are open source now so patches welcome
>>> :)
>>>
>>>
 -Darin


 On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi  wrote:

> I think you should really consider embedding chrome frame ActiveX in
> your own simple shell. That will not only enable the application to be
> started with desired real estate and get rid of status bubble but allow 
> you
> to customize it further if needed.
>
> On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher wrote:
>
>>
>> On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour 
>> wrote:
>>
>>> At work today, I talked to the CEO of my company to ship Chrome
>>> browser with all our Kiosk's and recommended Chrome to be our default
>>> browser for our web products. I bench marked our current web 
>>> applications
>>> with Chrome (ToT) vs IE 7, and our applications run at average 10 times
>>> faster. (For windows, Mac speed differed)
>>> There are some stuff that he didn't like:
>>>
>>>1. Status Bubble: for a cashiering application, it keeps popping
>>>up every second since buttons are all over the place. It was 
>>> distracting him
>>>from the main product.
>>>2. Full screen mode "always" => Kiosk Mode. He wants the web app
>>>to stay full screen, in IE, there is kiosk mode command line switch. 
>>> In FF
>>>there is a plugin.
>>>3. JavaScript errors kept appearing intermittently (on the Mac),
>>>would work on initial deploy but require a "Clear browsing data" on
>>>subsequent runs. Works great on windows (chrome). I guess we would 
>>> be using
>>>linux/windows for kiosk anyhow.

[chromium-dev] Re: Question about UI and "classic views"

[Nico Weber]

On Fri, Sep 25, 2009 at 10:24 AM, Darin Fisher  wrote:
> On Fri, Sep 25, 2009 at 10:22 AM, Nico Weber  wrote:
>>
>> >> At times, we seem to forget the impact of our silent updates.  They are
>> >> great for bug/security fixes, but when we do roll out something like
>> >> NNTP,
>> >> it can lead to a 'WTF' moment.  For future changes like this, it might
>> >> make
>> >> sense to put in messaging for the upgrade so the users get lead through
>> >> the
>> >> transition instead of their routine suddenly changing on them.
>> >
>> > All software, and all browsers, change their UI and capabilities as they
>> > release new versions.  Look at how Firefox 1.0, 2.0, 3.0, and 3.5 all
>> > had
>> > different main window themes (and not just cosmetically; they moved
>> > pieces
>> > around and changed the UX).  It's not like there was a "--use_2_0_theme"
>> > switch when 3.0 released.
>> > Users complain about anything that changes.  This is why user complaints
>> > should be an input, but not a hugely-weighted one.
>>
>> FWIW, Firefox uses can choose not to update to a new version if they
>> don't like the new UI though ( and some people mention this explicitly
>> as a reason for not updating:
>>
>> http://blog.mozilla.com/metrics/2009/08/21/why-people-dont-upgrade-their-browser-part-i/
>> ).
>
> It's also not something Mozilla supports.  Eventually, they stop offering
> security updates
> for old versions.

Sure, and I guess most people update eventually, but they can go
through their five stages of grief at their own speed. With
autoupdate, they get the new UI while they might still be in the
Denial or Anger stages :-)

--~--~-~--~~~---~--~~
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: Question about UI and "classic views"

[Amanda Walker]

On Fri, Sep 25, 2009 at 1:11 PM, Peter Kasting  wrote:

> All software, and all browsers, change their UI and capabilities as they
> release new versions.  Look at how Firefox 1.0, 2.0, 3.0, and 3.5 all had
> different main window themes (and not just cosmetically; they moved pieces
> around and changed the UX).  It's not like there was a "--use_2_0_theme"
> switch when 3.0 released.
>

Sure.  But it's not like users came in one day and their copy of 2.0 had
changed into 3.0.  Autoupdate (which is a good thing overall, don't get me
wrong) is different from a user-initiated upgrade in this respect.

--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: Question about UI and "classic views"

[Darin Fisher]

On Fri, Sep 25, 2009 at 10:22 AM, Nico Weber  wrote:

> >> At times, we seem to forget the impact of our silent updates.  They are
> >> great for bug/security fixes, but when we do roll out something like
> NNTP,
> >> it can lead to a 'WTF' moment.  For future changes like this, it might
> make
> >> sense to put in messaging for the upgrade so the users get lead through
> the
> >> transition instead of their routine suddenly changing on them.
> >
> > All software, and all browsers, change their UI and capabilities as they
> > release new versions.  Look at how Firefox 1.0, 2.0, 3.0, and 3.5 all had
> > different main window themes (and not just cosmetically; they moved
> pieces
> > around and changed the UX).  It's not like there was a "--use_2_0_theme"
> > switch when 3.0 released.
> > Users complain about anything that changes.  This is why user complaints
> > should be an input, but not a hugely-weighted one.
>
> FWIW, Firefox uses can choose not to update to a new version if they
> don't like the new UI though ( and some people mention this explicitly
> as a reason for not updating:
>
> http://blog.mozilla.com/metrics/2009/08/21/why-people-dont-upgrade-their-browser-part-i/
> ).
>

It's also not something Mozilla supports.  Eventually, they stop offering
security updates
for old versions.
-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: Question about UI and "classic views"

[Nico Weber]

>> At times, we seem to forget the impact of our silent updates.  They are
>> great for bug/security fixes, but when we do roll out something like NNTP,
>> it can lead to a 'WTF' moment.  For future changes like this, it might make
>> sense to put in messaging for the upgrade so the users get lead through the
>> transition instead of their routine suddenly changing on them.
>
> All software, and all browsers, change their UI and capabilities as they
> release new versions.  Look at how Firefox 1.0, 2.0, 3.0, and 3.5 all had
> different main window themes (and not just cosmetically; they moved pieces
> around and changed the UX).  It's not like there was a "--use_2_0_theme"
> switch when 3.0 released.
> Users complain about anything that changes.  This is why user complaints
> should be an input, but not a hugely-weighted one.

FWIW, Firefox uses can choose not to update to a new version if they
don't like the new UI though ( and some people mention this explicitly
as a reason for not updating:
http://blog.mozilla.com/metrics/2009/08/21/why-people-dont-upgrade-their-browser-part-i/
).

--~--~-~--~~~---~--~~
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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.

[Jeremy Orlow]

On Fri, Sep 25, 2009 at 10:01 AM, Amanda Walker  wrote:

> On Tue, Sep 22, 2009 at 9:06 PM, Dimitri Glazkov wrote:
>
>> This all means that we have to be a bit more diligent. We shouldn't be
>> paying these unnecessary costs. So, from now on, I propose a fairly
>> simple set of new rules:
>>
>> 1) if you write a Chromium patch for WebKit, you must provide URLs of
>> successful trybot runs with your submission. Chromium WebKit reviewers
>> will not r+ your patch otherwise. If you can't provide the trybot URLs
>> for some reason, please explain in detail why this patch could still
>> land.
>>
>> 2) if the two-sided patch you authored broke the canary and this
>> happened with no coordination with the WebKit gardener, you assume
>> WebKit gardening responsibility for the next 24 hours.
>>
>> Hopefully, these amendments to our existing ways will bring a bit more
>> peace and stability to the Chromium land. What do you think?
>>
>
> I think they're a good start, but they are symptoms of a larger problem.
>  "Move fast and clean up messes when they happen" worked great when we had
> one big mess a week.  These days, we have multiple ones per day.  And as
> good as the try bots and canaries are (kudos to M-A for setting up the try
> bots in the first place, and everyone who helps keep the ever-growing herd
> of bots running), they don't catch everything.  They don't catch build time
> regressions because someone forgot svn:ignores when refactoring where
> projects get generated, or accidentally checks something into the wrong
> directory (not to pick on anyone in particular, these are just recent
> examples).
>
> I'd add a 3rd principle:
>
> 3) If you change how chromium is built, however innocuous your change seems
> (gyp changes, new libraries, etc.), take extra care and use more reviewers
> than usual (preferably including someone intimately acquainted with the
> bots, such as maruel, thomasvl, markmentovai, nsylvain, etc.).  If you're
> reviewing such a change, don't just look at the diffs, try out the patch and
> flag anything that seems out of the ordinary.  "Build breakage" means more
> than just "doesn't compile"; it can also mean "overcompiles" (which kills
> bot performance) or "requires a clobber unnecessarily."
>

I had to land a 2 sided patch yesterday.  It blew up an important unit test
in a very creative way, and we're still trying to figure out how to clean it
up nicely.  In the mean time, we have a dev channel release blocker.  There
has to be a better way...

Here's a crazy idea:

4) Create a WebKit.next branch.  Have full build bot coverage on it.  All
integrations would go through it.  Other than that, only 2 sided patches
would land on it.  Whenever everything passes, we'd merge in with the main
branch.  We'd try very hard never to let it get more than a day or so out of
sync.

This would make 2 sided merges (which are often the reason for rushing a
DEPS roll--don't want to keep the canary red for too long, otherwise it's
very hard to sort things out) much less haphazard.  We could even have it
roll the DEPS automatically every time a new webkit.org patch lands, and
thus eliminate our need for dedicated canaries.

Yeah, it's crazybut I kind of like it.  And yeah, when the WebKit API
lands things should be better in terms of others breaking us, but this
addresses 2 sided patches...which are not going away any time soon.

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] buildbot failure in Chromium on Linux Builder (ChromeOS), revision 27199

[buildbot]

Automatically closing tree for "compile" on "Linux Builder (ChromeOS)"

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromeOS%29/builds/3542

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromeOS%29

--=>  Automatically closing tree for "compile" on "Linux Builder (ChromeOS)"  
<=--

Revision: 27199
Blame list: t...@chromium.org

Buildbot waterfall: http://build.chromium.org/

--~--~-~--~~~---~--~~
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: Question about UI and "classic views"

[Peter Kasting]

On Fri, Sep 25, 2009 at 7:16 AM, Thomas Van Lenten wrote:

> At times, we seem to forget the impact of our silent updates.  They are
> great for bug/security fixes, but when we do roll out something like NNTP,
> it can lead to a 'WTF' moment.  For future changes like this, it might make
> sense to put in messaging for the upgrade so the users get lead through the
> transition instead of their routine suddenly changing on them.
>

All software, and all browsers, change their UI and capabilities as they
release new versions.  Look at how Firefox 1.0, 2.0, 3.0, and 3.5 all had
different main window themes (and not just cosmetically; they moved pieces
around and changed the UX).  It's not like there was a "--use_2_0_theme"
switch when 3.0 released.

Users complain about anything that changes.  This is why user complaints
should be an input, but not a hugely-weighted one.

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: Question about UI and "classic views"

[Darin Fisher]

On Fri, Sep 25, 2009 at 7:07 AM, Amanda Walker  wrote:

> On Thu, Sep 24, 2009 at 3:11 AM, Darin Fisher  wrote:
>
>> Do websites provide users with previous versions after overhauling their
>> UX?  Some do (gmail seems to), but most do not.  You just get to surf the
>> latest.  Hopefully, the website changes for the better.  That's our burden
>> to bear.
>
>
> And other browsers are just a double-click away :-).  One difference
> between the NTP and a random website is that users think of the NTP as their
> content (see for example the wording in the complaint from Mike's sister at
> the start of this thread).  Web sites that show user-generated (or in this
> case, user-arranged) content tend to get more complaints about large visual
> changes than more passive or static sites (example: see all of the uproar
> whenever Facebook changes their UI).
>
> Personally, I like the latest version of the NTP, but I would be wary of
> lumping it in with websites in general when we're trying to understand user
> expectations.
>
> --Amanda
>
>

My comment applied to the entire browser.  We silently update it just like
websites are silently updated.
-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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.

[Amanda Walker]

On Tue, Sep 22, 2009 at 9:06 PM, Dimitri Glazkov wrote:

> This all means that we have to be a bit more diligent. We shouldn't be
> paying these unnecessary costs. So, from now on, I propose a fairly
> simple set of new rules:
>
> 1) if you write a Chromium patch for WebKit, you must provide URLs of
> successful trybot runs with your submission. Chromium WebKit reviewers
> will not r+ your patch otherwise. If you can't provide the trybot URLs
> for some reason, please explain in detail why this patch could still
> land.
>
> 2) if the two-sided patch you authored broke the canary and this
> happened with no coordination with the WebKit gardener, you assume
> WebKit gardening responsibility for the next 24 hours.
>
> Hopefully, these amendments to our existing ways will bring a bit more
> peace and stability to the Chromium land. What do you think?
>

I think they're a good start, but they are symptoms of a larger problem.
 "Move fast and clean up messes when they happen" worked great when we had
one big mess a week.  These days, we have multiple ones per day.  And as
good as the try bots and canaries are (kudos to M-A for setting up the try
bots in the first place, and everyone who helps keep the ever-growing herd
of bots running), they don't catch everything.  They don't catch build time
regressions because someone forgot svn:ignores when refactoring where
projects get generated, or accidentally checks something into the wrong
directory (not to pick on anyone in particular, these are just recent
examples).

I'd add a 3rd principle:

3) If you change how chromium is built, however innocuous your change seems
(gyp changes, new libraries, etc.), take extra care and use more reviewers
than usual (preferably including someone intimately acquainted with the
bots, such as maruel, thomasvl, markmentovai, nsylvain, etc.).  If you're
reviewing such a change, don't just look at the diffs, try out the patch and
flag anything that seems out of the ordinary.  "Build breakage" means more
than just "doesn't compile"; it can also mean "overcompiles" (which kills
bot performance) or "requires a clobber unnecessarily."

--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] buildbot failure in Chromium on Linux Builder (Views dbg), revision 27196

[buildbot]

Automatically closing tree for "compile" on "Linux Builder (Views dbg)"

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28Views%20dbg%29/builds/1202

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28Views%20dbg%29

--=>  Automatically closing tree for "compile" on "Linux Builder (Views dbg)"  
<=--

Revision: 27196
Blame list: pkast...@chromium.org

Buildbot waterfall: http://build.chromium.org/

--~--~-~--~~~---~--~~
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: Kiosk Mode for Chrome

[Jeremy Orlow]

On Fri, Sep 25, 2009 at 5:30 AM, Mohamed Mansour  wrote:

> I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode
> flag is set. If the Kiosk mode is set ( iexplorer.exe -k
> http://www.google.com ) it renders it as IE Renderer. It renders it fine
> in a Chrome Frame if its not in Kiosk mode. That must be a bug :)


wait, did you do '... -k cf:http://www.google.com'?  (Or does the Google
home page use Chrome Frame?)

(Not that I'm saying this is the right route.  It sounds like a command line
flag for Chrome might be the best way to go!)

For IE, kiosk mode has a context menu, but people usually apply the registry
> tweak to remove context menu from IE if they need to.
>
> For Chromium, it would be nice if stuff like this would be an extension, an
> extension should allow us to show/hide various parts of the UI. In the
> meantime, I quickly compiled a custom Chromium so that my CEO and VP could
> see the benefits of using Chrome instead of IE on some of our web products.
>
> Stuff that would be cool and would be very lightweight to include for kiosk
> mode would be:
> - No Status Bar- Full Screen (with no exit, only alt+f4 should work)
> - No Context Menus (should be an option)
> - Disable downloading of files.
> - No tabs
> - No opening files
> - many more
>
> I would rather that be an extension (but there are currently no way to
> actually block users to remove extensions, maybe blocking users entering a
> url would suffice) but not possible currently.
>
>  -Mohamed
>
>
>
> On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi  wrote:
>
>>
>>
>> On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher wrote:
>>
>>> Chrome Frame is a good option, but you'd still need a way to turn off
>>> some features.  For example, a kiosk probably doesn't want to have a context
>>> menu.
>>
>>
>> Chrome Frame can/will offer control over the context menu. This is exactly
>> the kind of customization Chrome Frame can offer. Too bad we don't have
>> Linux, Mac versions yet, but we are open source now so patches welcome :)
>>
>>
>>> -Darin
>>>
>>>
>>> On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi  wrote:
>>>
 I think you should really consider embedding chrome frame ActiveX in
 your own simple shell. That will not only enable the application to be
 started with desired real estate and get rid of status bubble but allow you
 to customize it further if needed.

 On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher wrote:

>
> On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour 
> wrote:
>
>> At work today, I talked to the CEO of my company to ship Chrome
>> browser with all our Kiosk's and recommended Chrome to be our default
>> browser for our web products. I bench marked our current web applications
>> with Chrome (ToT) vs IE 7, and our applications run at average 10 times
>> faster. (For windows, Mac speed differed)
>> There are some stuff that he didn't like:
>>
>>1. Status Bubble: for a cashiering application, it keeps popping
>>up every second since buttons are all over the place. It was 
>> distracting him
>>from the main product.
>>2. Full screen mode "always" => Kiosk Mode. He wants the web app
>>to stay full screen, in IE, there is kiosk mode command line switch. 
>> In FF
>>there is a plugin.
>>3. JavaScript errors kept appearing intermittently (on the Mac),
>>would work on initial deploy but require a "Clear browsing data" on
>>subsequent runs. Works great on windows (chrome). I guess we would be 
>> using
>>linux/windows for kiosk anyhow.
>>
>> Will there be plans for us to introduce Kiosk Mode in Chrome? It seems
>> the current audience is just targeted towards home users and there is no 
>> way
>> to use Google Chrome for other usages.
>>
>> Sure we could compile our own Chromium version, but many people
>> (Chrome forums and elsewhere) would like to use Chrome commercially. In 
>> the
>> meantime, I am going to compile a version with no status bar, but I 
>> believe
>> it would be nice to include it in future versions.
>>
>> Maybe we could allow extensions to control (hide/show) different areas
>> in chrome.
>>
>>
>
> Maybe I'm in the minority, but it doesn't sound that unreasonable to
> support command line options for disabling the status bubble and starting 
> in
> full screen mode.  We could lump these together into a --kiosk-mode 
> command
> line flag.  This seems like something that could be done in a fairly
> lightweight manner.
>
> Maybe others object?
>
> -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: Kiosk Mode for Chrome

[Marc-Antoine Ruel]

Well, Mohamed's patch is *way* simpler and portable.

On Fri, Sep 25, 2009 at 12:40 PM, Amit Joshi  wrote:
> Sorry for not being clear. What I meant was that you could create your own
> kiosk shell and embed Chrome Frame as ActiveX control to render the pages
> you want in it. That way you could customize different features up to your
> own satisfaction.
>
> On Fri, Sep 25, 2009 at 5:30 AM, Mohamed Mansour  wrote:
>>
>> I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode
>> flag is set. If the Kiosk mode is set ( iexplorer.exe -k
>> http://www.google.com ) it renders it as IE Renderer. It renders it fine in
>> a Chrome Frame if its not in Kiosk mode. That must be a bug :)
>> For IE, kiosk mode has a context menu, but people usually apply the
>> registry tweak to remove context menu from IE if they need to.
>> For Chromium, it would be nice if stuff like this would be an extension,
>> an extension should allow us to show/hide various parts of the UI. In the
>> meantime, I quickly compiled a custom Chromium so that my CEO and VP could
>> see the benefits of using Chrome instead of IE on some of our web products.
>>
>> Stuff that would be cool and would be very lightweight to include for
>> kiosk mode would be:
>> - No Status Bar
>> - Full Screen (with no exit, only alt+f4 should work)
>> - No Context Menus (should be an option)
>> - Disable downloading of files.
>> - No tabs
>> - No opening files
>> - many more
>> I would rather that be an extension (but there are currently no way to
>> actually block users to remove extensions, maybe blocking users entering a
>> url would suffice) but not possible currently.
>>  -Mohamed
>>
>>
>> On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi  wrote:
>>>
>>>
>>> On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher 
>>> wrote:

 Chrome Frame is a good option, but you'd still need a way to turn off
 some features.  For example, a kiosk probably doesn't want to have a 
 context
 menu.
>>>
>>> Chrome Frame can/will offer control over the context menu. This is
>>> exactly the kind of customization Chrome Frame can offer. Too bad we don't
>>> have Linux, Mac versions yet, but we are open source now so patches welcome
>>> :)

 -Darin

 On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi  wrote:
>
> I think you should really consider embedding chrome frame ActiveX in
> your own simple shell. That will not only enable the application to be
> started with desired real estate and get rid of status bubble but allow 
> you
> to customize it further if needed.
>
> On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher 
> wrote:
>>
>> On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour 
>> wrote:
>>>
>>> At work today, I talked to the CEO of my company to ship Chrome
>>> browser with all our Kiosk's and recommended Chrome to be our default
>>> browser for our web products. I bench marked our current web 
>>> applications
>>> with Chrome (ToT) vs IE 7, and our applications run at average 10 times
>>> faster. (For windows, Mac speed differed)
>>> There are some stuff that he didn't like:
>>>
>>> Status Bubble: for a cashiering application, it keeps popping up
>>> every second since buttons are all over the place. It was distracting 
>>> him
>>> from the main product.
>>> Full screen mode "always" => Kiosk Mode. He wants the web app to stay
>>> full screen, in IE, there is kiosk mode command line switch. In FF 
>>> there is
>>> a plugin.
>>> JavaScript errors kept appearing intermittently (on the Mac), would
>>> work on initial deploy but require a "Clear browsing data" on subsequent
>>> runs. Works great on windows (chrome). I guess we would be using
>>> linux/windows for kiosk anyhow.
>>>
>>> Will there be plans for us to introduce Kiosk Mode in Chrome? It
>>> seems the current audience is just targeted towards home users and 
>>> there is
>>> no way to use Google Chrome for other usages.
>>> Sure we could compile our own Chromium version, but many people
>>> (Chrome forums and elsewhere) would like to use Chrome commercially. In 
>>> the
>>> meantime, I am going to compile a version with no status bar, but I 
>>> believe
>>> it would be nice to include it in future versions.
>>> Maybe we could allow extensions to control (hide/show) different
>>> areas in chrome.
>>
>>
>> Maybe I'm in the minority, but it doesn't sound that unreasonable to
>> support command line options for disabling the status bubble and 
>> starting in
>> full screen mode.  We could lump these together into a --kiosk-mode 
>> command
>> line flag.  This seems like something that could be done in a fairly
>> lightweight manner.
>> Maybe others object?
>> -Darin
>>
>

>>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Deve

[chromium-dev] Re: Kiosk Mode for Chrome

[Amit Joshi]

Sorry for not being clear. What I meant was that you could create your own
kiosk shell and embed Chrome Frame as ActiveX control to render the pages
you want in it. That way you could customize different features up to your
own satisfaction.

On Fri, Sep 25, 2009 at 5:30 AM, Mohamed Mansour  wrote:

> I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode
> flag is set. If the Kiosk mode is set ( iexplorer.exe -k
> http://www.google.com ) it renders it as IE Renderer. It renders it fine
> in a Chrome Frame if its not in Kiosk mode. That must be a bug :)
> For IE, kiosk mode has a context menu, but people usually apply the
> registry tweak to remove context menu from IE if they need to.
>
> For Chromium, it would be nice if stuff like this would be an extension, an
> extension should allow us to show/hide various parts of the UI. In the
> meantime, I quickly compiled a custom Chromium so that my CEO and VP could
> see the benefits of using Chrome instead of IE on some of our web products.
>
> Stuff that would be cool and would be very lightweight to include for kiosk
> mode would be:
> - No Status Bar- Full Screen (with no exit, only alt+f4 should work)
> - No Context Menus (should be an option)
> - Disable downloading of files.
> - No tabs
> - No opening files
> - many more
>
> I would rather that be an extension (but there are currently no way to
> actually block users to remove extensions, maybe blocking users entering a
> url would suffice) but not possible currently.
>
>  -Mohamed
>
>
>
> On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi  wrote:
>
>>
>>
>> On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher wrote:
>>
>>> Chrome Frame is a good option, but you'd still need a way to turn off
>>> some features.  For example, a kiosk probably doesn't want to have a context
>>> menu.
>>
>>
>> Chrome Frame can/will offer control over the context menu. This is exactly
>> the kind of customization Chrome Frame can offer. Too bad we don't have
>> Linux, Mac versions yet, but we are open source now so patches welcome :)
>>
>>
>>> -Darin
>>>
>>>
>>> On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi  wrote:
>>>
 I think you should really consider embedding chrome frame ActiveX in
 your own simple shell. That will not only enable the application to be
 started with desired real estate and get rid of status bubble but allow you
 to customize it further if needed.

 On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher wrote:

>
> On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour 
> wrote:
>
>> At work today, I talked to the CEO of my company to ship Chrome
>> browser with all our Kiosk's and recommended Chrome to be our default
>> browser for our web products. I bench marked our current web applications
>> with Chrome (ToT) vs IE 7, and our applications run at average 10 times
>> faster. (For windows, Mac speed differed)
>> There are some stuff that he didn't like:
>>
>>1. Status Bubble: for a cashiering application, it keeps popping
>>up every second since buttons are all over the place. It was 
>> distracting him
>>from the main product.
>>2. Full screen mode "always" => Kiosk Mode. He wants the web app
>>to stay full screen, in IE, there is kiosk mode command line switch. 
>> In FF
>>there is a plugin.
>>3. JavaScript errors kept appearing intermittently (on the Mac),
>>would work on initial deploy but require a "Clear browsing data" on
>>subsequent runs. Works great on windows (chrome). I guess we would be 
>> using
>>linux/windows for kiosk anyhow.
>>
>> Will there be plans for us to introduce Kiosk Mode in Chrome? It seems
>> the current audience is just targeted towards home users and there is no 
>> way
>> to use Google Chrome for other usages.
>>
>> Sure we could compile our own Chromium version, but many people
>> (Chrome forums and elsewhere) would like to use Chrome commercially. In 
>> the
>> meantime, I am going to compile a version with no status bar, but I 
>> believe
>> it would be nice to include it in future versions.
>>
>> Maybe we could allow extensions to control (hide/show) different areas
>> in chrome.
>>
>>
>
> Maybe I'm in the minority, but it doesn't sound that unreasonable to
> support command line options for disabling the status bubble and starting 
> in
> full screen mode.  We could lump these together into a --kiosk-mode 
> command
> line flag.  This seems like something that could be done in a fairly
> lightweight manner.
>
> Maybe others object?
>
> -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: flaky resource failures

[Paweł Hajdan Jr .]

On Fri, Sep 25, 2009 at 05:26, Thomas Van Lenten wrote:

> On Thu, Sep 24, 2009 at 6:24 PM, Paweł Hajdan Jr.  > wrote:
>
>> On Thu, Sep 24, 2009 at 12:24, Thomas Van Lenten 
>> wrote:
>>
>>> Brad landed support for depending on all the python files that go into
>>> grit, so that part would have worked.  The not always rebuilding for .h
>>> files is the problem.
>>>
>> Does it mean we're missing some deps in the gyp files?
>>
> Shouldn't.  The IDEs should be figuring out what .h files are included by
> each .cc/.m/.mm/.etc and rebuild as needed.
>

The issue seems to occur only on Windows, which means Visual Studio. Isn't
its dependency tracking known to be unreliable? I really don't know how it
works (is there some docs which documents the quirks?).

--~--~-~--~~~---~--~~
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: Debugging CachedResource memory leak in test_shell

[Marshall Greenblatt]

On Thu, Sep 24, 2009 at 5:14 PM, Michael Nordman wrote:

> I think there may be more than one code path to CachedResource removal.
> 1. See DocLoader. It has a DocumentResourceMap that contains cached
> resources that have been loaded for its Document. The collection gets poked
> at in the ~DocLoader to clean things up.
>
> 2. During CacheResource validation. See
> CachedResource.clearResourceToRevalidate and deleteIfPossible.
>
>
Thanks Mike, I've identified the problem :-)

The Cache object is a singleton that never gets deleted, so any
CachedResource objects in the Cache will be leaked (inCache returns true in
deleteIfPossible) by both test_shell and chromium when the renderer exits.
It's possible to force deletion of everything in the cache by calling:

WebCore::cache()->setDisabled(true);

Would it be useful to do this when test_shell and the renderer process exits
or is it better to just let these objects leak?

Thanks,
Marshall


>
> On Thu, Sep 24, 2009 at 1:35 PM, Marshall Greenblatt <
> magreenbl...@gmail.com> wrote:
>
>> Hi All,
>>
>> I'm trying to debug the leak of CachedResource objects in test_shell.
>> Every time I browse to a page that contains an image or CSS file a new
>> CachedResource object is created in Cache.cpp createResource().  However,
>> none of these objects are ever freed.  Does anyone happen to know where/how
>> the CachedResource objects should be freed so that I can figure out why
>> they're getting lost?
>>
>> Thanks,
>> Marshall
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Kiosk Mode for Chrome

[Mohamed Mansour]

Something as simple as this:http://codereview.chromium.org/244003

Not necessarily clean, but this
thread is whether we would want to implement Kiosk mode in Chromium. That
will help many companies to use Chromium as their solution for hosting their
web products.

 -Mohamed


On Fri, Sep 25, 2009 at 8:47 AM, PhistucK  wrote:

> What are the major issues?Full screen with no escape hatch and no status
> bubble?
> Chrome developers already said the are willing to take care of those\accept
> patches for those.
> The rest are taken care of with disabling keyboard shortcuts, or am I
> wrong?
>
> ☆PhistucK
>
>
>
> On Fri, Sep 25, 2009 at 15:44, Mohamed Mansour  wrote:
>
>> The minor issues, yes, the major issues, no.
>>  -Mohamed
>>
>>
>>
>> On Fri, Sep 25, 2009 at 8:40 AM, PhistucK  wrote:
>>
>>> You can create a content script that will disable the shortcut keys of
>>> the browser and the right clicks, on all of the pages.About browsing to
>>> other pages (and so, downloading), you can apply a rule within a content
>>> script to always navigate to the home page of what you need, when going to
>>> any other URL.
>>> That would solve most of the issues you have in that list.
>>>
>>> ☆PhistucK
>>>
>>>
>>>
>>> On Fri, Sep 25, 2009 at 15:30, Mohamed Mansour  wrote:
>>>
 I tried ChromeFrame it is very good, but it doesn't work if the Kiosk
 Mode flag is set. If the Kiosk mode is set ( iexplorer.exe -k
 http://www.google.com ) it renders it as IE Renderer. It renders it
 fine in a Chrome Frame if its not in Kiosk mode. That must be a bug :)
 For IE, kiosk mode has a context menu, but people usually apply the
 registry tweak to remove context menu from IE if they need to.

 For Chromium, it would be nice if stuff like this would be an extension,
 an extension should allow us to show/hide various parts of the UI. In the
 meantime, I quickly compiled a custom Chromium so that my CEO and VP could
 see the benefits of using Chrome instead of IE on some of our web products.

 Stuff that would be cool and would be very lightweight to include for
 kiosk mode would be:
 - No Status Bar- Full Screen (with no exit, only alt+f4 should work)
 - No Context Menus (should be an option)
 - Disable downloading of files.
 - No tabs
 - No opening files
 - many more

 I would rather that be an extension (but there are currently no way to
 actually block users to remove extensions, maybe blocking users entering a
 url would suffice) but not possible currently.

  -Mohamed



 On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi  wrote:

>
>
> On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher wrote:
>
>> Chrome Frame is a good option, but you'd still need a way to turn off
>> some features.  For example, a kiosk probably doesn't want to have a 
>> context
>> menu.
>
>
> Chrome Frame can/will offer control over the context menu. This is
> exactly the kind of customization Chrome Frame can offer. Too bad we don't
> have Linux, Mac versions yet, but we are open source now so patches 
> welcome
> :)
>
>
>> -Darin
>>
>>
>> On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi wrote:
>>
>>> I think you should really consider embedding chrome frame ActiveX in
>>> your own simple shell. That will not only enable the application to be
>>> started with desired real estate and get rid of status bubble but allow 
>>> you
>>> to customize it further if needed.
>>>
>>> On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher 
>>> wrote:
>>>

 On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour >>> > wrote:

> At work today, I talked to the CEO of my company to ship Chrome
> browser with all our Kiosk's and recommended Chrome to be our default
> browser for our web products. I bench marked our current web 
> applications
> with Chrome (ToT) vs IE 7, and our applications run at average 10 
> times
> faster. (For windows, Mac speed differed)
> There are some stuff that he didn't like:
>
>1. Status Bubble: for a cashiering application, it keeps
>popping up every second since buttons are all over the place. It 
> was
>distracting him from the main product.
>2. Full screen mode "always" => Kiosk Mode. He wants the web
>app to stay full screen, in IE, there is kiosk mode command line 
> switch. In
>FF there is a plugin.
>3. JavaScript errors kept appearing intermittently (on the
>Mac), would work on initial deploy but require a "Clear browsing 
> data" on
>subsequent runs. Works great on windows (chrome). I guess we would 
> be using
>linux/windows for kiosk anyhow

[chromium-dev] Re: Question about UI and "classic views"

[Thomas Van Lenten]

The other part of this might just be messaging.
It's not uncommon for websites to have a link to let users try out the new
experience before it launches.  And once it does launch, they always seem to
include a "Check out our new look and cool new features..." blurb.  So it's
sudden switch, but messaged/introduced.

At times, we seem to forget the impact of our silent updates.  They are
great for bug/security fixes, but when we do roll out something like NNTP,
it can lead to a 'WTF' moment.  For future changes like this, it might make
sense to put in messaging for the upgrade so the users get lead through the
transition instead of their routine suddenly changing on them.

TVL


On Fri, Sep 25, 2009 at 10:07 AM, Amanda Walker  wrote:

> On Thu, Sep 24, 2009 at 3:11 AM, Darin Fisher  wrote:
>
>> Do websites provide users with previous versions after overhauling their
>> UX?  Some do (gmail seems to), but most do not.  You just get to surf the
>> latest.  Hopefully, the website changes for the better.  That's our burden
>> to bear.
>
>
> And other browsers are just a double-click away :-).  One difference
> between the NTP and a random website is that users think of the NTP as their
> content (see for example the wording in the complaint from Mike's sister at
> the start of this thread).  Web sites that show user-generated (or in this
> case, user-arranged) content tend to get more complaints about large visual
> changes than more passive or static sites (example: see all of the uproar
> whenever Facebook changes their UI).
>
> Personally, I like the latest version of the NTP, but I would be wary of
> lumping it in with websites in general when we're trying to understand user
> expectations.
>
> --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: Question about UI and "classic views"

[Amanda Walker]

On Thu, Sep 24, 2009 at 3:11 AM, Darin Fisher  wrote:

> Do websites provide users with previous versions after overhauling their
> UX?  Some do (gmail seems to), but most do not.  You just get to surf the
> latest.  Hopefully, the website changes for the better.  That's our burden
> to bear.


And other browsers are just a double-click away :-).  One difference between
the NTP and a random website is that users think of the NTP as their content
(see for example the wording in the complaint from Mike's sister at the
start of this thread).  Web sites that show user-generated (or in this case,
user-arranged) content tend to get more complaints about large visual
changes than more passive or static sites (example: see all of the uproar
whenever Facebook changes their UI).

Personally, I like the latest version of the NTP, but I would be wary of
lumping it in with websites in general when we're trying to understand user
expectations.

--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: Skipping reference_build ?

[Marc-Antoine Ruel]

It's too late for git but not for svn and tarballs. Please move them to DEPS.

M-A

On Thu, Sep 24, 2009 at 6:26 PM, Evan Martin  wrote:
>
> We have already scolded Alex about this, but it's too late now.
>
> Repeat PSA: plz to not be dumping large Windows binaries into the
> tree.  We have DEPS for a reason.
>
> On Thu, Sep 24, 2009 at 3:20 PM, Michael  wrote:
>>
>> The src/chrome_frame/tools/test/reference_build directory takes ages
>> to svn up, is there a way to skip it? I don't think I really need all
>> those .dll and .exe files on Linux anyway...
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
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 time doubled since May - what gives?

[Marc-Antoine Ruel]

Oh and a lot of warnings appeared recently. It is surprising how much
warnings slow down the build, probably due to stdout serialization.

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

M-A

On Fri, Sep 25, 2009 at 9:18 AM, Marc-Antoine Ruel  wrote:
> http://code.google.com/p/chromium/issues/detail?id=21266
>
> This is a real problem, I just haven't looked into this one in
> particular. Sometimes I just feel like renaming the dll...
>
> M-A
>
> On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour  wrote:
>> Hey Ben, same here ... I see this additional message today (havn't seen it
>> before)
>> 59>LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or
>> not built by the last incremental link; performing full link
>>
>> Changing one file used to take me 5 minutes to build. But now it takes me
>> ~10-15 minutes.
>> -Mohamed
>>
>>
>> On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) 
>> wrote:
>>>
>>> I just ran a build here at home on my i7 workstation. It took 14
>>> minutes. This is the same system that would build in 7 minutes when I
>>> set it up in May.
>>>
>>> What gives? We need to figure this out ASAP.
>>>
>>> -Ben
>>>
>>>
>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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 time doubled since May - what gives?

[Marc-Antoine Ruel]

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

This is a real problem, I just haven't looked into this one in
particular. Sometimes I just feel like renaming the dll...

M-A

On Thu, Sep 24, 2009 at 10:29 PM, Mohamed Mansour  wrote:
> Hey Ben, same here ... I see this additional message today (havn't seen it
> before)
> 59>LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or
> not built by the last incremental link; performing full link
>
> Changing one file used to take me 5 minutes to build. But now it takes me
> ~10-15 minutes.
> -Mohamed
>
>
> On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) 
> wrote:
>>
>> I just ran a build here at home on my i7 workstation. It took 14
>> minutes. This is the same system that would build in 7 minutes when I
>> set it up in May.
>>
>> What gives? We need to figure this out ASAP.
>>
>> -Ben
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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 time doubled since May - what gives?

[PhistucK]

Perhaps the sync library?That was a large thing that was added recently...

☆PhistucK


On Fri, Sep 25, 2009 at 05:35, Lei Zhang  wrote:

>
> This is very recent. The Windows try server build times have gone way
> up this week. I thought it was just because of Incredibuild
> misbehaving on the try servers, but it looks like you're experiencing
> similar problems without IB.
>
> I think this is only affects Windows - the Mac and Linux trybot
> compile times haven't increased significantly.
>
> On Thu, Sep 24, 2009 at 7:06 PM, Ben Goodger (Google) 
> wrote:
> >
> > I just ran a build here at home on my i7 workstation. It took 14
> > minutes. This is the same system that would build in 7 minutes when I
> > set it up in May.
> >
> > What gives? We need to figure this out ASAP.
> >
> > -Ben
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: Kiosk Mode for Chrome

[PhistucK]

What are the major issues?Full screen with no escape hatch and no status
bubble?
Chrome developers already said the are willing to take care of those\accept
patches for those.
The rest are taken care of with disabling keyboard shortcuts, or am I wrong?

☆PhistucK


On Fri, Sep 25, 2009 at 15:44, Mohamed Mansour  wrote:

> The minor issues, yes, the major issues, no.
>  -Mohamed
>
>
>
> On Fri, Sep 25, 2009 at 8:40 AM, PhistucK  wrote:
>
>> You can create a content script that will disable the shortcut keys of the
>> browser and the right clicks, on all of the pages.About browsing to other
>> pages (and so, downloading), you can apply a rule within a content script to
>> always navigate to the home page of what you need, when going to any other
>> URL.
>> That would solve most of the issues you have in that list.
>>
>> ☆PhistucK
>>
>>
>>
>> On Fri, Sep 25, 2009 at 15:30, Mohamed Mansour  wrote:
>>
>>> I tried ChromeFrame it is very good, but it doesn't work if the Kiosk
>>> Mode flag is set. If the Kiosk mode is set ( iexplorer.exe -k
>>> http://www.google.com ) it renders it as IE Renderer. It renders it fine
>>> in a Chrome Frame if its not in Kiosk mode. That must be a bug :)
>>> For IE, kiosk mode has a context menu, but people usually apply the
>>> registry tweak to remove context menu from IE if they need to.
>>>
>>> For Chromium, it would be nice if stuff like this would be an extension,
>>> an extension should allow us to show/hide various parts of the UI. In the
>>> meantime, I quickly compiled a custom Chromium so that my CEO and VP could
>>> see the benefits of using Chrome instead of IE on some of our web products.
>>>
>>> Stuff that would be cool and would be very lightweight to include for
>>> kiosk mode would be:
>>> - No Status Bar- Full Screen (with no exit, only alt+f4 should work)
>>> - No Context Menus (should be an option)
>>> - Disable downloading of files.
>>> - No tabs
>>> - No opening files
>>> - many more
>>>
>>> I would rather that be an extension (but there are currently no way to
>>> actually block users to remove extensions, maybe blocking users entering a
>>> url would suffice) but not possible currently.
>>>
>>>  -Mohamed
>>>
>>>
>>>
>>> On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi  wrote:
>>>


 On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher wrote:

> Chrome Frame is a good option, but you'd still need a way to turn off
> some features.  For example, a kiosk probably doesn't want to have a 
> context
> menu.


 Chrome Frame can/will offer control over the context menu. This is
 exactly the kind of customization Chrome Frame can offer. Too bad we don't
 have Linux, Mac versions yet, but we are open source now so patches welcome
 :)


> -Darin
>
>
> On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi wrote:
>
>> I think you should really consider embedding chrome frame ActiveX in
>> your own simple shell. That will not only enable the application to be
>> started with desired real estate and get rid of status bubble but allow 
>> you
>> to customize it further if needed.
>>
>> On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher wrote:
>>
>>>
>>> On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour 
>>> wrote:
>>>
 At work today, I talked to the CEO of my company to ship Chrome
 browser with all our Kiosk's and recommended Chrome to be our default
 browser for our web products. I bench marked our current web 
 applications
 with Chrome (ToT) vs IE 7, and our applications run at average 10 times
 faster. (For windows, Mac speed differed)
 There are some stuff that he didn't like:

1. Status Bubble: for a cashiering application, it keeps popping
up every second since buttons are all over the place. It was 
 distracting him
from the main product.
2. Full screen mode "always" => Kiosk Mode. He wants the web app
to stay full screen, in IE, there is kiosk mode command line 
 switch. In FF
there is a plugin.
3. JavaScript errors kept appearing intermittently (on the Mac),
would work on initial deploy but require a "Clear browsing data" on
subsequent runs. Works great on windows (chrome). I guess we would 
 be using
linux/windows for kiosk anyhow.

 Will there be plans for us to introduce Kiosk Mode in Chrome? It
 seems the current audience is just targeted towards home users and 
 there is
 no way to use Google Chrome for other usages.

 Sure we could compile our own Chromium version, but many people
 (Chrome forums and elsewhere) would like to use Chrome commercially. 
 In the
 meantime, I am going to compile a version with no status bar, but I 
 believe
 it would be nice

[chromium-dev] Re: Kiosk Mode for Chrome

[Mohamed Mansour]

The minor issues, yes, the major issues, no.
 -Mohamed


On Fri, Sep 25, 2009 at 8:40 AM, PhistucK  wrote:

> You can create a content script that will disable the shortcut keys of the
> browser and the right clicks, on all of the pages.About browsing to other
> pages (and so, downloading), you can apply a rule within a content script to
> always navigate to the home page of what you need, when going to any other
> URL.
> That would solve most of the issues you have in that list.
>
> ☆PhistucK
>
>
>
> On Fri, Sep 25, 2009 at 15:30, Mohamed Mansour  wrote:
>
>> I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode
>> flag is set. If the Kiosk mode is set ( iexplorer.exe -k
>> http://www.google.com ) it renders it as IE Renderer. It renders it fine
>> in a Chrome Frame if its not in Kiosk mode. That must be a bug :)
>> For IE, kiosk mode has a context menu, but people usually apply the
>> registry tweak to remove context menu from IE if they need to.
>>
>> For Chromium, it would be nice if stuff like this would be an extension,
>> an extension should allow us to show/hide various parts of the UI. In the
>> meantime, I quickly compiled a custom Chromium so that my CEO and VP could
>> see the benefits of using Chrome instead of IE on some of our web products.
>>
>> Stuff that would be cool and would be very lightweight to include for
>> kiosk mode would be:
>> - No Status Bar- Full Screen (with no exit, only alt+f4 should work)
>> - No Context Menus (should be an option)
>> - Disable downloading of files.
>> - No tabs
>> - No opening files
>> - many more
>>
>> I would rather that be an extension (but there are currently no way to
>> actually block users to remove extensions, maybe blocking users entering a
>> url would suffice) but not possible currently.
>>
>>  -Mohamed
>>
>>
>>
>> On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi  wrote:
>>
>>>
>>>
>>> On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher wrote:
>>>
 Chrome Frame is a good option, but you'd still need a way to turn off
 some features.  For example, a kiosk probably doesn't want to have a 
 context
 menu.
>>>
>>>
>>> Chrome Frame can/will offer control over the context menu. This is
>>> exactly the kind of customization Chrome Frame can offer. Too bad we don't
>>> have Linux, Mac versions yet, but we are open source now so patches welcome
>>> :)
>>>
>>>
 -Darin


 On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi  wrote:

> I think you should really consider embedding chrome frame ActiveX in
> your own simple shell. That will not only enable the application to be
> started with desired real estate and get rid of status bubble but allow 
> you
> to customize it further if needed.
>
> On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher wrote:
>
>>
>> On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour 
>> wrote:
>>
>>> At work today, I talked to the CEO of my company to ship Chrome
>>> browser with all our Kiosk's and recommended Chrome to be our default
>>> browser for our web products. I bench marked our current web 
>>> applications
>>> with Chrome (ToT) vs IE 7, and our applications run at average 10 times
>>> faster. (For windows, Mac speed differed)
>>> There are some stuff that he didn't like:
>>>
>>>1. Status Bubble: for a cashiering application, it keeps popping
>>>up every second since buttons are all over the place. It was 
>>> distracting him
>>>from the main product.
>>>2. Full screen mode "always" => Kiosk Mode. He wants the web app
>>>to stay full screen, in IE, there is kiosk mode command line switch. 
>>> In FF
>>>there is a plugin.
>>>3. JavaScript errors kept appearing intermittently (on the Mac),
>>>would work on initial deploy but require a "Clear browsing data" on
>>>subsequent runs. Works great on windows (chrome). I guess we would 
>>> be using
>>>linux/windows for kiosk anyhow.
>>>
>>> Will there be plans for us to introduce Kiosk Mode in Chrome? It
>>> seems the current audience is just targeted towards home users and 
>>> there is
>>> no way to use Google Chrome for other usages.
>>>
>>> Sure we could compile our own Chromium version, but many people
>>> (Chrome forums and elsewhere) would like to use Chrome commercially. In 
>>> the
>>> meantime, I am going to compile a version with no status bar, but I 
>>> believe
>>> it would be nice to include it in future versions.
>>>
>>> Maybe we could allow extensions to control (hide/show) different
>>> areas in chrome.
>>>
>>>
>>
>> Maybe I'm in the minority, but it doesn't sound that unreasonable to
>> support command line options for disabling the status bubble and 
>> starting in
>> full screen mode.  We could lump these together into a --kiosk-mode 
>> command
>> line flag.  

[chromium-dev] Re: Kiosk Mode for Chrome

[PhistucK]

You can create a content script that will disable the shortcut keys of the
browser and the right clicks, on all of the pages.About browsing to other
pages (and so, downloading), you can apply a rule within a content script to
always navigate to the home page of what you need, when going to any other
URL.
That would solve most of the issues you have in that list.

☆PhistucK


On Fri, Sep 25, 2009 at 15:30, Mohamed Mansour  wrote:

> I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode
> flag is set. If the Kiosk mode is set ( iexplorer.exe -k
> http://www.google.com ) it renders it as IE Renderer. It renders it fine
> in a Chrome Frame if its not in Kiosk mode. That must be a bug :)
> For IE, kiosk mode has a context menu, but people usually apply the
> registry tweak to remove context menu from IE if they need to.
>
> For Chromium, it would be nice if stuff like this would be an extension, an
> extension should allow us to show/hide various parts of the UI. In the
> meantime, I quickly compiled a custom Chromium so that my CEO and VP could
> see the benefits of using Chrome instead of IE on some of our web products.
>
> Stuff that would be cool and would be very lightweight to include for kiosk
> mode would be:
> - No Status Bar- Full Screen (with no exit, only alt+f4 should work)
> - No Context Menus (should be an option)
> - Disable downloading of files.
> - No tabs
> - No opening files
> - many more
>
> I would rather that be an extension (but there are currently no way to
> actually block users to remove extensions, maybe blocking users entering a
> url would suffice) but not possible currently.
>
>  -Mohamed
>
>
>
> On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi  wrote:
>
>>
>>
>> On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher wrote:
>>
>>> Chrome Frame is a good option, but you'd still need a way to turn off
>>> some features.  For example, a kiosk probably doesn't want to have a context
>>> menu.
>>
>>
>> Chrome Frame can/will offer control over the context menu. This is exactly
>> the kind of customization Chrome Frame can offer. Too bad we don't have
>> Linux, Mac versions yet, but we are open source now so patches welcome :)
>>
>>
>>> -Darin
>>>
>>>
>>> On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi  wrote:
>>>
 I think you should really consider embedding chrome frame ActiveX in
 your own simple shell. That will not only enable the application to be
 started with desired real estate and get rid of status bubble but allow you
 to customize it further if needed.

 On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher wrote:

>
> On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour 
> wrote:
>
>> At work today, I talked to the CEO of my company to ship Chrome
>> browser with all our Kiosk's and recommended Chrome to be our default
>> browser for our web products. I bench marked our current web applications
>> with Chrome (ToT) vs IE 7, and our applications run at average 10 times
>> faster. (For windows, Mac speed differed)
>> There are some stuff that he didn't like:
>>
>>1. Status Bubble: for a cashiering application, it keeps popping
>>up every second since buttons are all over the place. It was 
>> distracting him
>>from the main product.
>>2. Full screen mode "always" => Kiosk Mode. He wants the web app
>>to stay full screen, in IE, there is kiosk mode command line switch. 
>> In FF
>>there is a plugin.
>>3. JavaScript errors kept appearing intermittently (on the Mac),
>>would work on initial deploy but require a "Clear browsing data" on
>>subsequent runs. Works great on windows (chrome). I guess we would be 
>> using
>>linux/windows for kiosk anyhow.
>>
>> Will there be plans for us to introduce Kiosk Mode in Chrome? It seems
>> the current audience is just targeted towards home users and there is no 
>> way
>> to use Google Chrome for other usages.
>>
>> Sure we could compile our own Chromium version, but many people
>> (Chrome forums and elsewhere) would like to use Chrome commercially. In 
>> the
>> meantime, I am going to compile a version with no status bar, but I 
>> believe
>> it would be nice to include it in future versions.
>>
>> Maybe we could allow extensions to control (hide/show) different areas
>> in chrome.
>>
>>
>
> Maybe I'm in the minority, but it doesn't sound that unreasonable to
> support command line options for disabling the status bubble and starting 
> in
> full screen mode.  We could lump these together into a --kiosk-mode 
> command
> line flag.  This seems like something that could be done in a fairly
> lightweight manner.
>
> Maybe others object?
>
> -Darin
>
>
>

>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list:

[chromium-dev] Re: Kiosk Mode for Chrome

[Mohamed Mansour]

I tried ChromeFrame it is very good, but it doesn't work if the Kiosk Mode
flag is set. If the Kiosk mode is set ( iexplorer.exe -k
http://www.google.com ) it renders it as IE Renderer. It renders it fine in
a Chrome Frame if its not in Kiosk mode. That must be a bug :)
For IE, kiosk mode has a context menu, but people usually apply the registry
tweak to remove context menu from IE if they need to.

For Chromium, it would be nice if stuff like this would be an extension, an
extension should allow us to show/hide various parts of the UI. In the
meantime, I quickly compiled a custom Chromium so that my CEO and VP could
see the benefits of using Chrome instead of IE on some of our web products.

Stuff that would be cool and would be very lightweight to include for kiosk
mode would be:
- No Status Bar- Full Screen (with no exit, only alt+f4 should work)
- No Context Menus (should be an option)
- Disable downloading of files.
- No tabs
- No opening files
- many more

I would rather that be an extension (but there are currently no way to
actually block users to remove extensions, maybe blocking users entering a
url would suffice) but not possible currently.

 -Mohamed


On Fri, Sep 25, 2009 at 1:52 AM, Amit Joshi  wrote:

>
>
> On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher  wrote:
>
>> Chrome Frame is a good option, but you'd still need a way to turn off some
>> features.  For example, a kiosk probably doesn't want to have a context
>> menu.
>
>
> Chrome Frame can/will offer control over the context menu. This is exactly
> the kind of customization Chrome Frame can offer. Too bad we don't have
> Linux, Mac versions yet, but we are open source now so patches welcome :)
>
>
>> -Darin
>>
>>
>> On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi  wrote:
>>
>>> I think you should really consider embedding chrome frame ActiveX in your
>>> own simple shell. That will not only enable the application to be started
>>> with desired real estate and get rid of status bubble but allow you to
>>> customize it further if needed.
>>>
>>> On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher wrote:
>>>

 On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour wrote:

> At work today, I talked to the CEO of my company to ship Chrome browser
> with all our Kiosk's and recommended Chrome to be our default browser for
> our web products. I bench marked our current web applications with Chrome
> (ToT) vs IE 7, and our applications run at average 10 times faster. (For
> windows, Mac speed differed)
> There are some stuff that he didn't like:
>
>1. Status Bubble: for a cashiering application, it keeps popping up
>every second since buttons are all over the place. It was distracting 
> him
>from the main product.
>2. Full screen mode "always" => Kiosk Mode. He wants the web app to
>stay full screen, in IE, there is kiosk mode command line switch. In FF
>there is a plugin.
>3. JavaScript errors kept appearing intermittently (on the Mac),
>would work on initial deploy but require a "Clear browsing data" on
>subsequent runs. Works great on windows (chrome). I guess we would be 
> using
>linux/windows for kiosk anyhow.
>
> Will there be plans for us to introduce Kiosk Mode in Chrome? It seems
> the current audience is just targeted towards home users and there is no 
> way
> to use Google Chrome for other usages.
>
> Sure we could compile our own Chromium version, but many people (Chrome
> forums and elsewhere) would like to use Chrome commercially. In the
> meantime, I am going to compile a version with no status bar, but I 
> believe
> it would be nice to include it in future versions.
>
> Maybe we could allow extensions to control (hide/show) different areas
> in chrome.
>
>

 Maybe I'm in the minority, but it doesn't sound that unreasonable to
 support command line options for disabling the status bubble and starting 
 in
 full screen mode.  We could lump these together into a --kiosk-mode command
 line flag.  This seems like something that could be done in a fairly
 lightweight manner.

 Maybe others object?

 -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: flaky resource failures

[Thomas Van Lenten]

On Thu, Sep 24, 2009 at 6:24 PM, Paweł Hajdan Jr.
wrote:

> On Thu, Sep 24, 2009 at 12:24, Thomas Van Lenten wrote:
>
>> Brad landed support for depending on all the python files that go into
>> grit, so that part would have worked.  The not always rebuilding for .h
>> files is the problem.
>>
>
> Does it mean we're missing some deps in the gyp files?
>

Shouldn't.  The IDEs should be figuring out what .h files are included by
each .cc/.m/.mm/.etc and rebuild as needed.

TVL

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