[chromium-dev] Re: Fwd: [chromium-dev] Re: OS X IPC Design doc

[John Abd-El-Malek]

Not to beat a dead horse, but looking at these tables, it seems that
the decision to go one way or another can be made simply by looking at
the 3 bottom rows.  However, I'm pretty sure you won't find any
existing messages that go over a few KBs.  For any large data
transfer, we use shared memory buffers.

I'm not trying to argue for one system or another, but I think things
like sending 1MB or 7MB of data quickly, or up to 256MB, aren't
actually needed by the existing code.

On Wed, Nov 12, 2008 at 4:46 PM, Jeremy Moskovich <[EMAIL PROTECTED]> wrote:
> We ran some benchmarks of Mach ports vs FIFOs on OSX, you can find the
> results in the "Performance Considerations" section of the Design doc.
>
> Best regards,
> Jeremy
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Mysterious build errors today

[John Abd-El-Malek]

This happened to me over the last few days with building Webkit's
tree.  It was driving me nuts, until I also saw it with Chrome.  I
rebooted and then it magically worked.  My guess is that it was cygwin's fault.

On Wed, Nov 26, 2008 at 12:08 PM, Mike Belshe <[EMAIL PROTECTED]> wrote:
>
> Today my builds mysteriously started failing.
>
> When building DerivedSources I get
>
> /cygdrive/e/trunk/src/THIRD_~1/WebKit/WebCore/svg/SVGNumberList.idl:1:6
> warning: null character(s) ignored
>
> 
>
> followed by
>
> Can't call method "fileName" without a package or object reference at
> /cygdrive/e/trunk/src/webkit/port/bindings/scripts/IDLParser.pm line
> 133.
>
>
>
> I changed none of these files and didn't change my cygwin stuff.  It
> appears that something in the build system changed?
>
> Clues?
>
> Mike
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: MathML and math accessibility as a Chromium plugin

[John Abd-El-Malek]

On Fri, Dec 5, 2008 at 8:24 AM, Marc-Antoine Ruel <[EMAIL PROTECTED]> wrote:
>
> As an argument, you could say that isn't it funny activex controls can
> override the specified viewport size and even resize itself whenever
> it wants while a NPAPI has no control on its viewport?

You can actually do that with NPAPI (I just verified).  Call
NPN_GetValue for NPNVPluginElementNPObject, then  NPN_GetProperty on
the result for "style".  You can then NPN_SetProperty on that result
for "width" and "900px" for example (let me know if you want some
sample code).

Paul, can this help in making MathML be implementable using NPAPI?

The other blockers you mentioned were getting the font/size of
surrounding text and accessibility.  The latter can be done on your
own if you use a windowed plugin, since Windows will just send you the
relevant WM messages for accessibility.

For getting the font/size, you can walk the DOM in NPAPI just like how
you do it in ActiveX.  i.e. using NPN_GetValue for NPNVWindowNPObject.

>
> M-A
>
> On Fri, Dec 5, 2008 at 10:52 AM, PaulTopping <[EMAIL PROTECTED]> wrote:
>>
>> I did propose that to the WebKit developer list a few years back but I
>> suppose it is time again. Unless things have changed, they seem dead
>> set against anything that is not open source.
>>
>> Paul
>>
>> On Dec 4, 11:06 pm, Darin Fisher <[EMAIL PROTECTED]> wrote:
>>> An extension like that would have to involve hooks into WebKit's rendering
>>> pipeline (obviously).  That means, that WebKit would first need to support
>>> those hooks before we could surface support for loading a binary to
>>> implement those hooks.  In other words, we have no intention or desire to
>>> fork WebKit (beyond using V8 instead of JSC).  In fact, we are aggressively
>>> working toward being able to use WebKit tip-of-tree source directly from
>>> svn.webkit.org without any modifications.  This means that you should
>>> probably go back and propose / seek changes to WebKit if you wish to see
>>> these kinds of extension APIs available to Chrome extensions in the future.
>>>  I suggested NPAPI because it may be easier / more acceptable by the WebKit
>>> developers to add to NPAPI to accomplish what you'd need.
>>> -Darin
>>>
>>>
>>>
>>> On Tue, Dec 2, 2008 at 12:08 PM, PaulTopping <[EMAIL PROTECTED]> wrote:
>>>
>>> > Those are interesting ideas. I was assuming you meant using NPAPI in
>>> > the traditional way. Your suggestions bear some thought.
>>>
>>> > To answer your questions about MathPlayer in IE, it is a binary
>>> > rendering behavior written in C++. It is not an ActiveX control in the
>>> > sense of a control that might be used in a form or in Visual Basic. It
>>> > does use and implement COM interfaces as does pretty much everything
>>> > that works with IE.
>>>
>>> > Rendering proceeds as follows. IE asks MathPlayer how much space it
>>> > needs on the page. To answer that question, MP has to traverse the
>>> > MathML DOM nodes and ask IE about the ambient font, font size, and
>>> > column width. Later, IE asks MP to render itself in a device context
>>> > passed to it. There is also code to handle mouse clicks and display a
>>> > context menu but this is all standard stuff.
>>>
>>> > On Dec 2, 11:46 am, Aaron Boodman <[EMAIL PROTECTED]> wrote:
>>> > > Resending, as I sent the first time from the wrong address.
>>>
>>> > > > On Tue, Dec 2, 2008 at 8:06 AM, PaulTopping <[EMAIL PROTECTED]> wrote:
>>> > > >> This is all very old territory. As far as I know, NPAPI requires that
>>> > > >> the amount of space the equation takes up on a page be known in
>>> > > >> advance, rather than be calculated at run-time to be dependent on the
>>> > > >> MathML content. There is no support for baseline alignment of the
>>> > > >> equation with the surrounding text. The rendering can't adapt to the
>>> > > >> font and point size of the surrounding text, an absoluter requirement
>>> > > >> for math. There is no connection to accessibility. Authors are not
>>> > > >> interested in writing separate MathML files. With a typical technical
>>> > > >> paper containing hundreds of equations, it very quickly becomes a
>>> > > >> nightmare.
>>>
>>> > > > That isn't how I meant to suggest using NPAPI. And just so you know,
>>> > > > I'd be happy to have people building these kind of extensions on top
>>> > > > of Chromium's extension system; I'm not trying to shoo you away. I'm
>>> > > > just curious to know where NPAPI falls short because it seems like a
>>> > > > good way to implement something like this.
>>>
>>> > > > How I envisioned you might use NPAPI is to have a single script,
>>> > > > similar to gears_init.js [1] that you ask authors to embed on their
>>> > > > pages. In browsers that natively support MathML, the script does
>>> > > > nothing. Otherwise, if it detects your plugin is installed, it creates
>>> > > > and embeds it. The script then interacts with the plugin, eventually
>>> > > > modifying the DOM of the page. The NPAPI plugin could gene

[chromium-dev] Rietveld improvements for large changelists

[John Abd-El-Malek]

(It's been suggested that I send this out to a large audience, so here you go)

Most of the Rietveld problems that I see in the logs or that people
complain about has been with regards to either very large changelists
(i.e. > 100 files) or with many patchsets of large changelists (i.e.
10 patchsets of 20 files each).  I've recently been pushing fixes to
alleviate these problems, so Rietveld should now be able to work with
these kinds of changelists.  If you've been holding back using
Rietveld for these reviews, or manually splitting them up into
multiple changelists, this shouldn't be necessary anymore.

Note that changelists with > 500 files still won't work.  Those are
pretty rare and it would take major changes to how Rietveld works in
order to make them work, so I don't think it's worth it at this point.

As usual, let me know if you see any problems.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Rietveld improvements for large changelists

[John Abd-El-Malek]

On Thu, Dec 11, 2008 at 12:07 AM, e. roman <[EMAIL PROTECTED]> wrote:
>
> Glad to hear this.
> However I just tried building some webkit-merge changelists and
> rietveld continues to have problems.
> (upload would succeed, but when trying to load the resulting page you
> get a 500; 170 files total).

I just saw this in the error logs.  One of the Rietveld reviewers had
pointed out another place where we can reduce the lookups by O(n), and
I just pushed that.  With that, I can see that issue (11377) fine.
Can you try uploading again?  It might be best to start from a new
issue (i.e. gcl delete and then create another changelist).

>
> I ended up chunking into gcl changes of 40 each, but this is a pain to manage.
> Hopefully there is more improvement that can be made here...
>
> On Wed, Dec 10, 2008 at 4:03 PM, Erik Kay <[EMAIL PROTECTED]> wrote:
>>
>> Awesome John.  Thanks!
>>
>>
>> On Wed, Dec 10, 2008 at 4:00 PM, John Abd-El-Malek <[EMAIL PROTECTED]> wrote:
>>>
>>> (It's been suggested that I send this out to a large audience, so here you 
>>> go)
>>>
>>> Most of the Rietveld problems that I see in the logs or that people
>>> complain about has been with regards to either very large changelists
>>> (i.e. > 100 files) or with many patchsets of large changelists (i.e.
>>> 10 patchsets of 20 files each).  I've recently been pushing fixes to
>>> alleviate these problems, so Rietveld should now be able to work with
>>> these kinds of changelists.  If you've been holding back using
>>> Rietveld for these reviews, or manually splitting them up into
>>> multiple changelists, this shouldn't be necessary anymore.
>>>
>>> Note that changelists with > 500 files still won't work.  Those are
>>> pretty rare and it would take major changes to how Rietveld works in
>>> order to make them work, so I don't think it's worth it at this point.
>>>
>>> As usual, let me know if you see any problems.
>>>
>>> >
>>>
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: Rietveld improvements for large changelists

[John Abd-El-Malek]

On Thu, Dec 11, 2008 at 1:03 AM, John Abd-El-Malek <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 11, 2008 at 12:07 AM, e. roman <[EMAIL PROTECTED]> wrote:
>>
>> Glad to hear this.
>> However I just tried building some webkit-merge changelists and
>> rietveld continues to have problems.
>> (upload would succeed, but when trying to load the resulting page you
>> get a 500; 170 files total).
>
> I just saw this in the error logs.  One of the Rietveld reviewers had
> pointed out another place where we can reduce the lookups by O(n), and
> I just pushed that.  With that, I can see that issue (11377) fine.

oops, I meant 13377

> Can you try uploading again?  It might be best to start from a new
> issue (i.e. gcl delete and then create another changelist).
>
>>
>> I ended up chunking into gcl changes of 40 each, but this is a pain to 
>> manage.
>> Hopefully there is more improvement that can be made here...
>>
>> On Wed, Dec 10, 2008 at 4:03 PM, Erik Kay <[EMAIL PROTECTED]> wrote:
>>>
>>> Awesome John.  Thanks!
>>>
>>>
>>> On Wed, Dec 10, 2008 at 4:00 PM, John Abd-El-Malek <[EMAIL PROTECTED]> 
>>> wrote:
>>>>
>>>> (It's been suggested that I send this out to a large audience, so here you 
>>>> go)
>>>>
>>>> Most of the Rietveld problems that I see in the logs or that people
>>>> complain about has been with regards to either very large changelists
>>>> (i.e. > 100 files) or with many patchsets of large changelists (i.e.
>>>> 10 patchsets of 20 files each).  I've recently been pushing fixes to
>>>> alleviate these problems, so Rietveld should now be able to work with
>>>> these kinds of changelists.  If you've been holding back using
>>>> Rietveld for these reviews, or manually splitting them up into
>>>> multiple changelists, this shouldn't be necessary anymore.
>>>>
>>>> Note that changelists with > 500 files still won't work.  Those are
>>>> pretty rare and it would take major changes to how Rietveld works in
>>>> order to make them work, so I don't think it's worth it at this point.
>>>>
>>>> As usual, let me know if you see any problems.
>>>>
>>>> >
>>>>
>>>
>>> >
>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: code style verification/formatting tool

[John Abd-El-Malek]

Just a heads-up that I've integrated the script into our Rietveld
instance.  If you use gcl, it will ping the server at a special url
after a patchset upload so that it can lint the files in the
background.  When you visit the issue page, you'll see  a "x errors"
link under the Lint column which takes you to the lint output. If the
file hasn't been linted yet, you'll see "? errors", in which case
clicking the link will show the errors and save it for future
refreshes of the issue page.

On Fri, Dec 5, 2008 at 5:34 AM, Marc-Antoine Ruel  wrote:
>
> I did an internal search and the current state is:
>
> - "Folks have been looking at open sourcing cpplint"
> - In its current incarnation, there is a lot of google-specific checks
> that needs to be factored out simply because they don't apply to
> external and open source projects.
> - Nobody actually took over to do the work.
>
> So I wouldn't expect anything in the near term.
>
> M-A
>
> On Thu, Dec 4, 2008 at 10:24 PM, Marshall Greenblatt
>  wrote:
>> Ok, so, back to the original question.  When can those of us external to
>> google expect a code style tool? :-)
>>
>> On Thu, Dec 4, 2008 at 1:57 PM, Dean McNamee  wrote:
>>>
>>> It doesn't need to be a parser, it's just a linter.  You don't really
>>> need to understand anything about the program to give useful warnings
>>> about style.  Our biggest style violation is probably trailing
>>> whitespace, for example.
>>>
>>> On Thu, Dec 4, 2008 at 7:33 PM, Benjamin  wrote:
>>> >
>>> > You wrote a c++ parser in python? cl!  I can't wait to see the
>>> > source.
>>> >
>>> > -Benjamin Meyer
>>> >
>>> > On Thu, Dec 4, 2008 at 12:22 PM, Pam Greene  wrote:
>>> >>
>>> >> On Wed, Dec 3, 2008 at 8:30 PM, Benjamin  wrote:
>>> >>>
>>> >>> On Wed, Dec 3, 2008 at 3:45 PM, Marshall Greenblatt
>>> >>>  wrote:
>>>  Sorry to be a pest, but has there been any progress on this?
>>> 
>>>  Thanks,
>>>  Marshall
>>> 
>>>  On Thu, Sep 18, 2008 at 4:17 PM, Pam Greene  wrote:
>>> >
>>> > On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt
>>> >  wrote:
>>> > > Hi Mark/Pam,
>>> > >
>>> > > On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai 
>>> > > wrote:
>>> > >>
>>> > >> Great question.  We've been talking about open-sourcing something
>>> > >> for
>>> > >> this, but so far, we don't have anything yet.  We do have
>>> > >> something we
>>> > >> use internally, but someone needs to go through it and clean up a
>>> > >> few
>>> > >> things before releasing it so that it runs well in the wild.
>>> > >>  When it
>>> > >> does materialize, it'll show up on the style guide project
>>> > >> (http://google-styleguide.googlecode.com/).
>>> > >
>>> > > Do you guys have a timeline in mind of when such a tool might
>>> > > become
>>> > > available?  If there are potential code licensing/IP issues,
>>> > > perhaps it
>>> > > could be made available as a web-based service?  For instance,
>>> > > something
>>> > > like the w3c validator but returning the corrections in either
>>> > > human-readable format or a format conducive to automation.
>>> >
>>> > Everybody's generally in support of open-sourcing the tool, and I
>>> > don't anticipate any licensing conflicts; it's just a matter of
>>> > finding the time to go through it.  For what it's worth, setting it
>>> > up
>>> > as a web-based service wouldn't be any faster.  More than days, less
>>> > than months, would be my guess.
>>> >
>>> > - Pam
>>> >>>
>>> >>> A web tool would only delay releasing a real tool.  Just curious how
>>> >>> is it written?  Using llvm, rpp, or another parser?
>>> >>
>>> >> It's in Python.
>>> >>
>>> >> - Pam
>>> >>
>>> >>>
>>> >>> -Benjamin Meyer
>>> >>>
>>> >>> >
>>> >>>
>>> >>
>>> >> >
>>> >>
>>> >
>>> > >
>>> >
>>>
>>>
>>
>>
>> >
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: code style verification/formatting tool

[John Abd-El-Malek]

On Tue, Dec 16, 2008 at 8:26 PM, Mohamed Mansour
 wrote:
> Awesome John, will save a lot of time for those reviewers. So I assume this
> is only for Google code style, webkit patches reviews will always display an
> error since they have a different style.

That's correct.  The script doesn't catch all style violations, but it
should cover enough to save reviewers tedious nitting.
>
> On Tue, Dec 16, 2008 at 11:20 PM, Adam Barth  wrote:
>>
>> Awesome!  Thanks John.  Trailing whitespace be gone!
>>
>> On Tue, Dec 16, 2008 at 8:16 PM, John Abd-El-Malek 
>> wrote:
>> >
>> > Just a heads-up that I've integrated the script into our Rietveld
>> > instance.  If you use gcl, it will ping the server at a special url
>> > after a patchset upload so that it can lint the files in the
>> > background.  When you visit the issue page, you'll see  a "x errors"
>> > link under the Lint column which takes you to the lint output. If the
>> > file hasn't been linted yet, you'll see "? errors", in which case
>> > clicking the link will show the errors and save it for future
>> > refreshes of the issue page.
>> >
>> > On Fri, Dec 5, 2008 at 5:34 AM, Marc-Antoine Ruel 
>> > wrote:
>> >>
>> >> I did an internal search and the current state is:
>> >>
>> >> - "Folks have been looking at open sourcing cpplint"
>> >> - In its current incarnation, there is a lot of google-specific checks
>> >> that needs to be factored out simply because they don't apply to
>> >> external and open source projects.
>> >> - Nobody actually took over to do the work.
>> >>
>> >> So I wouldn't expect anything in the near term.
>> >>
>> >> M-A
>> >>
>> >> On Thu, Dec 4, 2008 at 10:24 PM, Marshall Greenblatt
>> >>  wrote:
>> >>> Ok, so, back to the original question.  When can those of us external
>> >>> to
>> >>> google expect a code style tool? :-)
>> >>>
>> >>> On Thu, Dec 4, 2008 at 1:57 PM, Dean McNamee 
>> >>> wrote:
>> >>>>
>> >>>> It doesn't need to be a parser, it's just a linter.  You don't really
>> >>>> need to understand anything about the program to give useful warnings
>> >>>> about style.  Our biggest style violation is probably trailing
>> >>>> whitespace, for example.
>> >>>>
>> >>>> On Thu, Dec 4, 2008 at 7:33 PM, Benjamin  wrote:
>> >>>> >
>> >>>> > You wrote a c++ parser in python? cl!  I can't wait to see the
>> >>>> > source.
>> >>>> >
>> >>>> > -Benjamin Meyer
>> >>>> >
>> >>>> > On Thu, Dec 4, 2008 at 12:22 PM, Pam Greene 
>> >>>> > wrote:
>> >>>> >>
>> >>>> >> On Wed, Dec 3, 2008 at 8:30 PM, Benjamin  wrote:
>> >>>> >>>
>> >>>> >>> On Wed, Dec 3, 2008 at 3:45 PM, Marshall Greenblatt
>> >>>> >>>  wrote:
>> >>>> >>>> Sorry to be a pest, but has there been any progress on this?
>> >>>> >>>>
>> >>>> >>>> Thanks,
>> >>>> >>>> Marshall
>> >>>> >>>>
>> >>>> >>>> On Thu, Sep 18, 2008 at 4:17 PM, Pam Greene 
>> >>>> >>>> wrote:
>> >>>> >>>>>
>> >>>> >>>>> On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt
>> >>>> >>>>>  wrote:
>> >>>> >>>>> > Hi Mark/Pam,
>> >>>> >>>>> >
>> >>>> >>>>> > On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai
>> >>>> >>>>> > 
>> >>>> >>>>> > wrote:
>> >>>> >>>>> >>
>> >>>> >>>>> >> Great question.  We've been talking about open-sourcing
>> >>>> >>>>> >> something
>> >>>> >>>>> >> for
>> >>>> >>>>> >> this, but so far, we don't have anything yet.  We do have
>> >>>> >>&

[chromium-dev] Re: Tree flakyness

[John Abd-El-Malek]

On Mon, Dec 15, 2008 at 4:58 PM, Nicolas Sylvain  wrote:
> Hello,
>   As you all know, our tests are really flaky and are causing the tree to be
> red too often.
>   I took a quick look at the test logs and compiled the stats about all the
> flakyness.
>
> UI TESTS:
> In the last 7 days, 188 ui tests failed. 47 of them failed more than 30
> times.
> The biggest offenders:
> 122  BrowserTest.JavascriptAlertActivatesTab
>  85  UnloadTest.CrossSiteInfiniteUnloadAsync
>  82  ErrorPageTest.DNSError

I just committed a fix for this a few hours ago.  It might fix other
flakiness as well.

>  78  UnloadTest.CrossSiteInfiniteBeforeUnloadAsync
>  52  BrowserTest.TabNavigationAccelerators
>  35  ChromeMainTest.SecondLaunch
>  35  AutomationProxyTest.GetTabCount
>  34  PreferenceServiceTest.PreservedWindowPlacementIsLoaded
>  34  AutomationProxyTest.GetBrowserWindow
>  34  AutomationProxyTest.GetActiveTabIndex
> I used to file bugs for all the flaky tests and disable them, but this
> approach did not work.
>
> We currently have 25 ui-tests that are disabled, and I don't think anyone is
> trying to fix them
> UNIT TESTS:
> This one is getting more stable. Nothing to report, but we have 13 disabled
> tests.
> PERF TESTS:
> The page cycler tests are often crashing. The offending code is
> in WebCore::ConsoleMessage::operator== which is a new function added a month
> ago. It's a bit late to start reverting this code though (was part of a v8
> change), and hard to replicate on our dev machines (it never crashed in a
> debugger).
>
> If someone has time, it would be great if you could help debugging, mainly
> if you wrote any of these tests.
> Thanks
> Nicolas
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to 
chromium-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/chromium-dev?hl=en
-~--~~~~--~~--~--~---

[chromium-dev] Re: code style verification/formatting tool

[John Abd-El-Malek]

This will be possible once Elliot cleans up the lint script so that it
can be sent outside Google.

On Wed, Dec 17, 2008 at 10:36 AM, Mohamed Mansour
 wrote:
> Would be nice to make a gcl lint feature :)
> gcl lint [mychangelist] before we submit it to codereview
>
> On Wed, Dec 17, 2008 at 1:33 PM, Marc-Antoine Ruel 
> wrote:
>>
>> Yep, that's simple and neat
>>
>> On Wed, Dec 17, 2008 at 1:29 PM, Erik Kay  wrote:
>> > jam++
>> > Great stuff!  I like how this is integrated.  It feels very natural.
>> > Erik
>> >
>> > On Tue, Dec 16, 2008 at 8:16 PM, John Abd-El-Malek 
>> > wrote:
>> >>
>> >> Just a heads-up that I've integrated the script into our Rietveld
>> >> instance.  If you use gcl, it will ping the server at a special url
>> >> after a patchset upload so that it can lint the files in the
>> >> background.  When you visit the issue page, you'll see  a "x errors"
>> >> link under the Lint column which takes you to the lint output. If the
>> >> file hasn't been linted yet, you'll see "? errors", in which case
>> >> clicking the link will show the errors and save it for future
>> >> refreshes of the issue page.
>> >>
>> >> On Fri, Dec 5, 2008 at 5:34 AM, Marc-Antoine Ruel 
>> >> wrote:
>> >> >
>> >> > I did an internal search and the current state is:
>> >> >
>> >> > - "Folks have been looking at open sourcing cpplint"
>> >> > - In its current incarnation, there is a lot of google-specific
>> >> > checks
>> >> > that needs to be factored out simply because they don't apply to
>> >> > external and open source projects.
>> >> > - Nobody actually took over to do the work.
>> >> >
>> >> > So I wouldn't expect anything in the near term.
>> >> >
>> >> > M-A
>> >> >
>> >> > On Thu, Dec 4, 2008 at 10:24 PM, Marshall Greenblatt
>> >> >  wrote:
>> >> >> Ok, so, back to the original question.  When can those of us
>> >> >> external
>> >> >> to
>> >> >> google expect a code style tool? :-)
>> >> >>
>> >> >> On Thu, Dec 4, 2008 at 1:57 PM, Dean McNamee 
>> >> >> wrote:
>> >> >>>
>> >> >>> It doesn't need to be a parser, it's just a linter.  You don't
>> >> >>> really
>> >> >>> need to understand anything about the program to give useful
>> >> >>> warnings
>> >> >>> about style.  Our biggest style violation is probably trailing
>> >> >>> whitespace, for example.
>> >> >>>
>> >> >>> On Thu, Dec 4, 2008 at 7:33 PM, Benjamin  wrote:
>> >> >>> >
>> >> >>> > You wrote a c++ parser in python? cl!  I can't wait to see
>> >> >>> > the
>> >> >>> > source.
>> >> >>> >
>> >> >>> > -Benjamin Meyer
>> >> >>> >
>> >> >>> > On Thu, Dec 4, 2008 at 12:22 PM, Pam Greene 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> On Wed, Dec 3, 2008 at 8:30 PM, Benjamin 
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> On Wed, Dec 3, 2008 at 3:45 PM, Marshall Greenblatt
>> >> >>> >>>  wrote:
>> >> >>> >>>> Sorry to be a pest, but has there been any progress on this?
>> >> >>> >>>>
>> >> >>> >>>> Thanks,
>> >> >>> >>>> Marshall
>> >> >>> >>>>
>> >> >>> >>>> On Thu, Sep 18, 2008 at 4:17 PM, Pam Greene 
>> >> >>> >>>> wrote:
>> >> >>> >>>>>
>> >> >>> >>>>> On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt
>> >> >>> >>>>>  wrote:
>> >> >>> >>>>> > Hi Mark/Pam,
>> >> >>> >>>>> >
>> >> >>> >>>>> > On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentov

[chromium-dev] Re: cpplint.py open sourced!

[John Abd-El-Malek]

On Tue, Jan 13, 2009 at 2:25 PM, Elliot Glaysher (Chromium) <
e...@chromium.org> wrote:

>
> Background: For the last couple of months, there have been requests
> from external contributors for a style linting tool. I've just finish
> cleaning Google's cpplint.py up for public release.
>
> cpplint.py takes file names as input and returns file/line number
> pairs with error messages about style violations. By default it
> outputs in a format friendly to emacs compile-mode, but can output
> Visual Studio compatible errors with the "--output=vs7" option. See
> cpplint.py --help for more details. cpplint.py is not perfect as it is
> based on regular expressions--thus it won't catch everything and will
> have the occasional false positive.
>
> John is planning on integrating this directly with gcl, but if you
> want to run it right now, the python script is available at:


I didn't know this!  What I'm planning on doing is using this version in
Rietveld.  If anyone else wants to integrate it with gcl, that should be
pretty easy.


>
>  http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py
>
> For those who are interested, I've also released Google's indentation
> rules for emacs:
>
>  http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el
>
> -- Elliot
>
> >
>

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

[chromium-dev] Sending -m "patchset description" on gcl upload

[John Abd-El-Malek]

Just a heads up about a very small gcl change which allows a description to
be added on an upload.  This doesn't work on the first upload (since that
uses the description).  You might find this useful when uploading new
versions of a change, to let the reviewer know what changed.
gcl upload change_name -m "description of the patchset"

--~--~-~--~~~---~--~~
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: Thoughts on the default plugin

[John Abd-El-Malek]

It seems that the only reason this code is needed is to get the function
pointers for the internal plugin.  Perhaps the PluginVersionInfo &
InternalPluginInfo stuff could be taken out of the platform independent
code.  ReadWebPluginInfo can be modified to return both the WebPluginInfo &
the three function pointers (if it's an internal plugin).  What do you
think?

On Tue, Jan 20, 2009 at 9:33 AM, Avi Drissman  wrote:

> I'm looking at InternalPluginInfo in plugin_lib.h. Its first component is a
> PluginVersionInfo, which is basically the Win32 version of the NPAPI data.
> Right now my plugin info parsing code pulls info from either a plist (via
> CFBundle) or resources, and neither is easy to reuse to parse a set of
> strings. What format does Linux have? Could we reuse the code?
>
> Avi
>
> >
>

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

[chromium-dev] Re: Thoughts on the default plugin

[John Abd-El-Malek]

Where would this be used?

On Tue, Jan 20, 2009 at 11:24 AM, Marshall Greenblatt <
magreenbl...@gmail.com> wrote:

> On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt <
> magreenbl...@gmail.com> wrote:
>
>> It would also be nice if we had a public method for registering internal
>> plugins dynamically, instead of having to modify the g_internal_plugins
>> array in plugin_lib.cc.
>>
>> For instance (based on the current code):
>>
>> PluginLib::RegisterInternalPlugin(PluginVersionInfo version_info,
>> NP_GetEntryPointsFunc
>> np_getentrypoints,
>> NP_InitializeFunc
>> np_initialize,
>> NP_ShutdownFunc
>> np_shutdown);
>>
>> This would be functionally equivalent to adding an entry to the existing
>> g_internal_plugins array, but would be run-time accessible from elsewhere in
>> the code base.
>>
>> On Tue, Jan 20, 2009 at 1:48 PM, John Abd-El-Malek wrote:
>>
>>> It seems that the only reason this code is needed is to get the function
>>> pointers for the internal plugin.  Perhaps the PluginVersionInfo &
>>> InternalPluginInfo stuff could be taken out of the platform independent
>>> code.  ReadWebPluginInfo can be modified to return both the WebPluginInfo &
>>> the three function pointers (if it's an internal plugin).  What do you
>>> think?
>>>
>>>
>>> On Tue, Jan 20, 2009 at 9:33 AM, Avi Drissman  wrote:
>>>
>>>> I'm looking at InternalPluginInfo in plugin_lib.h. Its first component
>>>> is a PluginVersionInfo, which is basically the Win32 version of the NPAPI
>>>> data. Right now my plugin info parsing code pulls info from either a plist
>>>> (via CFBundle) or resources, and neither is easy to reuse to parse a set of
>>>> strings. What format does Linux have? Could we reuse the code?
>>>>
>>>> Avi
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
> >
>

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

[chromium-dev] Re: Thoughts on the default plugin

[John Abd-El-Malek]

Perhaps something like PluginList::AddExtraPluginPath can be added which
takes the parameters you mentioned.  This should be easy to do, I'd be happy
to review it if you send me a patch :)

On Tue, Jan 20, 2009 at 12:00 PM, Marshall Greenblatt <
magreenbl...@gmail.com> wrote:

> I agree, registering with a WebPluginInfo and function pointers would be
> the ideal solution :-).
>
>
> On Tue, Jan 20, 2009 at 2:57 PM, Avi Drissman  wrote:
>
>> In that case, registering with a WebPluginInfo/function pointers would be
>> better than keeping around PluginVersionInfo. Real data structures FTW.
>>
>> Avi
>>
>>
>> On Tue, Jan 20, 2009 at 2:51 PM, Marshall Greenblatt <
>> magreenbl...@gmail.com> wrote:
>>
>>> My immediate usage case is for the chromium embedded framework (CEF):
>>> http://code.google.com/p/chromiumembedded/
>>>
>>> CEF supports plugins that are an integrated part of the container
>>> application.  For instance, consider a medical viewing application where the
>>> complete user interface is an embedded browser window.  An internal plugin
>>> is embedded in the browser window for viewing medical scan images.  The
>>> plugin depends on the medical viewing application (cannot function
>>> independently), and so we compile both the viewing application and the
>>> plugin into a single executable.
>>>
>>> Currently, CEF must duplicate the entire webkit\glue\plugins directory in
>>> order to make the minor changes necessary to support this capability.  If we
>>> could dynamically register internal plugins via PluginLib then we could
>>> eliminate the code duplication.
>>>
>>> I imagine dynamically registering internal plugins (as part of an
>>> extension, for instance) might also be a useful capability once the chromium
>>> extension framework is in place.
>>>
>>>
>>>
>>> On Tue, Jan 20, 2009 at 2:29 PM, Avi Drissman  wrote:
>>>
>>>> I'm trying to figure out a way to get away from PluginVersionInfo as
>>>> it's very Win32-centric.
>>>>
>>>> BTW, what's the scenario that you have in mind that dynamic registration
>>>> would help with? If we're making changes here, we should take your usage
>>>> needs into account.
>>>>
>>>> Avi
>>>>
>>>>
>>>> On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt <
>>>> magreenbl...@gmail.com> wrote:
>>>>
>>>>> On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt <
>>>>> magreenbl...@gmail.com> wrote:
>>>>>
>>>>>> It would also be nice if we had a public method for registering
>>>>>> internal plugins dynamically, instead of having to modify the
>>>>>> g_internal_plugins array in plugin_lib.cc.
>>>>>>
>>>>>> For instance (based on the current code):
>>>>>>
>>>>>> PluginLib::RegisterInternalPlugin(PluginVersionInfo version_info,
>>>>>> NP_GetEntryPointsFunc
>>>>>> np_getentrypoints,
>>>>>> NP_InitializeFunc
>>>>>> np_initialize,
>>>>>> NP_ShutdownFunc
>>>>>> np_shutdown);
>>>>>>
>>>>>> This would be functionally equivalent to adding an entry to the
>>>>>> existing g_internal_plugins array, but would be run-time accessible from
>>>>>> elsewhere in the code base.
>>>>>>
>>>>>> On Tue, Jan 20, 2009 at 1:48 PM, John Abd-El-Malek 
>>>>>> wrote:
>>>>>>
>>>>>>> It seems that the only reason this code is needed is to get the
>>>>>>> function pointers for the internal plugin.  Perhaps the 
>>>>>>> PluginVersionInfo &
>>>>>>> InternalPluginInfo stuff could be taken out of the platform independent
>>>>>>> code.  ReadWebPluginInfo can be modified to return both the 
>>>>>>> WebPluginInfo &
>>>>>>> the three function pointers (if it's an internal plugin).  What do you
>>>>>>> think?
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 20, 2009 at 9:33 AM, Avi Drissman wrote:
>>>>>>>
>>>>>>>> I'm looking at InternalPluginInfo in plugin_lib.h. Its first
>>>>>>>> component is a PluginVersionInfo, which is basically the Win32 version 
>>>>>>>> of
>>>>>>>> the NPAPI data. Right now my plugin info parsing code pulls info from 
>>>>>>>> either
>>>>>>>> a plist (via CFBundle) or resources, and neither is easy to reuse to 
>>>>>>>> parse a
>>>>>>>> set of strings. What format does Linux have? Could we reuse the code?
>>>>>>>>
>>>>>>>> Avi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
> >
>

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

[chromium-dev] Re: Thoughts on the default plugin

[John Abd-El-Malek]

PluginList only needs WebPluginInfo structs, as its purpose is just to
figure out which plugin can handle a mimetype.  The trick we do is that we
denote internal plugins using "special" filenames.  For example, look at the
internal plugin (kDefaultPluginLibraryNameLook).

The function pointers are stored in the platform specific plugin lib file.
 In plugin_lib_win.cc, it's g_internal_plugins.  You'll have to convert this
to a std::vector, and then you can add a static method to PluginLib to add
items to it.


On Tue, Jan 20, 2009 at 1:07 PM, Marshall Greenblatt  wrote:

> PluginList maintains a vector of WebPluginInfo structs.  As-is, that won't
> let us store the function pointers.  Should we:
>
> 1. Add the function pointers as members of the WebPluginInfo struct in
> webplugin.h
>
> 2. Change PluginList::plugins_ to a vector of structs like the following
> that would only be used internal to PluginList:
>
> struct PluginListInfo {
>   WebPluginInfo plugin_info;
>   NP_GetEntryPointsFunc np_getentrypoints;
>   NP_InitializeFunc np_initialize;
>   NP_ShutdownFunc np_shutdown;
> };
>
> 3. Same as 2, but maintain these structures in a vector separate from
> PluginList::plugins_ and only use for the dynamically registered internal
> plugins.
>
>
> On Tue, Jan 20, 2009 at 3:27 PM, John Abd-El-Malek wrote:
>
>> Perhaps something like PluginList::AddExtraPluginPath can be added which
>> takes the parameters you mentioned.  This should be easy to do, I'd be happy
>> to review it if you send me a patch :)
>>
>>
>> On Tue, Jan 20, 2009 at 12:00 PM, Marshall Greenblatt <
>> magreenbl...@gmail.com> wrote:
>>
>>> I agree, registering with a WebPluginInfo and function pointers would be
>>> the ideal solution :-).
>>>
>>>
>>> On Tue, Jan 20, 2009 at 2:57 PM, Avi Drissman  wrote:
>>>
>>>> In that case, registering with a WebPluginInfo/function pointers would
>>>> be better than keeping around PluginVersionInfo. Real data structures FTW.
>>>>
>>>> Avi
>>>>
>>>>
>>>> On Tue, Jan 20, 2009 at 2:51 PM, Marshall Greenblatt <
>>>> magreenbl...@gmail.com> wrote:
>>>>
>>>>> My immediate usage case is for the chromium embedded framework (CEF):
>>>>> http://code.google.com/p/chromiumembedded/
>>>>>
>>>>> CEF supports plugins that are an integrated part of the container
>>>>> application.  For instance, consider a medical viewing application where 
>>>>> the
>>>>> complete user interface is an embedded browser window.  An internal plugin
>>>>> is embedded in the browser window for viewing medical scan images.  The
>>>>> plugin depends on the medical viewing application (cannot function
>>>>> independently), and so we compile both the viewing application and the
>>>>> plugin into a single executable.
>>>>>
>>>>> Currently, CEF must duplicate the entire webkit\glue\plugins directory
>>>>> in order to make the minor changes necessary to support this capability.  
>>>>> If
>>>>> we could dynamically register internal plugins via PluginLib then we could
>>>>> eliminate the code duplication.
>>>>>
>>>>> I imagine dynamically registering internal plugins (as part of an
>>>>> extension, for instance) might also be a useful capability once the 
>>>>> chromium
>>>>> extension framework is in place.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 20, 2009 at 2:29 PM, Avi Drissman wrote:
>>>>>
>>>>>> I'm trying to figure out a way to get away from PluginVersionInfo as
>>>>>> it's very Win32-centric.
>>>>>>
>>>>>> BTW, what's the scenario that you have in mind that dynamic
>>>>>> registration would help with? If we're making changes here, we should 
>>>>>> take
>>>>>> your usage needs into account.
>>>>>>
>>>>>> Avi
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt <
>>>>>> magreenbl...@gmail.com> wrote:
>>>>>>
>>>>>>> On Tue, Jan 20, 2009 at 2:24 PM, Marshall Greenblatt <
>>>>>>> magreenbl...@gmail.com> wrote:
>>>>>>>
>>>>>>>> It would also be nice if we 

[chromium-dev] Re: [linux] plugin info caching

[John Abd-El-Malek]

On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin  wrote:
>
> I'd been sending this sort of stuff to Dean and John but maybe other
> people will find it interesting.
>
> Plugin loading works in two phases:
> - at startup, we scan the plugin directories for metadata, like plugin
> names and which mime-types they apply to;
> - at runtime, when we're asked for a specific plugin by mime type, we
> open the appropriate library and have at it.
>
> On Windows and Mac, the startup step queries file metadata (version
> info on Windows, plists on Mac).
> On Linux, that step must dlopen() the plugin and poke a function in
> it.  This means if a plugin ends up getting used we open it twice,
> which is especially brutal because Flash can take multiple seconds to
> open for me (complicated story, Adobe is working on it).
>
> It appears that Mozilla (maybe for similar reasons) caches this info
> across browser runs and relies on the file mtime to see when its cache
> has expired, much to some users' dismay:
>  https://bugzilla.mozilla.org/show_bug.cgi?id=125469
> Or at least they did in 2002.  ;)
>
> For now (for test_shell) I think I'll just pay the double-load cost.

I think that's the way to go.  Also, in the future you'll really be
opening it in another process, so you'll have to open it twice
anyways...

> The alternative is leaving plugins open, which I think wastes memory
> and hurts load time.  At some point we'll have to look at performance
> and decide about the cache thing.

I don't think you'd ever want to do this, because of memory as you say.

>
> PS: Do we scan for plugins on a background thread in the normal
> browser startup?

yes

> If so, how do we prevent races between that scan and
> someone's home page requesting a plugin?

PluginService has a lock around PluginList
>
> >
>

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

[chromium-dev] Re: [linux] plugin info caching

[John Abd-El-Malek]

One of my goals with the out of process worker code is it to make it easier
to have many different types of child processes.  Perhaps it makes sense to
have the linux port do this stuff in a child process once that code is
ready.

On Tue, Jan 27, 2009 at 10:49 PM, Darin Fisher  wrote:

> Wow.  It sucks that we'll need to load plugins in the main browser process.
>  That gives plugins a nice opportunity to hose the browser.  Oh well :-(  If
> we really wanted to, I suppose we could have a plugin scanner process, but
> that seems unfortunately heavyweight.
> -Darin
>
>
>
> On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin  wrote:
>
>>
>> I'd been sending this sort of stuff to Dean and John but maybe other
>> people will find it interesting.
>>
>> Plugin loading works in two phases:
>> - at startup, we scan the plugin directories for metadata, like plugin
>> names and which mime-types they apply to;
>> - at runtime, when we're asked for a specific plugin by mime type, we
>> open the appropriate library and have at it.
>>
>> On Windows and Mac, the startup step queries file metadata (version
>> info on Windows, plists on Mac).
>> On Linux, that step must dlopen() the plugin and poke a function in
>> it.  This means if a plugin ends up getting used we open it twice,
>> which is especially brutal because Flash can take multiple seconds to
>> open for me (complicated story, Adobe is working on it).
>>
>> It appears that Mozilla (maybe for similar reasons) caches this info
>> across browser runs and relies on the file mtime to see when its cache
>> has expired, much to some users' dismay:
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=125469
>> Or at least they did in 2002.  ;)
>>
>> For now (for test_shell) I think I'll just pay the double-load cost.
>> The alternative is leaving plugins open, which I think wastes memory
>> and hurts load time.  At some point we'll have to look at performance
>> and decide about the cache thing.
>>
>> PS: Do we scan for plugins on a background thread in the normal
>> browser startup?  If so, how do we prevent races between that scan and
>> someone's home page requesting a plugin?
>>
>>
>>
>
> >
>

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

[chromium-dev] Don't include render_messages.h in a header

[John Abd-El-Malek]

I've gone through the code and removed all such occurrences. This
speeds up the build from 15 to 13 minutes (using /MP on quadcore with
SSD). It also means that editing that file only rebuilds 36 files
instead of 200.

There shouldn't be any reason to include that file from a header. The
reason this has happened is that people have ended up using structs
that define the parameters of an IPC message with many parameters as
member variables in classes. If this happens, then the struct should
just be moved to its own file outside of render_messages.h.

--~--~-~--~~~---~--~~
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: [extensions] Extension Process Model Draft

[John Abd-El-Malek]

Looks good, one comment: previously there's been some high level
comments about how workers can be used to give extensions a long lived
context.  If this is still the case, would an extension that used a
worker & UI end up having to use two processes?

On Wed, Feb 4, 2009 at 5:49 PM, Matt Perry  wrote:
> I wrote up a short design doc covering what our extension process model will
> look like.  Feedback welcome.
> http://dev.chromium.org/developers/design-documents/extensions/process-model
> >
>

--~--~-~--~~~---~--~~
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: Don't include render_messages.h in a header

[John Abd-El-Malek]

One idea I've been thinking about is timing how long a clean build
takes, and tracking that just as we do with other performance tests.
The goal would be to notice when someone introduces an unnecessary
dependency that slows the build.  Obviously if it's needed, that's ok.

Chromium-XP does a full build each time, I wonder how easy it would be
to plot its build times?

On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin  wrote:
> I fear we have a have a couple long threads of headers that touch
> everything.  At one point we had something like: v8 bindings -> stats
> table -> process_util -> process, which meant if you touched any of
> our process-management code we'd rebuild all of WebKit's SVG bindings.
>  :~(
>
> For an especially painful build, try touching npapi.h.  Apparently
> most of our project depends on that file.
>
> On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek  wrote:
>>
>> I've gone through the code and removed all such occurrences. This
>> speeds up the build from 15 to 13 minutes (using /MP on quadcore with
>> SSD). It also means that editing that file only rebuilds 36 files
>> instead of 200.
>>
>> There shouldn't be any reason to include that file from a header. The
>> reason this has happened is that people have ended up using structs
>> that define the parameters of an IPC message with many parameters as
>> member variables in classes. If this happens, then the struct should
>> just be moved to its own file outside of render_messages.h.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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 the renderer process on OS X

[John Abd-El-Malek]

On Thu, Feb 5, 2009 at 4:57 PM, Jeremy Moskovich  wrote:
> Just a quick note, since this may be generally useful:
>
> If you pass the --renderer-startup-dialog when running the browser (or the
> unit tests) then any spawned render process will print a message to stdout
> with it's pid and then call pause().
>
> XCode doesn't like debugging multiple processes, so what I've done up till
> now is launch from the command line with the above flag and then do a
> Run->Attach To Process->Process Id... in XCode to actually attach to the
> renderer process.  I can then hit continue and we're off...
>
> In general, Chrome's process structure propagates command line flags from
> parent to child, so any flags you pass to the browser on startup will be
> passed to child processes, this is also useful when debugging the renderer.

BrowserRenderProcessHost::switch_names determines which flags are
propagated (you might be aware of it, but want to make sure that
others are too).

>
> I'll post more detailed notes to the wiki timorrow...
>
> Best regards,
> Jeremy
>
> >
>

--~--~-~--~~~---~--~~
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: Don't include render_messages.h in a header

[John Abd-El-Malek]

On Fri, Feb 6, 2009 at 10:54 AM, Nicolas Sylvain wrote:

>
>
> On Thu, Feb 5, 2009 at 10:56 AM, John Abd-El-Malek wrote:
>
>>
>> One idea I've been thinking about is timing how long a clean build
>> takes, and tracking that just as we do with other performance tests.
>> The goal would be to notice when someone introduces an unnecessary
>> dependency that slows the build.  Obviously if it's needed, that's ok.
>>
>> Chromium-XP does a full build each time, I wonder how easy it would be
>> to plot its build times?
>
>
> I attached a graph of the build time of Chromium XP over the last 3000
> changelists.
>
> I manually removed all the really high values (10% higher than the previous
> and the next build), otherwise it was too noisy.
>
> It's still really noisy, but we can see an increase of about 1 minute and
> 40 seconds to the compile time between revision 7755 and 7774.
>
> It was not obvious to me what was the cause by looking at all the changes
> in this range. Maybe a webkit merge. Maybe the new dependency on browser.
>
> It's important to note that this machine is using incredibuild.
>

Interesting graph.  I think using the time from incredibuild will be noisy
due to how many other builds are going on at the same time.  What would be
more work, but more accurate, would be if we kick off a full build on the
other machines without incredibuild (or this one with IB disabled) every
night.


>
> Nicolas
>
>
>
>>
>> On Thu, Feb 5, 2009 at 10:48 AM, Evan Martin  wrote:
>> > I fear we have a have a couple long threads of headers that touch
>> > everything.  At one point we had something like: v8 bindings -> stats
>> > table -> process_util -> process, which meant if you touched any of
>> > our process-management code we'd rebuild all of WebKit's SVG bindings.
>> >  :~(
>> >
>> > For an especially painful build, try touching npapi.h.  Apparently
>> > most of our project depends on that file.
>> >
>> > On Thu, Feb 5, 2009 at 10:29 AM, John Abd-El-Malek 
>> wrote:
>> >>
>> >> I've gone through the code and removed all such occurrences. This
>> >> speeds up the build from 15 to 13 minutes (using /MP on quadcore with
>> >> SSD). It also means that editing that file only rebuilds 36 files
>> >> instead of 200.
>> >>
>> >> There shouldn't be any reason to include that file from a header. The
>> >> reason this has happened is that people have ended up using structs
>> >> that define the parameters of an IPC message with many parameters as
>> >> member variables in classes. If this happens, then the struct should
>> >> just be moved to its own file outside of render_messages.h.
>> >>
>> >> >>
>> >>
>> >
>>
>> >>
>>
>

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

[chromium-dev] Where is the data for reliablity and purify tests stored?

[John Abd-El-Malek]

(CCing chrome-dev so that others who don't know can search for this later.
 Using Erik's & Huan's chromium emails so reply get sent to the list).

I submitted some refactoring and now I'm seeing the reliability and purify
tests are red, which I think is a false alarm due to callstacks changing.

For the reliability tests, this is the new regression.  I don't think my
code could have affected this, so my hunch is that this callstack didn't
match an existing list since RenderThread::OnMessageReceived is now
ChildThread::OnMessageReceived.  But I can't find out where the existing
crash callstacks are stored so I can verify this?

http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Reliability/builds/1155/steps/reliability%20tests/logs/stdio

REGRESSION: NEW crash stack traces found

chrome_23e!WebCore::FrameLoader::submitFormAgain+0x1e
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\frameloader.cpp
@ 511]
chrome_23e!WebCore::FrameLoader::executeScript+0x5d
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\frameloader.cpp
@ 788]
chrome_23e!WebCore::HTMLTokenizer::scriptExecution+0xc7
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
@ 608]
chrome_23e!WebCore::HTMLTokenizer::notifyFinished+0x204
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
@ 1986]
chrome_23e!WebCore::CachedScript::addClient+0x23
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedscript.cpp
@ 57]
chrome_23e!WebCore::HTMLTokenizer::scriptHandler+0x404
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
@ 494]
chrome_23e!WebCore::HTMLTokenizer::parseSpecial+0x3fd
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
@ 347]
chrome_23e!WebCore::HTMLTokenizer::parseTag+0x112c
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
@ 1495]
chrome_23e!WebCore::HTMLTokenizer::write+0x410
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
@ 1726]
chrome_23e!WebCore::HTMLTokenizer::notifyFinished+0x27c
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
@ 2014]
chrome_23e!WebCore::CachedImage::checkNotify+0x3a
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedimage.cpp
@ 320]
chrome_23e!WebCore::CachedScript::data+0x99
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedscript.cpp
@ 98]
chrome_23e!WebCore::Loader::Host::didFinishLoading+0xab
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\loader.cpp
@ 305]
chrome_23e!WebCore::SubresourceLoader::didFinishLoading+0x2b
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\subresourceloader.cpp
@ 183]
chrome_23e!WebCore::ResourceLoader::didFinishLoading+0x7
[c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\resourceloader.cpp
@ 417]
chrome_23e!WebCore::ResourceHandleInternal::OnCompletedRequest+0xf7
[c:\b\slave\chromium-rel-xp\build\src\webkit\glue\resource_handle_impl.cc
@ 636]
chrome_23e!ResourceDispatcher::OnRequestComplete+0x86
[c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.cc
@ 419]
chrome_23e!IPC::MessageWithTuple
>::Dispatch+0x30
[c:\b\slave\chromium-rel-xp\build\src\chrome\common\ipc_message_utils.h
@ 1135]
chrome_23e!ResourceDispatcher::DispatchMessageW+0x97
[c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.cc
@ 464]
chrome_23e!ResourceDispatcher::OnMessageReceived+0x174
[c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.cc
@ 277]
chrome_23e!RenderView::OnMessageReceived+0x81
[c:\b\slave\chromium-rel-xp\build\src\chrome\renderer\render_view.cc @
333]
chrome_23e!MessageRouter::RouteMessage+0x34
[c:\b\slave\chromium-rel-xp\build\src\chrome\common\message_router.cc
@ 39]
chrome_23e!MessageRouter::OnMessageReceived+0x30
[c:\b\slave\chromium-rel-xp\build\src\chrome\common\message_router.cc
@ 30]
chrome_23e!ChildThread::OnMessageReceived+0x36
[c:\b\slave\chromium-rel-xp\build\src\chrome\common\child_thread.cc @
72]
chrome_23e!RunnableMethod >::Run+0x17
[c:\b\slave\chromium-rel-xp\build\src\base\task.h @ 308]
chrome_23e!MessageLoop::RunTask+0x80
[c:\b\slave\chromium-rel-xp\build\src\base\message_loop.cc @ 309]
chrome_23e!MessageLoop::DoWork+0x1ea
[c:\b\slave\chromium-rel-xp\build\src\base\message_loop.cc @ 416]
chrome_23e!base::MessagePumpDefault::Run+0x111
[c:\b\slave\chromium-rel-xp\build\src\base\message_pump_default.cc @
50]
chrome_23e!MessageLoop::RunInternal+0xb7
[c:\b\slave\chromium-rel-xp\build\src\base\message_loop.cc @ 197]
chrome_23e!MessageLoop::RunHandler+0xa0
[c:\b\slave\chromium-rel-xp\build\src\base\message_loop.cc @ 181]
chrome_23e!

[chromium-dev] Re: Where is the data for reliablity and purify tests stored?

[John Abd-El-Malek]

Thanks for the info, I'll update the data now.

On Sat, Feb 21, 2009 at 12:39 PM, Erik Kay  wrote:

> John,
>
> I just sent out email this past week to chromium-dev about an updated
> wiki page with all of the Purify info you could want (search for
> "Using Purify").  The page is here:
>
> http://dev.chromium.org/developers/how-tos/using-purify
>
> The short answer for these tests is that the data is in:
>  src/chrome/test/data/purify
>
> and the data that you need in order to add to these config files is here:
>  http://build.chromium.org/buildbot/purify/unit/
>
> Erik
>
>
> On Sat, Feb 21, 2009 at 12:12 PM, John Abd-El-Malek 
> wrote:
> > (CCing chrome-dev so that others who don't know can search for this
> later.
> >  Using Erik's & Huan's chromium emails so reply get sent to the list).
> >
> > I submitted some refactoring and now I'm seeing the reliability and
> purify
> > tests are red, which I think is a false alarm due to callstacks changing.
> > For the reliability tests, this is the new regression.  I don't think my
> > code could have affected this, so my hunch is that this callstack didn't
> > match an existing list since RenderThread::OnMessageReceived is now
> > ChildThread::OnMessageReceived.  But I can't find out where the existing
> > crash callstacks are stored so I can verify this?
> >
> >
> http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Reliability/builds/1155/steps/reliability%20tests/logs/stdio
> >
> > REGRESSION: NEW crash stack traces found
> > 
> > chrome_23e!WebCore::FrameLoader::submitFormAgain+0x1e
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\frameloader.cpp
> > @ 511]
> > chrome_23e!WebCore::FrameLoader::executeScript+0x5d
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\frameloader.cpp
> > @ 788]
> > chrome_23e!WebCore::HTMLTokenizer::scriptExecution+0xc7
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> > @ 608]
> > chrome_23e!WebCore::HTMLTokenizer::notifyFinished+0x204
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> > @ 1986]
> > chrome_23e!WebCore::CachedScript::addClient+0x23
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedscript.cpp
> > @ 57]
> > chrome_23e!WebCore::HTMLTokenizer::scriptHandler+0x404
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> > @ 494]
> > chrome_23e!WebCore::HTMLTokenizer::parseSpecial+0x3fd
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> > @ 347]
> > chrome_23e!WebCore::HTMLTokenizer::parseTag+0x112c
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> > @ 1495]
> > chrome_23e!WebCore::HTMLTokenizer::write+0x410
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> > @ 1726]
> > chrome_23e!WebCore::HTMLTokenizer::notifyFinished+0x27c
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
> > @ 2014]
> > chrome_23e!WebCore::CachedImage::checkNotify+0x3a
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedimage.cpp
> > @ 320]
> > chrome_23e!WebCore::CachedScript::data+0x99
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedscript.cpp
> > @ 98]
> > chrome_23e!WebCore::Loader::Host::didFinishLoading+0xab
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\loader.cpp
> > @ 305]
> > chrome_23e!WebCore::SubresourceLoader::didFinishLoading+0x2b
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\subresourceloader.cpp
> > @ 183]
> > chrome_23e!WebCore::ResourceLoader::didFinishLoading+0x7
> >
> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\resourceloader.cpp
> > @ 417]
> > chrome_23e!WebCore::ResourceHandleInternal::OnCompletedRequest+0xf7
> > [c:\b\slave\chromium-rel-xp\build\src\webkit\glue\resource_handle_impl.cc
> @
> > 636]
> > chrome_23e!ResourceDispatcher::OnRequestComplete+0x86
> >
> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.cc @
> > 419]
> > chrome_23e!IPC::MessageWithTuple
> >>::Dispatch &

[chromium-dev] Re: Where is the data for reliablity and purify tests stored?

[John Abd-El-Malek]

great, thanks.

On Sun, Feb 22, 2009 at 2:31 PM, Patrick Johnson wrote:

> Hey John,
> I filed a bug for the reliability crash (
> http://code.google.com/p/chromium/issues/detail?id=7951) and added it to
> our known crashes file.
>
> Patrick
>
>
> On Sat, Feb 21, 2009 at 12:12 PM, John Abd-El-Malek wrote:
>
>> (CCing chrome-dev so that others who don't know can search for this later.
>>  Using Erik's & Huan's chromium emails so reply get sent to the list).
>>
>> I submitted some refactoring and now I'm seeing the reliability and purify
>> tests are red, which I think is a false alarm due to callstacks changing.
>>
>> For the reliability tests, this is the new regression.  I don't think my
>> code could have affected this, so my hunch is that this callstack didn't
>> match an existing list since RenderThread::OnMessageReceived is now
>> ChildThread::OnMessageReceived.  But I can't find out where the existing
>> crash callstacks are stored so I can verify this?
>>
>>
>> http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Reliability/builds/1155/steps/reliability%20tests/logs/stdio
>>
>> REGRESSION: NEW crash stack traces found
>> 
>> chrome_23e!WebCore::FrameLoader::submitFormAgain+0x1e 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\frameloader.cpp
>>  @ 511]
>> chrome_23e!WebCore::FrameLoader::executeScript+0x5d 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\frameloader.cpp
>>  @ 788]
>> chrome_23e!WebCore::HTMLTokenizer::scriptExecution+0xc7 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
>>  @ 608]
>> chrome_23e!WebCore::HTMLTokenizer::notifyFinished+0x204 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
>>  @ 1986]
>> chrome_23e!WebCore::CachedScript::addClient+0x23 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedscript.cpp
>>  @ 57]
>> chrome_23e!WebCore::HTMLTokenizer::scriptHandler+0x404 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
>>  @ 494]
>> chrome_23e!WebCore::HTMLTokenizer::parseSpecial+0x3fd 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
>>  @ 347]
>> chrome_23e!WebCore::HTMLTokenizer::parseTag+0x112c 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
>>  @ 1495]
>> chrome_23e!WebCore::HTMLTokenizer::write+0x410 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
>>  @ 1726]
>> chrome_23e!WebCore::HTMLTokenizer::notifyFinished+0x27c 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\html\htmltokenizer.cpp
>>  @ 2014]
>> chrome_23e!WebCore::CachedImage::checkNotify+0x3a 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedimage.cpp
>>  @ 320]
>> chrome_23e!WebCore::CachedScript::data+0x99 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\cachedscript.cpp
>>  @ 98]
>> chrome_23e!WebCore::Loader::Host::didFinishLoading+0xab 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\loader.cpp
>>  @ 305]
>> chrome_23e!WebCore::SubresourceLoader::didFinishLoading+0x2b 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\subresourceloader.cpp
>>  @ 183]
>> chrome_23e!WebCore::ResourceLoader::didFinishLoading+0x7 
>> [c:\b\slave\chromium-rel-xp\build\src\third_party\webkit\webcore\loader\resourceloader.cpp
>>  @ 417]
>> chrome_23e!WebCore::ResourceHandleInternal::OnCompletedRequest+0xf7 
>> [c:\b\slave\chromium-rel-xp\build\src\webkit\glue\resource_handle_impl.cc @ 
>> 636]
>> chrome_23e!ResourceDispatcher::OnRequestComplete+0x86 
>> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.cc @ 
>> 419]
>> chrome_23e!IPC::MessageWithTuple 
>> >::Dispatch> ResourceDispatcher::*)(int,URLRequestStatus const &)>+0x30 
>> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\ipc_message_utils.h @ 
>> 1135]
>> chrome_23e!ResourceDispatcher::DispatchMessageW+0x97 
>> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.cc @ 
>> 464]
>> chrome_23e!ResourceDispatcher::OnMessageReceived+0x174 
>> [c:\b\slave\chromium-rel-xp\build\src\chrome\common\resource_dispatcher.

[chromium-dev] Thoughts regarding exposing --single-process, in-process-plugins in release builds

[John Abd-El-Malek]

I was looking at the second top crasher in 2.0.166.1, and it turned out that
these users are running with --in-process-plugins.  This turns off the
sandbox and runs plugins in the renderer process.
So far we've exposed all the internal command line switches to all users,
but I'm wondering if that has outlived its usefulness. We don't test either
mode on chromebot, while in-process-plugins doesn't even have any tests. I
don't think spending much development time on these modes is worth the
opportunity cost.

The flip side is in the past they have been useful to have around, i.e. when
someone complains about a bug, we sometimes ask them to try these modes.

So I propose that we disable these flags in release builds, and if we want
to test on users, we can point them towards debug builds off the build
server. Obviously this is more work for them, but I think this avoids
distracting us with looking at modes that are only used by a minority of
users, and which we know are already broken. The bigger issue is why these
users used those modes. I think in the past we might have suggested it to
people if they had performance problems etc, but hopefully these are taken
care of by now, and if not, better to know it anyways by having these users
use the standard multi-process mode.

Any strong opposition to this?

--~--~-~--~~~---~--~~
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: Thoughts regarding exposing --single-process, in-process-plugins in release builds

[John Abd-El-Malek]

I thought it wouldn't be as useful, since the Chromium build will use a
different profile so the differences will be even more..

On Mon, Mar 2, 2009 at 4:30 PM, Mark Larson (Google) wrote:

> Can we disable them for Google Chrome builds, and leave them on for
> Chromium?
> We don't currently have an archive of debug builds, but we do have that for
> Chromium release builds.
>
> --Mark
>
> On Mon, Mar 2, 2009 at 16:16, John Abd-El-Malek  wrote:
>
>> I was looking at the second top crasher in 2.0.166.1, and it turned out
>> that these users are running with --in-process-plugins.  This turns off the
>> sandbox and runs plugins in the renderer process.
>> So far we've exposed all the internal command line switches to all users,
>> but I'm wondering if that has outlived its usefulness. We don't test
>> either mode on chromebot, while in-process-plugins doesn't even have any
>> tests. I don't think spending much development time on these modes is worth
>> the opportunity cost.
>>
>> The flip side is in the past they have been useful to have around, i.e.
>> when someone complains about a bug, we sometimes ask them to try these
>> modes.
>>
>> So I propose that we disable these flags in release builds, and if we want
>> to test on users, we can point them towards debug builds off the build
>> server. Obviously this is more work for them, but I think this avoids
>> distracting us with looking at modes that are only used by a minority of
>> users, and which we know are already broken. The bigger issue is why these
>> users used those modes. I think in the past we might have suggested it to
>> people if they had performance problems etc, but hopefully these are taken
>> care of by now, and if not, better to know it anyways by having these users
>> use the standard multi-process mode.
>>
>> Any strong opposition to this?
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Thoughts regarding exposing --single-process, in-process-plugins in release builds

[John Abd-El-Malek]

On Mon, Mar 2, 2009 at 4:31 PM, Erik Kay  wrote:

> If we do this, I'd suggest that we leave them in on Chromium builds,
> but not Chrome builds rather than Release vs. Debug.  I think asking a
> user to switch to Debug is a lot worse since it'll also slow them down
> a lot.
>
> As for why people are doing this, it's likely because of the large
> number of crashes related to third party DLL injection that turning
> off the sandbox fixes. Given this, I'd say that we're not in a
> position to remove these flags since they're currently the only
> recommended workaround.


Right, I realize there are still compatibility problems, which is why
I purposely left --no-sandbox out of the list.  If people are using
-in-process-plugins or --single-process instead of --no-sandbox, that's
worse off..

>
>
> Erik
>
>
> On Mon, Mar 2, 2009 at 4:25 PM, Elliot Glaysher (Chromium)
>  wrote:
> >
> > +1. We absolutely should do this.
> >
> > -- Elliot
> >
> > On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek 
> wrote:
> >> I was looking at the second top crasher in 2.0.166.1, and it turned out
> that
> >> these users are running with --in-process-plugins.  This turns off the
> >> sandbox and runs plugins in the renderer process.
> >> So far we've exposed all the internal command line switches to all
> users,
> >> but I'm wondering if that has outlived its usefulness. We don't test
> either
> >> mode on chromebot, while in-process-plugins doesn't even have any tests.
> I
> >> don't think spending much development time on these modes is worth the
> >> opportunity cost.
> >> The flip side is in the past they have been useful to have around, i.e.
> when
> >> someone complains about a bug, we sometimes ask them to try these modes.
> >> So I propose that we disable these flags in release builds, and if we
> want
> >> to test on users, we can point them towards debug builds off the build
> >> server. Obviously this is more work for them, but I think this avoids
> >> distracting us with looking at modes that are only used by a minority of
> >> users, and which we know are already broken. The bigger issue is why
> these
> >> users used those modes. I think in the past we might have suggested it
> to
> >> people if they had performance problems etc, but hopefully these are
> taken
> >> care of by now, and if not, better to know it anyways by having these
> users
> >> use the standard multi-process mode.
> >> Any strong opposition to this?
> >> >
> >>
> >
> > > >
> >
>

--~--~-~--~~~---~--~~
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: Thoughts regarding exposing --single-process, in-process-plugins in release builds

[John Abd-El-Malek]

Also, I don't feel that strongly regarding Chrome vs Chromium or Debug vs
Release.  The only thing I'm strongly against is having this in Chrome
Release :)

On Mon, Mar 2, 2009 at 4:33 PM, John Abd-El-Malek  wrote:

>
>
> On Mon, Mar 2, 2009 at 4:31 PM, Erik Kay  wrote:
>
>> If we do this, I'd suggest that we leave them in on Chromium builds,
>> but not Chrome builds rather than Release vs. Debug.  I think asking a
>> user to switch to Debug is a lot worse since it'll also slow them down
>> a lot.
>>
>> As for why people are doing this, it's likely because of the large
>> number of crashes related to third party DLL injection that turning
>> off the sandbox fixes. Given this, I'd say that we're not in a
>> position to remove these flags since they're currently the only
>> recommended workaround.
>
>
> Right, I realize there are still compatibility problems, which is why
> I purposely left --no-sandbox out of the list.  If people are using
> -in-process-plugins or --single-process instead of --no-sandbox, that's
> worse off..
>
>>
>>
>> Erik
>>
>>
>> On Mon, Mar 2, 2009 at 4:25 PM, Elliot Glaysher (Chromium)
>>  wrote:
>> >
>> > +1. We absolutely should do this.
>> >
>> > -- Elliot
>> >
>> > On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek 
>> wrote:
>> >> I was looking at the second top crasher in 2.0.166.1, and it turned out
>> that
>> >> these users are running with --in-process-plugins.  This turns off the
>> >> sandbox and runs plugins in the renderer process.
>> >> So far we've exposed all the internal command line switches to all
>> users,
>> >> but I'm wondering if that has outlived its usefulness. We don't test
>> either
>> >> mode on chromebot, while in-process-plugins doesn't even have any
>> tests. I
>> >> don't think spending much development time on these modes is worth the
>> >> opportunity cost.
>> >> The flip side is in the past they have been useful to have around, i.e.
>> when
>> >> someone complains about a bug, we sometimes ask them to try these
>> modes.
>> >> So I propose that we disable these flags in release builds, and if we
>> want
>> >> to test on users, we can point them towards debug builds off the build
>> >> server. Obviously this is more work for them, but I think this avoids
>> >> distracting us with looking at modes that are only used by a minority
>> of
>> >> users, and which we know are already broken. The bigger issue is why
>> these
>> >> users used those modes. I think in the past we might have suggested it
>> to
>> >> people if they had performance problems etc, but hopefully these are
>> taken
>> >> care of by now, and if not, better to know it anyways by having these
>> users
>> >> use the standard multi-process mode.
>> >> Any strong opposition to this?
>> >> >
>> >>
>> >
>> > >> >
>> >
>>
>
>

--~--~-~--~~~---~--~~
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: Thoughts regarding exposing --single-process, in-process-plugins in release builds

[John Abd-El-Malek]

I guess that could work as well.  I think that Chrome's full usefulness
comes when it's multi-process and sandboxed, and the other modes are not
well tested.  We should figure out why these users are resorting to using
these flags day-to-day, but we shouldn't have to support them when using
these flags (i.e. they can use Chromium builds if they really want).

On Mon, Mar 2, 2009 at 4:27 PM, Matt Perry  wrote:

> What if we could include the full command line for the process in
> crash dumps?  Then we could filter out crashes when certain flags are
> present, but still allow these flags in release builds when necessary.
>
> On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek 
> wrote:
> > I was looking at the second top crasher in 2.0.166.1, and it turned out
> that
> > these users are running with --in-process-plugins.  This turns off the
> > sandbox and runs plugins in the renderer process.
> > So far we've exposed all the internal command line switches to all users,
> > but I'm wondering if that has outlived its usefulness. We don't test
> either
> > mode on chromebot, while in-process-plugins doesn't even have any tests.
> I
> > don't think spending much development time on these modes is worth the
> > opportunity cost.
> > The flip side is in the past they have been useful to have around, i.e.
> when
> > someone complains about a bug, we sometimes ask them to try these modes.
> > So I propose that we disable these flags in release builds, and if we
> want
> > to test on users, we can point them towards debug builds off the build
> > server. Obviously this is more work for them, but I think this avoids
> > distracting us with looking at modes that are only used by a minority of
> > users, and which we know are already broken. The bigger issue is why
> these
> > users used those modes. I think in the past we might have suggested it to
> > people if they had performance problems etc, but hopefully these are
> taken
> > care of by now, and if not, better to know it anyways by having these
> users
> > use the standard multi-process mode.
> > Any strong opposition to this?
> > > >
> >
>

--~--~-~--~~~---~--~~
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: Thoughts regarding exposing --single-process, in-process-plugins in release builds

[John Abd-El-Malek]

On Mon, Mar 2, 2009 at 4:42 PM, Nick Carter  wrote:

> This source recommends "--in-process-plugins" to make chrome work on
> win7/64bit.
>
>
> http://www.chromeplugins.org/tips-tricks/how-to-run-google-chrome-on-windows-7-64-bit/


Ben says that this is now fixed.


>
> <http://www.chromeplugins.org/tips-tricks/how-to-run-google-chrome-on-windows-7-64-bit/>
>
>  - nick
>
> On Mon, Mar 2, 2009 at 4:36 PM, Evan Martin  wrote:
>
>>
>> On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek 
>> wrote:
>> > I was looking at the second top crasher in 2.0.166.1, and it turned out
>> that
>> > these users are running with --in-process-plugins.  This turns off the
>> > sandbox and runs plugins in the renderer process.
>> > So far we've exposed all the internal command line switches to all
>> users,
>> > but I'm wondering if that has outlived its usefulness. We don't test
>> either
>> > mode on chromebot, while in-process-plugins doesn't even have any tests.
>> I
>> > don't think spending much development time on these modes is worth the
>> > opportunity cost.
>> > The flip side is in the past they have been useful to have around, i.e.
>> when
>> > someone complains about a bug, we sometimes ask them to try these modes.
>> > So I propose that we disable these flags in release builds, and if we
>> want
>> > to test on users, we can point them towards debug builds off the build
>> > server. Obviously this is more work for them, but I think this avoids
>> > distracting us with looking at modes that are only used by a minority of
>> > users, and which we know are already broken. The bigger issue is why
>> these
>> > users used those modes. I think in the past we might have suggested it
>> to
>> > people if they had performance problems etc, but hopefully these are
>> taken
>> > care of by now, and if not, better to know it anyways by having these
>> users
>> > use the standard multi-process mode.
>> > Any strong opposition to this?
>>
>> The advantage to turning off these flags is that it reduces the noise
>> in the crash system.
>> Therefore, it seems reasonable to me we only want to turn off those
>> flags where we want less noise:official release builds.
>>
>> I am scared there are some users for whom removing this flag will
>> cause their browser to get worse.
>> It would be nice if there was a way for such users to still opt in.
>> One idea is simply renaming the flag.  That would also sidestep all
>> this "only in official builds" logic.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Thoughts regarding exposing --single-process, in-process-plugins in release builds

[John Abd-El-Malek]

On Mon, Mar 2, 2009 at 4:49 PM, Darin Fisher  wrote:

> Wow... we definitely have re-entrancy bugs with --in-process-plugins that
> are not worth fixing.
> Command line options like this are, however, kind of nice since it allows
> you to tell
> a user to try the flag to see if it fixes a particular problem.  Maybe we
> could allow the
> option but show a MessageBox at startup warning them about the fact that
> the option
> is unsupported and potentially hazardous to the stability of Chrome.
>

But then we still have the same side-effects (less security, crash reports).
 I think this is a small enough use-case, that pointing users towards
Chromium or Debug Chrome builds is almost just as good, while avoiding the
overhead with having official Chrome builds used in untested and buggy
configurations.


>
> -Darin
>
>
> On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek wrote:
>
>> I was looking at the second top crasher in 2.0.166.1, and it turned out
>> that these users are running with --in-process-plugins.  This turns off the
>> sandbox and runs plugins in the renderer process.
>> So far we've exposed all the internal command line switches to all users,
>> but I'm wondering if that has outlived its usefulness. We don't test
>> either mode on chromebot, while in-process-plugins doesn't even have any
>> tests. I don't think spending much development time on these modes is worth
>> the opportunity cost.
>>
>> The flip side is in the past they have been useful to have around, i.e.
>> when someone complains about a bug, we sometimes ask them to try these
>> modes.
>>
>> So I propose that we disable these flags in release builds, and if we want
>> to test on users, we can point them towards debug builds off the build
>> server. Obviously this is more work for them, but I think this avoids
>> distracting us with looking at modes that are only used by a minority of
>> users, and which we know are already broken. The bigger issue is why these
>> users used those modes. I think in the past we might have suggested it to
>> people if they had performance problems etc, but hopefully these are taken
>> care of by now, and if not, better to know it anyways by having these users
>> use the standard multi-process mode.
>>
>> Any strong opposition to this?
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: Thoughts regarding exposing --single-process, in-process-plugins in release builds

[John Abd-El-Malek]

What about hangs?  These will show up in the MS dashboard that Carlos looks
like.  UMA stats might be off etc...
I think in general since these configurations aren't tested, it seems a
little odd to update these users.  Just as we saw for 2.0.166.1, an update
can suddenly start crashing them often.

On Mon, Mar 2, 2009 at 4:53 PM, Mike Belshe  wrote:

> Maybe turn of crash reporting when these flags are enabled?
> Mike
>
>
> On Mon, Mar 2, 2009 at 4:49 PM, Darin Fisher  wrote:
>
>> Wow... we definitely have re-entrancy bugs with --in-process-plugins that
>> are not worth fixing.
>> Command line options like this are, however, kind of nice since it allows
>> you to tell
>> a user to try the flag to see if it fixes a particular problem.  Maybe we
>> could allow the
>> option but show a MessageBox at startup warning them about the fact that
>> the option
>> is unsupported and potentially hazardous to the stability of Chrome.
>>
>> -Darin
>>
>>
>> On Mon, Mar 2, 2009 at 4:16 PM, John Abd-El-Malek wrote:
>>
>>> I was looking at the second top crasher in 2.0.166.1, and it turned out
>>> that these users are running with --in-process-plugins.  This turns off the
>>> sandbox and runs plugins in the renderer process.
>>> So far we've exposed all the internal command line switches to all users,
>>> but I'm wondering if that has outlived its usefulness. We don't test
>>> either mode on chromebot, while in-process-plugins doesn't even have any
>>> tests. I don't think spending much development time on these modes is worth
>>> the opportunity cost.
>>>
>>> The flip side is in the past they have been useful to have around, i.e.
>>> when someone complains about a bug, we sometimes ask them to try these
>>> modes.
>>>
>>> So I propose that we disable these flags in release builds, and if we
>>> want to test on users, we can point them towards debug builds off the build
>>> server. Obviously this is more work for them, but I think this avoids
>>> distracting us with looking at modes that are only used by a minority of
>>> users, and which we know are already broken. The bigger issue is why these
>>> users used those modes. I think in the past we might have suggested it to
>>> people if they had performance problems etc, but hopefully these are taken
>>> care of by now, and if not, better to know it anyways by having these users
>>> use the standard multi-process mode.
>>>
>>> Any strong opposition to this?
>>>
>>>
>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Thoughts regarding exposing --single-process, in-process-plugins in release builds

[John Abd-El-Malek]

The point I was trying to make was that this isn't just about crash dumps.
 For example, engineering effort will have to be done to filter them out of
UMA statistics.  Also, there are reentrancy issues with plugins as Darin
mentioned.  We know of them, but haven't bothered spending time chasing them
down since we considered -in-process-plugins to be just a testing mode, not
one used by users.
I really don't think we want to support this kind of mode (single-process or
in-process-plugins).  If we do, then we will have to make sure all of our
tests exercise this code (which we're not even close to).  Until that point,
I think it's doesn't serve our users to give (and autoupdate) builds that
we're not testing.

I'm not saying it's not possible to do this, just the opportunity cost is
not worth it.

If anywhere near 50% of users started using whacky flags because of bugs in
our code, we have major problems, and we should be fixing them instead of
spending time supporting multiple modes.

On Mon, Mar 2, 2009 at 5:52 PM, Mike Belshe  wrote:

> I don't think it is so black and white.  If we're going to ignore all crash
> dumps that have certain cmdline flags anyway, then collecting dumps is not
> interesting.
>
> The problem is that if 50% of our userbase ends up using some whacky flag
> that causes crashes, and we don't collect the data, we could be blind to it.
>  I don't think this is a realistic scenario, but I can't stay it is
> impossible either.
>
> What I do believe is:
>   a) We should figure out the configurations we "support".
>   b) If we're not going to support a particular configuration, we should
> let the user know.
>   c) If we're not going to support a particular configuration, it needs to
> be SUPER OBVIOUS in the crash dump that the configuration was an unsupported
> one, so that we don't waste time on the bug.
>
> Proposal:
>   a) Put up the warning message on startup "unsupported command line
> flags", as Darin suggests.
>   b) find a way to make go/crash generally filter out crashes which contain
> dangerous cmdline flags that we don't wish to debug.
>   c) figure out a way to avoid having crashers for unsupported configs from
> going to microsoft.
>
> Mike
>
>
>
>
>
> On Mon, Mar 2, 2009 at 4:55 PM, Peter Kasting wrote:
>
>> On Mon, Mar 2, 2009 at 4:53 PM, Mike Belshe  wrote:
>>
>>> Maybe turn of crash reporting when these flags are enabled?
>>
>>
>> No, this just makes life better for us, not for users.
>>
>> 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] Telling svn to ignore VS's .user files

[John Abd-El-Malek]

Just a heads up for others who find it annoying when svn st always shows the
vcproj.GOOGLE.username.user files.  You can put *.user in the global-ignores
setting in svn's config file to avoid this.

--~--~-~--~~~---~--~~
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: More plugin questions

[John Abd-El-Malek]

On Thu, Mar 5, 2009 at 8:59 PM, eager_learner
wrote:

>
> Hello Plugin Gurus
>
> The following link is very well written and I hope it still holds good
>
> http://sites.google.com/a/chromium.org/dev/developers/design-documents/plugin-architecture
>
> I have some followup questions on plugin development (internal)
>
> 1. Based on the plugin architecture design document, can you point me
> to an existing plugin (flash, shockwave, activeX) code file names? The
> source Navigator project that I have created does not show any
> inheritance of WebPplugin


I think there's some confusion between the internal Chrome classes used to
implement multi-process plugins, and the NPAPI APIs that are exposed by any
plugin (external or internal).

>
>
> 2. Again the debugging process seems a little difficult if new
> processes are spawned (one for the browser, one for the renderer and
> one for the plugin). How can we attach Visual Studio to the plugin?


Start chrome with --renderer-startup-dialog and/or --plugin-startup-dialog
to have a message box load on process startup, then you can attach VS.


>
>
> 3. Do plugin writers need to know anything about the class
> PluginInstance? It seems to create the WebPlugin or atleast gets
> passed it and has a reference to it.


No it's internal to the plugin implementation.

>
>
> Simply put, what needs to be done by plugin developers to develop an
> internal plugin?


Have a look at plugin_list.cc, specifically the constructor which adds
default_plugin.  The main thing to look at is how it maps the three NPAPI
methods (NP_GetEntryPoints/NP_Initialize/NP_Shutdown) to functions that are
linked in the same binary.



> Does the NPAPI need to know about the PluginInstance?


No

>
>
> Perhaps there is a clearer document that explains this.
>
> Thanks
> Vijay
> >
>

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

[chromium-dev] Spam on chromium-reviews

[John Abd-El-Malek]

I'm guessing I'm not the only one who's irritated by it.  Can we make it so
that only members can post to chromium-reviews?  We can automatically
subscribe everyone who's sent a review in the last month or something.
What do people think?

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

[chromium-dev] Re: Spam on chromium-reviews

[John Abd-El-Malek]

sweet, thanks.

On Fri, Mar 6, 2009 at 10:45 AM, Ian Fette  wrote:

> I enabled moderation for new senders. This shouldn't cause the problem
> Peter mentions below, though may cause delays for new posters. Hopefully
> between myself and others we can moderate reasonably efficiently (we're
> already doing this for dev, many -bugs messages get held for moderation
> because they "look like spam", and we seem to have a reasonable turnaround
> time.)
> -Ian
>
> On Fri, Mar 6, 2009 at 10:38 AM, Peter Kasting wrote:
>
>> On Fri, Mar 6, 2009 at 10:34 AM, John Abd-El-Malek wrote:
>>
>>> I'm guessing I'm not the only one who's irritated by it.  Can we make it
>>> so that only members can post to chromium-reviews?  We can automatically
>>> subscribe everyone who's sent a review in the last month or something.
>>
>>
>> Would this prevent random new people from submitting a patch to Rietveld
>> and having it mailed out for review?
>>
>> We might have to ask Jon Conradt to moderate first posts like he does
>> already for some of the other lists.
>>
>> 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: More plugin questions

[John Abd-El-Malek]

Hi Vijay,
It sounds like reading up on NPAPI and how Windows applications paint is in
order :)

Here are some documents:

Here's the high level link about NPAPI on the Mozilla docs, links to samples
etc: https://developer.mozilla.org/en/Plugins
This is the reference for NPAPI:
https://developer.mozilla.org/en/Gecko_Plugin_API_Reference

Here's the MSDN page on GDI, which shows how to paint into bitmaps etc:
http://msdn.microsoft.com/en-us/library/dd145203(VS.85).aspx

I'll fill in a few answers below.


On Fri, Mar 6, 2009 at 2:03 PM, eager_learner
wrote:

>
> Thanks John and Marshall. I have much work done in the lines of what
> Marshall has suggested except that I did this in the plugin_list.cc as
> opposed to plugin_list_win.cc. I got all my clues from the default
> plugin. I am able to get the stream for the content-type as desired. I
> just dont know what is available in terms of UI for me to display.
>
> At the end of my followup questions are things I have done [GOTO ABC
> at the end of my questions]
>
> Q1. SetWindow entry point function similar to NPP_SetWindow gets
> passed a parameter of type NPWindow
>//static NPError SetWindow_metalink(NPP instance, NPWindow
> *window)
>a)   How can this be used to display anything for the plugin?


see the npapi documentation.  depending on whether it's
windowed/windoweless, you'll either have to run a message loop for the HWND,
or you'll be called with an HDC (on windows) to paint.



>
>b)   window->window is of type void*  and is expected to be a
> window handle. Can this be platform agnostic(Win32/Linux...)? Are


no


>
> there Chrome API wrappers that abstract details of Windowing and
> rendering? I would assume that this is part of Webkit. I have no clue
> about this. Pointers to docs and smaple code highly appreciated.
>
> Q2. Regarding the archtecture document
>
> http://sites.google.com/a/chromium.org/dev/developers/design-documents/plugin-architecture,there
> is
>i. a browser process
>ii. a rendering tab process  and
>   iii. a plugin process



>
>   Assuming that the Entrypoint functions are running in the plugin
> process (??? correct me), how will the plugin process communicate with
> the rendering process to
>   display what it needs to?


you don't need to worry about any of this, it's all handled transparently.
 you just need to implement the NPAPI entry points.


> The WebKit is shown to be part of the
> rendering process. Does the plugin writer need to be aware of the IPC
> mechanism defined in chrome
>   and if so where could I find that.
>
> Q3. What I would like to do is have a dynamically generated HTML page
> with a table of items based on the stream that I get in NPP_Write
> function. Can I summon the renderer via the NPWindow argument? Any


no.  but you can script the renderer.  see NPObject in the NPAPI
documentation.

>
> Example code for this?
>
> Q4. A general question I have on browser plugins is whether the screen
> blitz is platform independent (Win32, Linux etc).


no


> Is there any
> conditionally compiled code that plugin developers generally have for
> display. This question is rephrasing Q1.b.
>
> Q5. Since I am working on the metalink plugin ["PoC"] as an internal
> plugin, I will need the plugin-process to spawn threads
> (chomeThread??) to download each piece concurrantly. Is there a
> document explaining to developers API like ChromeThread etc?


the documentation for the chrome classes is mostly in the headers.

>
>
> Below is the summary of where I have reached.
>
> ABC:
> //in plugin_list.cc in PluginList::PluginList() I added the following
>#if defined (OS_WIN )
>#if defined (METALINK)
>  const PluginVersionInfo metalink_plugin = {
>  FilePath(kDefaultPluginLibraryName),
>  L"Metalink Plug-in",
>  L"Provides the starting point for Metalink
> plugin to be
> registered and called appropriately",
>  L"1",
>  L"application/metalink+xml",
>  L"metalink",
>  L"Something",
>  {
>metalink_plugin::NP_GetEntryPoints,
>metalink_plugin::NP_Initialize,
>metalink_plugin::NP_Shutdown
>  }
>  };
>  internal_plugins_.push_back(metalink_plugin);
>#endif
>#endif
>
> My Entrypoints for NPAPI are also defined
>NPError API_CALL NP_GetEntryPoints(NPPluginFuncs*
> funcs)
>{
>#if 0
>  int * p = 0;
>  *p = 22; // my assert
> 

[chromium-dev] Re: Burned out trying to do SendWithTimeout

[John Abd-El-Malek]

The only place that calls it in the browser process is
BrowserAccessbilityManager, which I'm guessing isn't critical for the ports
(it's actually disabled by default on our shipping builds).
 success = members->render_widget_host_->process()->channel()->
SendWithTimeout(msg, kAccessibilityMessageTimeOut);

process() returns a RenderProcessHost, whose channel() returns a SyncChannel
which has the SendWithTimeout.

On Thu, Mar 12, 2009 at 11:04 AM, Avi Drissman  wrote:

> OK, so there's this nifty SendWithTimeout on SyncChannel. Awesome. And
> RenderViewHost just has to call it, just like it calls Send() today for
> other calls.
>
> This is where things are falling apart for me.
>
> For Send(), RenderViewHost calls (via RWH) its Send(), which calls
> RenderProcessHost's Send(), which ends up in BrowserRenderProcessHost, which
> has a SyncChannel. But the intermediate steps are a blur. RenderProcessHost
> doesn't actually have Send(), but apparently inherits it from
> IPC::Channel::Sender, and as far as I can tell there is no such thing.
>
> I'm obviously missing something. Thoughts?
>
> >
>

--~--~-~--~~~---~--~~
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: [extensions] Design doc: API pattern proposal

[John Abd-El-Malek]

One comment regarding synchronous IPC (I presume this is from the extension
process to the renderer\browser process): I agree that synchronous IPC is
slower, and better to be async when possible.  However, if it's used for
APIs that aren't called frequently (100 calls/s, as opposed to thousands or
ten thousands), it's not so bad.  It'll keep the programming model easy, and
the performance impact will be negligible.

On Thu, Mar 12, 2009 at 1:35 PM, Aaron Boodman  wrote:

>
>
> http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/api-pattern
>
> I'm thinking about what the general pattern for the APIs we expose to
> extensions should be. I've been leaning toward something that is quite
> a bit of a departure from the style of the DOM and more idiomatic
> JavaScript and more asynchronous.
>
> Feedback wanted.
>
> >
>

--~--~-~--~~~---~--~~
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: windowless plugin drawing

[John Abd-El-Malek]

I think it'd be very helpful to just copy & paste it here:
http://dev.chromium.org/developers/design-documents/plugin-architecture

On Thu, Mar 12, 2009 at 3:38 PM, Evan Martin  wrote:

>
> John graciously explained all this to me so I thought I'd write what I
> know before I forget.  Amanda/John, please correct me where I'm wrong!
>
> Windowless plugins are designed to run directly within the rendering
> pipeline.  When WebKit wants to draw a region of the screen involving
> the plugin it calls into the plugin code, handing it a drawing
> context.  Windowless plugins are often used in situations where the
> plugin is expected to be transparent over the page -- it's up to the
> plugin drawing code to decide how it munges the bit of the page it's
> given.
>
> To take windowless plugins out of process, you still need to
> incorporate their rendering in the (synchronous) rendering pass done
> by WebKit.  A naively slow option is to clip out the region that the
> plugin will draw on then synchronously ship that over to the plugin
> process and let it draw.  This can then be sped up with some shared
> memory.
>
> However, rendering speed is then at the mercy of the plugin process
> (imagine a page with 30 transparent plugins -- we'd need 30 round
> trips to the plugin process).  So instead we have windowless plugins
> asynchronously paint, much like how our existing page rendering is
> asynchronous with respect to the screen.  The renderer has effectively
> a backing store of what the plugin's rendered area looks like and uses
> this image when drawing, and the plugin is free to asynchronously send
> over new updates representing changes to the rendered area.
>
> All of this is complicated a bit by "transparent" plugins.  The plugin
> process needs to know what pixels it wants to draw over.  So it also
> keeps a cache of what the renderer last sent it as the page background
> behind the plugin, then lets the plugin repeatedly draw over that.
>
> So, in all, here are the buffers involved for the region drawn by a
> windowless plugin:
>
> Renderer process
>  - backing store of what the plugin last rendered as
>  - shared memory with the plugin for receiving updates ("transport DIB")
>  - copy of the page background behind the plugin (described below)
>
> Plugin process
>  - copy of the page background behind the plugin, used as the source
> material when drawing
>  - shared memory with the renderer for sending updates ("transport DIB")
>
> Why does the renderer keep a copy of the page background?  Because if
> the page background changes, we need to synchronously get the plugin
> to redraw over the new background it will appear to lag.  We can tell
> that the background changed by comparing the newly-rendered background
> against our copy of what the plugin thinks the background.  Since the
> plugin and renderer processes are asynchronous with respect to one
> another, they need separate copies.
>
> All of this sounds heinously slow, and it is, but it means there are
> no glitches when drawing, just burned CPU.
>
> On Linux we have the extra twist that the plugin expects to draw on an
> X Drawable, not a memory buffer.  However, in the local X server case
> it seems to me we can make the transport DIB live in shared memory
> (much like it does in our fast drawing path in the renderer->browser
> communication).  Implementing this is another story.  :)
>
> >
>

--~--~-~--~~~---~--~~
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: rev 11763 removes frame pointer from ResourceRequest

[John Abd-El-Malek]

The reason I did it was because in the worker process, there's no frame.
 Why/where do you need it?

On Mon, Mar 16, 2009 at 1:46 PM, Marshall Greenblatt  wrote:

> Hi John,
>
> Rev 11763 removes the WebFrame pointer that was previously passed to
> ResourceLoaderBridge::Create() in simple_resource_loader_bridge.cc.  How can
> I use the new 'routing_id' parameter to retrieve the WebFrame pointer, if
> any, that originated the request?
>
> 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: rev 11763 removes frame pointer from ResourceRequest

[John Abd-El-Malek]

two questions:1) app cache won't be used with workers, right?  or is the
goal for XHR requests from workers go through app cache?  That would be
pretty difficult to do since for example a shared worker isn't associated
with any particular renderer.
2) what is the 'context' used for?  the requestorID is the ID of the
RenderView, so we could add static methods that get a RenderView (or
WebViewDelegate) given its id, similar to how we do things in the browser
process for RenderViewHost.  Why do you need the reference btw?  Is there
code I can look at?

On Mon, Mar 16, 2009 at 2:04 PM, Michael Nordman wrote:

> We're going to need some kind of reference to the 'context' for the app
> cache impl too, i had been depending on the WebFrame ptr for this thusfar,
> but that won't help us in workers.
>
> On Mon, Mar 16, 2009 at 2:01 PM, John Abd-El-Malek wrote:
>
>> The reason I did it was because in the worker process, there's no frame.
>>  Why/where do you need it?
>>
>>
>> On Mon, Mar 16, 2009 at 1:46 PM, Marshall Greenblatt <
>> magreenbl...@gmail.com> wrote:
>>
>>> Hi John,
>>>
>>> Rev 11763 removes the WebFrame pointer that was previously passed to
>>> ResourceLoaderBridge::Create() in simple_resource_loader_bridge.cc.  How can
>>> I use the new 'routing_id' parameter to retrieve the WebFrame pointer, if
>>> any, that originated the request?
>>>
>>> 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: Top level browsing contexts and processes

[John Abd-El-Malek]

On Fri, Mar 20, 2009 at 10:23 AM, Jeremy Orlow  wrote:

> Are there any plans (long term or short) to render stuff like iframes with
> a different origin inside a different process?  Does the story get more
> complicated with plugs and extensions?
>
> *More background:*
> I'm looking at implementing window.sessionStorage.  It's spec (
> http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute) says:
>
> The sessionStorage attribute represents the set of storage areas specific
> to the current top-level browsing context.
>
> Each top-level browsing context has a unique set of session storage areas,
> one for each origin.
>
> Webkit already has a nice implementation that should actually work pretty
> well for chrome, provided that there's never more than one process per
> top-level browsing context.
>
> One area that seems much more murky to me is plugins.  I assume that if a
> plugin interacts with a page's javascript, it'll be doing it in that page's
> render process...is this correct?
>

yep that's correct.


>
> Are there any complications extensions might add?
>
>
> Thanks!
> J
>
> >
>

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

[chromium-dev] Re: Need advice on where localStorage should live

[John Abd-El-Malek]

On Fri, Mar 20, 2009 at 7:04 PM, Jeremy Orlow  wrote:

> *If you don't care where various bits of the localStorage implementation
> live and you aren't scared about letting stuff out of the sandbox, you can
> stop reading now.*
>
> *
> *
> Background:
>
> For those who don't know the spec by heart:  SessionStorage can be thought
> of as 'tab local' storage space for each origin.  LocalStorage is shared
> across all browser windows of the same origin and is persistent.  All data
> is stored in key/value pairs where both the key and value are strings.  It's
> possible to subscribe to DOM storage events.  Events and ease of use are why
> a developer might use localStorage even though the database interface
> exists.  The exact spec is here: http://dev.w3.org/html5/webstorage/
>
>
> *Where should the localStorage implementation live?
> *
>
> I'm planning on implementing localStorage very soon within Chromium.
>  Unfortunately, how to do this is not very clearcut.  Here are all the
> possibilities I know of so far:  (Note that I'm intentionally ignoring the
> backing file format for now...as that debate will partially depend on how
> it's implemented.)
>
> 1)  The most obvious solution is to have have the browser process keep
> track of the key/values for each origin and write it to disk.  The problem
> with this approach is that we're allowing user supplied data to exist in
> memory (possibly the stack at times, though we could probably avoid this if
> we tried) outside of a sandbox.  Ian Fette (and I'm sure others) have pretty
> big reservations for this reason.  That said, this is definitely the
> simplest and cleanest solution, so if we can figure out something that we're
> confident with security wise, this is how I'd like to do it.
>

I really don't see the big issue here.  We already do this with renderer
supplied data such as FORMs, POST, even really long URLs.  The main point is
to ensure that we don't trust that data.


>
> 2)  What follows from #1 is simply pulling all the localStorage code into
> its own (sandboxed) process.  The problem is that, unless a lot of the
> internet starts using localStorage, it seems disproportionately heavy
> weight.  Starting it on demand and killing it off if localStorage hasn't
> been used for a while would mitigate.
>
> 3)  A completely different solution is to use shared memory + the code
> recently written to pass file handles between processes.  The shared memory
> would be used to coordinate between processes and to store key/val data.
> One render process for each origin will take responsibility for syncing data
> to disk.  Event notifications can occur either via IPC (though sharing
> key/val data can NOT for latency/responsiveness reasons) or shared
> memory--whichever is easier.  Obviously the chief problem with this is
> memory usage.  I'm sure it'll also be more complex and have a greater
> bug/exploit cross section.
>
> 4)  A variation of #3 would be to keep all key/val data in the file and
> only use shared memory for locking (if necessary).  I'm not going to discuss
> the implementation details because I don't want us to get hung up on them,
> but the general idea would be for each process to have an open file handle
> for their origin(s) and somehow (shared memory, flock, etc) coordinate with
> the other processes.  This will almost certainly be slower than memory (if
> nothing else, due to system calls) but it'll use less memory and possibly be
> easier to make secure.
>
> 5)  One last option is to layer the whole thing on top of the HTML 5
> database layer.  Unfortunately, there's no efficient way for this layer to
> support events.  Even hooking directly into sqlite won't work since its
> triggers layer apparently only notifies you (i.e. works) if the
> insert/delete/update happens in your own process.  Of course sqlite can be
> the backing for any other option, but please, let's hold off on that
> discussion for now.
>

It seems that either way you have to build your own custom notification
system in order to alert all renderer processes if a url they have loaded
has updated storage values.  Why not use sqlite in each renderer process
then, with this system build on top of it?


>
>
> *So here are my questions:*
>
> How paranoid should we be about passing a user created string to the
> browsing process and having it send the data on to the renderer and some
> backend like sqlite?
>
> Do we trust sqlite enough to use it outside of a sandbox?  (Hopefully,
> because we're already doing this, right?  If not are there other mechanisms
> for storing the data on disk that we do trust?)
>
> Would we feel more comfortable with #1 if the renderer processes somehow
> mangled the keys and values before sending them out?  For example, they
> could base64 encode them or even do something non-deterministic so that
> attackers have no guarantee about what the memory would look like that's
> passing through the browser process?
>
>
> And, most importantly, which op

[chromium-dev] Re: Have we wasted some patches?

[John Abd-El-Malek]

On Sun, Mar 22, 2009 at 5:17 PM, cpu  wrote:

>
>
>
> On Mar 22, 8:47 am, empriser  wrote:
> > There are more than 50,000 patches onhttp://codereview.chromium.org/;
>
> I don't think so. 50k/365 = 140. That means 140 patches per day
> including weekends. We are very active but not that active.


right, the issue numbers are handed out internally by App Engine, and don't
correspond to how many issues have been created.  Also, people may create
test changelists that they never intend to send out, or may create multiple
versions for the same change.  This server is also used by v8.

>
>
> > I have some questions about it:
> > How many patches have been submitted?
> > How to filter the patches that have not been submitted?
>
> You can monitor two groups: chromium-reviews and chromium-checkins.
>
> By the way chromium-checkins is saying there are 11228 messages.
> Unfortunately some are spam.
>
> As for 'wasting patches' I think that would be very subjective. One
> person's pet feature is another's unnecessary bloat.
>
>
> >
>

--~--~-~--~~~---~--~~
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: porting chrome_process_filter

[John Abd-El-Malek]

2009/3/24 Thomas Van Lenten 

> A bunch of process handle code is something we're gonna need to look very
> carefully at.  The filtering via names may be valid on Windows, but on
> Linux, a user could have Chromium running twice (with different
> profiles/user data dirs) pointing at different displays, so we'll have to be
> very careful to make sure it's only acting on the processes in the current
> "instance" and not the other one.
>
> If I remember right when I looked at some of this, the Windows code uses
> the process filter as a hook to scan the windows to find a running Chromium
> and send it a message.  So that whole functionality should be re-abstracted,
> if needed, instead of making it have to work by walking a process list.


Right, this is used so that if the user starts Chrome a second time, it
tells the currently running exe to open a new tab.  This is the standard way
of doing it on Windows, but I don't know how Mac/Linux apps enforce
single-instance semantics.  We should first figure out if this code is
needed before porting it..


>
>
> TVL
>
>
>
> On Tue, Mar 24, 2009 at 11:31 AM, Paweł Hajdan Jr. <
> phajdan...@chromium.org> wrote:
>
>> I'm thinking about porting chrome/common/chrome_process_filter, but I
>> don't quite know how it works on Windows (there's some FindWindowEx there).
>> Could someone briefly explain what it's supposed to do?
>>
>> And some more specific questions:
>>
>> - does it match only browser process, or everything (browser, renderer,
>> etc)?
>> - would ProcessSingleton be a good starting point for making the filter
>> work on Linux? (like trying to see which process has the singleton socket
>> open)
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: porting chrome_process_filter

[John Abd-El-Malek]

On Tue, Mar 24, 2009 at 10:00 AM, Amanda Walker  wrote:

> 2009/3/24 John Abd-El-Malek :
> > Right, this is used so that if the user starts Chrome a second time, it
> > tells the currently running exe to open a new tab.  This is the standard
> way
> > of doing it on Windows, but I don't know how Mac/Linux apps enforce
> > single-instance semantics.  We should first figure out if this code is
> > needed before porting it..
>
> Mac OS X handles this via the UI--if you try to launch an
> already-running application through the Finder, Dock, etc., the
> already running instance is brought to the front.  While nothing in
> the underlying OS enforces single-instance semantics, the only way to
> get multiple instances within a single user session is to open a
> command line and explicitly launch them (or do the equivalent from
> another program or script).  Additional instances can of course be
> launched in other user sessions simply by switching to another session
> and launching the application normally.
>
> It's not at all clear to me that we need to explicitly filter out
> multiple instances on the Mac; if we do, we will need to scope such
> filtering to a single user session, which will require using
> Mac-specific APIs.  I would suggest that we postpone this until and
> unless we find a demonstrated need for it.


A lot of the code that touches databases/files in the user-data-dir assume
they're the only ones accessing them.  If multiple instances use the data,
there could be corruption.


>
>
> --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: [linux] GTK and multi-threading

[John Abd-El-Malek]

On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade  wrote:

>
> glib and x aren't thread-safe. To work around this our intention is to
> only call into them from the UI thread. Unfortunately we currently
> don't follow through on this.
>
> To query the clipboard the renderer sends a sync IPC call to the
> browser. The browser handles this call on the IO thread (in
> resource_message_filter.cc), where it calls into base::Clipboard. On
> linux this makes copious use of GTK+ functions (which in turn wrap
> calls to X). Oops! We'd like to be able to proxy off the calls to the
> UI thread, but I hear handling a sync IPC message on the UI thread is
> a nono. A couple options have been suggested, although neither is
> really all that appealing:
>
> a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
> the calls thread safe, but it does so by locking a process-wide mutex,
> which will block our UI thread's main loop.


Deadlock-wise, this is equivalent to just processing the message on the UI
thread.  So it's a no-go..


>
>
> b) Create a second UI thread with its own X connection. Adam suggested
> this one so he's better able than I to explain the implications.


I'm not familiar with X so I can't comment on this.  For background, the
problem we ran into on Windows is as follows:

-UI thread in browser process handles an input/paint/random Windows message,
which gets sent to a child window (plugin)
-browser UI thread effectively waits on the plugin UI thread
-plugin UI thread, as a result of the Windows message, ends up calling a JS
function on the page, or any other NPN_ function
-this results in a sync IPC message to the main renderer thread

If the main renderer thread then tries to do a sync IPC to the UI thread, a
cycle is reached and there's deadlock.

I don't know how child windows are implemented in Linux, and whether events
from parent->child will end up blocking the browser process' UI loop.  If
this doesn't happen, then we can come up with some sort of abstraction that
dispatches the messages on different thread for different platforms.  If it
has this same constraint, perhaps other things can be done on Linux (i.e.
will the sandbox prevent you from calling X functions?).


>
> Anyone with thoughts, advice, insight?
>
> p.s. So yes, webview copy-pasta is currently very dicey. You can
> always use the selection clipboard though, as long as you only care
> about text.
>
> -- Evan Stade
>
> >
>

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

[chromium-dev] Re: [linux] GTK and multi-threading

[John Abd-El-Malek]

On Fri, Apr 10, 2009 at 1:03 PM, Brett Wilson  wrote:

>
> On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade  wrote:
> > a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
> > the calls thread safe, but it does so by locking a process-wide mutex,
> > which will block our UI thread's main loop.
>
> I personally think this is OK. These calls "should" be on the UI
> thread and we'd put them there if we could. So having them on another
> thread blocking the UI thread seems equivalent. We just need to be
> careful to limit the locking to just that.


If in Linux plugin windows block the parent window (as they do on Windows),
then this will lead to a deadlock just as if the message was processed on
the UI thread.


>
> Brett
>
> >
>

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

[chromium-dev] Re: No more commits to third_party/WebKit

[John Abd-El-Malek]

Does this also
include  third_party\WebKit\WebKit\chromium\public\WebKitClient.h?  I'm
guessing not, since none of those files are in the WebKit repository yet,
but just want to double check.

On Fri, May 1, 2009 at 8:35 AM, Dimitri Glazkov wrote:

>
> We are very, very close to total unforking. In order to facilitate the
> completion of this process, please refrain from landing any changes in
> trunk/deps/third_party/WebKit. This holds true even if your patch is
> already approved upstream. So, to put it simply:
>
> NO MOAR THIRD_PARTY/WEBKIT COMMEETS.
>
> :DG<
>
> >
>

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

[chromium-dev] Re: Unforking: Canary Bot Lives!

[John Abd-El-Malek]

This is definitely awesome!
Too bad, I was just about to sign up to do the next n merges ;)

On Fri, May 1, 2009 at 2:38 PM, Dimitri Glazkov wrote:

>
> Hello all,
>
> This is kind of a momentous occasion. For the first time -- ever, our
> WebKit Canary bot (the one that pulls directly from WebKit upstream)
> has built successfully and was able to run tests:
>
>
> http://build.chromium.org/buildbot/waterfall.fyi/builders/Webkit%20(webkit.org)/builds/2937
>
> What does this mean? This means that our unforking efforts have
> finally paid off -- we can now pull directly from WebKit upstream!
>
> Congratulations to all of you who worked and helped during the last 7
> months! This was a long run, and despite various setbacks, we have
> reached this milestone.
>
> This also means that the daily merge as we know it is soon to be
> replaced with a less daunting activity -- WebKit gardening. I am
> working on the document to define what this will entail. Stay tuned.
>
> :DG<
>
> >
>

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

[chromium-dev] Re: What is the best way to file bugs against codereview.chromium.org?

[John Abd-El-Malek]

You can file a bug at http://code.google.com/p/rietveld/issues/list, and cc
me.

On Mon, May 11, 2009 at 9:36 AM, Darin Fisher  wrote:

> In some cases, I suspect I may need to file the issue against upstream
> Reitveld...  any guidance?
>
> Thanks,
> -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: CIA-bot on #chromium?

[John Abd-El-Malek]

One reason I don't find the IRC bot is as useful as subscribing to
chromium-checkins is that I'll miss checkins when I'm not looking at mirc or
when I get disconnected.  I find it useful to add gmail filters for
filepaths (i.e. src/chrome/plugin or render_messages_internal).
On Tue, May 12, 2009 at 2:01 PM, Peter Kasting wrote:

> On Tue, May 12, 2009 at 1:27 PM, Adam Barth  wrote:
>
>> Of course there are other ways of doing those things (like reading the
>> buildbot page or subscribing to the RSS), but I find IRC useful since
>> I'm half paying attention to it anyway.
>>
>
> OK, that makes some sense.  I think if IRC was the main/only mechanism we
> used to communicate I'd be more interested.  As-is I get most of this
> information from being CCed on all code reviews, so I know to speak up then
> if I see something exciting.
>
> 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: What is the best way to get document location from an NPAPI plugin?

[John Abd-El-Malek]

Are you sure this is broken?  Flash uses this so if it was broken, we would
have seen lots of sites fail.
On a debug build, I can see this working fine using about:ipc.

NPN_GetProperty is called on "location"
and the returned object is NPN_Invoke'd to call "toString"

On Mon, Jun 8, 2009 at 1:38 AM, vijay  wrote:

>
> Yeah. Here is what worked for us in the past: we issue a NPN_GetURL
> with "javascript:document.location" and the browser simply delivered
> the location via the standard NPP_NewStream, NPP_Write, etc. This
> works perfectly with mozilla/firefox. It also used to work the same
> exact way in Chrome 1.x so our code worked without any problems.
> However, with Chrome 2.0 (and the webkit underneath it), there were
> some changes and the javascript "results" are not being delivered via
> streams any more. Chrome/webkit is simply executing the javascript and
> ignoring the results. I can't say I agree with the rationale behind
> the change but it seems to have killed about the simplest way to get
> the document location :)
>
> On Jun 7, 11:29 pm, Adam Barth  wrote:
> > This turns out to be very trick to do securely.  I recommend studying
> > how Flash does this and doing *precisely* the same thing.
> >
> > Adam
> >
> > On Sun, Jun 7, 2009 at 10:57 PM, vijay wrote:
> >
> > > Preferably a browser-independent way would be great.
> >
> > > Thanks in advance,
> > > Vijay
> >
>

--~--~-~--~~~---~--~~
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: What is the best way to get document location from an NPAPI plugin?

[John Abd-El-Malek]

Perhaps try javascript:window.location.  We have a test for this in
npapi_uitest.cc: GetURL, and it uses window.location successfully.

On Mon, Jun 8, 2009 at 1:29 PM, vijay  wrote:

>
> Hmm... I'm not exactly sure how Flash works (are there any pointers
> to  this or do you figure this just by debugging Flash with Chrome?)
> but here's the specific problem I'm running into.
>
> We used to use NPN_GetURL with "javascript:document.location" as the
> URL. In the current implementation, after this script is executed in
> WebPluginImpl::ExecuteScript (in src/webkit/glue/webplugin_impl.cc),
> its checking the result value:
>
>  WebCore::ScriptValue result =
>  frame()->loader()->executeScript(script_str, popups_allowed);
>  WebCore::String script_result;
>  std::wstring wresult;
>  bool succ = false;
>  if (result.getString(script_result)) {
>succ = true;
>wresult = webkit_glue::StringToStdWString(script_result);
>  }
>
> For the above javascript I'm using, the result is false and I'm not
> sure why. Because of that, eventually in the
> PluginInstance::SendJavaScriptStream, no stream is being created at
> all. As I mentioned before this used to work with Chrome 1.x. I'm not
> sure why the javascript document.location does not correctly result in
> a string. I probably need to dig in more. Does this exact sequence
> work correctly for you?
>
> Thanks for all your time btw!
> Vijay
>
> On Jun 8, 11:15 am, John Abd-El-Malek  wrote:
> > Are you sure this is broken?  Flash uses this so if it was broken, we
> would
> > have seen lots of sites fail.
> > On a debug build, I can see this working fine using about:ipc.
> >
> > NPN_GetProperty is called on "location"
> > and the returned object is NPN_Invoke'd to call "toString"
> >
> > On Mon, Jun 8, 2009 at 1:38 AM, vijay  wrote:
> >
> > > Yeah. Here is what worked for us in the past: we issue a NPN_GetURL
> > > with "javascript:document.location" and the browser simply delivered
> > > the location via the standard NPP_NewStream, NPP_Write, etc. This
> > > works perfectly with mozilla/firefox. It also used to work the same
> > > exact way in Chrome 1.x so our code worked without any problems.
> > > However, with Chrome 2.0 (and the webkit underneath it), there were
> > > some changes and the javascript "results" are not being delivered via
> > > streams any more. Chrome/webkit is simply executing the javascript and
> > > ignoring the results. I can't say I agree with the rationale behind
> > > the change but it seems to have killed about the simplest way to get
> > > the document location :)
> >
> > > On Jun 7, 11:29 pm, Adam Barth  wrote:
> > > > This turns out to be very trick to do securely.  I recommend studying
> > > > how Flash does this and doing *precisely* the same thing.
> >
> > > > Adam
> >
> > > > On Sun, Jun 7, 2009 at 10:57 PM, vijay wrote:
> >
> > > > > Preferably a browser-independent way would be great.
> >
> > > > > Thanks in advance,
> > > > > Vijay
> >
>

--~--~-~--~~~---~--~~
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: What is the best way to get document location from an NPAPI plugin?

[John Abd-El-Malek]

BTW this is how Flash does it.

On Mon, Jun 8, 2009 at 7:47 PM, Adam Barth  wrote:

>
> On Mon, Jun 8, 2009 at 1:29 PM, vijay wrote:
> > We used to use NPN_GetURL with "javascript:document.location" as the
> > URL. In the current implementation, after this script is executed in
> > WebPluginImpl::ExecuteScript (in src/webkit/glue/webplugin_impl.cc),
> > its checking the result value:
>
> This is not a secure way to determine which page embedded the plug-in.
>  If you require this value to make a security decision, you should use
> a different approach.
>
> 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: What is the best way to get document location from an NPAPI plugin?

[John Abd-El-Malek]

I was referring to what I sniffed in IPC traffic:
NPN_GetProperty is called on "location"
and the returned object is NPN_Invoke'd to call "toString"

Isn't this what you mean?  If you observed something else, we should figure
out what the discrepancy is!

On Tue, Jun 9, 2009 at 3:36 PM, Adam Barth  wrote:

> Flash does something similar, but not *precisely* the same.  I stand
> by my statement that the below is insecure.
>
> Adam
>
>
> On Mon, Jun 8, 2009 at 8:08 PM, John Abd-El-Malek wrote:
> > BTW this is how Flash does it.
> >
> > On Mon, Jun 8, 2009 at 7:47 PM, Adam Barth  wrote:
> >>
> >> On Mon, Jun 8, 2009 at 1:29 PM, vijay wrote:
> >> > We used to use NPN_GetURL with "javascript:document.location" as the
> >> > URL. In the current implementation, after this script is executed in
> >> > WebPluginImpl::ExecuteScript (in src/webkit/glue/webplugin_impl.cc),
> >> > its checking the result value:
> >>
> >> This is not a secure way to determine which page embedded the plug-in.
> >>  If you require this value to make a security decision, you should use
> >> a different approach.
> >>
> >> 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: What is the best way to get document location from an NPAPI plugin?

[John Abd-El-Malek]

My question to you is what you see Flash doing.  I pasted below what I
observed by looking at their NPN calls.

On Tue, Jun 9, 2009 at 5:23 PM, Adam Barth  wrote:

> Here's a demo of an attack that works in Chrome:
>
> http://webblaze.org/abarth/tests/document-location/
>
> Flash does something similar, but not *precisely* what Vijay proposed.
>  This approach is extremely fragile.  If you require this value to
> make a security decision, I recommend a different approach (as I have
> now stated multiple times).
>
> Adam
>
>
> On Tue, Jun 9, 2009 at 1:16 AM, John Abd-El-Malek wrote:
> > I was referring to what I sniffed in IPC traffic:
> > NPN_GetProperty is called on "location"
> > and the returned object is NPN_Invoke'd to call "toString"
> > Isn't this what you mean?  If you observed something else, we should
> figure
> > out what the discrepancy is!
> > On Tue, Jun 9, 2009 at 3:36 PM, Adam Barth  wrote:
> >>
> >> Flash does something similar, but not *precisely* the same.  I stand
> >> by my statement that the below is insecure.
> >>
> >> Adam
> >>
> >>
> >> On Mon, Jun 8, 2009 at 8:08 PM, John Abd-El-Malek
> wrote:
> >> > BTW this is how Flash does it.
> >> >
> >> > On Mon, Jun 8, 2009 at 7:47 PM, Adam Barth 
> wrote:
> >> >>
> >> >> On Mon, Jun 8, 2009 at 1:29 PM, vijay wrote:
> >> >> > We used to use NPN_GetURL with "javascript:document.location" as
> the
> >> >> > URL. In the current implementation, after this script is executed
> in
> >> >> > WebPluginImpl::ExecuteScript (in
> src/webkit/glue/webplugin_impl.cc),
> >> >> > its checking the result value:
> >> >>
> >> >> This is not a secure way to determine which page embedded the
> plug-in.
> >> >>  If you require this value to make a security decision, you should
> use
> >> >> a different approach.
> >> >>
> >> >> 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: What is the best way to get document location from an NPAPI plugin?

[John Abd-El-Malek]

On Wed, Jun 10, 2009 at 12:30 AM, Adam Barth  wrote:

> I'm hesitant to say because I don't want Vijay to treat this as advice
> on the "right" way to determine which page included his plug-in.  The
> approach of trying to read the document's location via JavaScript is
> fundamentally insecure.


I think if we tell someone not to do something because it's insecure, we
need to at least tell them about the most secure way we know about, even if
it's not perfect.  IMO unless Vijay's plugin's is on a large number of
machines, it won't be a an attractive target for attackers.


>
>
> That being said, my understanding is that Flash examines the location
> property of the window object and not the document object.  Note that
> simply making this change to the below is *not* sufficient for
> security.


Ok, this matches what I observed and wrote below..


>
>
> Adam
>
>
> On Tue, Jun 9, 2009 at 1:30 AM, John Abd-El-Malek wrote:
> > My question to you is what you see Flash doing.  I pasted below what I
> > observed by looking at their NPN calls.
> >
> > On Tue, Jun 9, 2009 at 5:23 PM, Adam Barth  wrote:
> >>
> >> Here's a demo of an attack that works in Chrome:
> >>
> >> http://webblaze.org/abarth/tests/document-location/
> >>
> >> Flash does something similar, but not *precisely* what Vijay proposed.
> >>  This approach is extremely fragile.  If you require this value to
> >> make a security decision, I recommend a different approach (as I have
> >> now stated multiple times).
> >>
> >> Adam
> >>
> >>
> >> On Tue, Jun 9, 2009 at 1:16 AM, John Abd-El-Malek
> wrote:
> >> > I was referring to what I sniffed in IPC traffic:
> >> > NPN_GetProperty is called on "location"
> >> > and the returned object is NPN_Invoke'd to call "toString"
> >> > Isn't this what you mean?  If you observed something else, we should
> >> > figure
> >> > out what the discrepancy is!
> >> > On Tue, Jun 9, 2009 at 3:36 PM, Adam Barth 
> wrote:
> >> >>
> >> >> Flash does something similar, but not *precisely* the same.  I stand
> >> >> by my statement that the below is insecure.
> >> >>
> >> >> Adam
> >> >>
> >> >>
> >> >> On Mon, Jun 8, 2009 at 8:08 PM, John Abd-El-Malek
> >> >> wrote:
> >> >> > BTW this is how Flash does it.
> >> >> >
> >> >> > On Mon, Jun 8, 2009 at 7:47 PM, Adam Barth 
> >> >> > wrote:
> >> >> >>
> >> >> >> On Mon, Jun 8, 2009 at 1:29 PM, vijay wrote:
> >> >> >> > We used to use NPN_GetURL with "javascript:document.location" as
> >> >> >> > the
> >> >> >> > URL. In the current implementation, after this script is
> executed
> >> >> >> > in
> >> >> >> > WebPluginImpl::ExecuteScript (in
> >> >> >> > src/webkit/glue/webplugin_impl.cc),
> >> >> >> > its checking the result value:
> >> >> >>
> >> >> >> This is not a secure way to determine which page embedded the
> >> >> >> plug-in.
> >> >> >>  If you require this value to make a security decision, you should
> >> >> >> use
> >> >> >> a different approach.
> >> >> >>
> >> >> >> 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: Renderer Process and Browser Process

[John Abd-El-Malek]

On Wed, Jun 10, 2009 at 11:48 AM, Meryl Silverburgh <
silverburgh.me...@gmail.com> wrote:

>
> From this document, it talks about Messaging between
>
> http://dev.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome
>
> Can you please help me understand what is the Message Flow for an Alert
> Dialog?
>
> like in this case:
>  function f1() { var a = 1; alert("hello"); a = 2;};
> f1(); 
>
> I assume it is like this, please correct me if i am wrong:
> 1. Browser Process downloads the test page
> 2. Renderer Process gets the html source, parses the html and have v8
> executes script node
> 3. v8 pauses at 'alert' call, sends a message to Browser Process to
> pop up the alert dialog and Render Process blocked till it receives
> message from Browser.
> 4. Browser Process shows the alert dialog with the right message (in
> this case 'hello')
> 5. When user clicks 'Okay', browser process sends a message back to
> Renderer Process and v8 continues execute the rest of the Script node.
>
> Is this correct?


Yep this is pretty much what happens.  For more details, search
for ViewHostMsg_RunJavaScriptMessage


>
>
> Thank you for any clarificaiton.
>
> >
>

--~--~-~--~~~---~--~~
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: Is there any logging to print out messaging between Browser and Renderer

[John Abd-El-Malek]

You can use the IPC logger, which is enabled in debug builds only by
default.  about:ipc
On Windows this will popup a graphical display which also allows you to
filter for specific messages.  On Linux, you need to set
the CHROME_IPC_LOGGING environment variable.

On Wed, Jun 10, 2009 at 7:24 PM, Meryl Silverburgh <
silverburgh.me...@gmail.com> wrote:

>
> Hi,
>
> Is there any logging to print out messaging between Browser and
> Renderer processes?
> If yes, can you please tell me how to enable it? And where does the log go?
>
> Thank you.
>
> >
>

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

[chromium-dev] Re: Is there any logging to print out messaging between Browser and Renderer

[John Abd-El-Malek]

about:ipc is only implemented on Windows.
For Mac/Linux, you need to set the CHROME_IPC_LOGGING environment variable.
 All the messages will be dumped to stderr.

On Wed, Jun 10, 2009 at 8:34 PM, Meryl Silverburgh <
silverburgh.me...@gmail.com> wrote:

>
> Thank you. I try and successfully build chromium on MacOS using XCode.
> Then I do a 'build and Go (debug)'.
>
> In one tab , I load www.google.com and then do a search for 'test'.
> In another tab, I enter 'about:ipc' but it shows nothing.
>
> Am I missing something?
>
> Thank you.
>
> On Wed, Jun 10, 2009 at 8:02 PM, Eric Roman wrote:
> > Even better, use a DEBUG build of chromium and navigate to "about:ipc".
> > This opens a window that logs all of the IPC messages being made.
> >
> > On Wed, Jun 10, 2009 at 7:34 PM, Mohamed Mansour
> wrote:
> >> You can pass in --log-level=N to the command line, where N is
> >> 0 = INFO
> >> 1 = WARNING
> >> 2 = ERROR
> >> 3 = FATAL
> >> The default login level is set to 1 which is WARNING.
> >>
> >> -- Mohamed Mansour
> >>
> >>
> >> On Wed, Jun 10, 2009 at 10:24 PM, Meryl Silverburgh
> >>  wrote:
> >>>
> >>> Hi,
> >>>
> >>> Is there any logging to print out messaging between Browser and
> >>> Renderer processes?
> >>> If yes, can you please tell me how to enable it? And where does the log
> >>> go?
> >>>
> >>> Thank you.
> >>>
> >>>
> >>
> >>
> >> >>
> >>
> >
>
> >
>

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

[chromium-dev] Re: Renderer Process and Browser Process

[John Abd-El-Malek]

On Wed, Jun 10, 2009 at 10:19 PM, Meryl Silverburgh <
silverburgh.me...@gmail.com> wrote:

> On Wed, Jun 10, 2009 at 12:18 PM, John Abd-El-Malek
> wrote:
> >
> >
> > On Wed, Jun 10, 2009 at 11:48 AM, Meryl Silverburgh
> >  wrote:
> >>
> >> From this document, it talks about Messaging between
> >>
> >>
> http://dev.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome
> >>
> >> Can you please help me understand what is the Message Flow for an Alert
> >> Dialog?
> >>
> >> like in this case:
> >>  function f1() { var a = 1; alert("hello"); a = 2;};
> >> f1(); 
> >>
> >> I assume it is like this, please correct me if i am wrong:
> >> 1. Browser Process downloads the test page
> >> 2. Renderer Process gets the html source, parses the html and have v8
> >> executes script node
> >> 3. v8 pauses at 'alert' call, sends a message to Browser Process to
> >> pop up the alert dialog and Render Process blocked till it receives
> >> message from Browser.
> >> 4. Browser Process shows the alert dialog with the right message (in
> >> this case 'hello')
> >> 5. When user clicks 'Okay', browser process sends a message back to
> >> Renderer Process and v8 continues execute the rest of the Script node.
> >>
> >> Is this correct?
> >
> > Yep this is pretty much what happens.  For more details, search
> > for ViewHostMsg_RunJavaScriptMessage
> >
>
> Thank you. John.
>
> I think this method is Render process to send a message to Browser
> process to pop up an alert dialog.
> bool RenderView::RunJavaScriptMessage(int type,
>  const std::wstring& message,
>  const std::wstring& default_value,
>  const GURL& frame_url,
>  std::wstring* result)
>
> that calls:
> bool Channel::Send(Message* message);
> and then
> bool Channel::ChannelImpl::ProcessOutgoingMessages()
>
> My question is how the Render process being blocked after it sends the
> message to Browser process, which one is a blocking calls or which one
> calls a blocking method?
> And how it will resume when Browser process replys a message? How
> Render is being resumed (which method does that)?


This is done automatically since ViewHostMsg_RunJavaScriptMessage is
declared as a synchronous IPC message (see render_messages_internal.h).

The code that does the waiting until the browser replies is
IPC::SyncChannel.  See Send() in ipc_sync_channel.cc.

>
>
> Thank you.
>
>
> >>
> >> Thank you for any clarificaiton.
> >>
> >> > >>
> >
> >
>

--~--~-~--~~~---~--~~
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: OWNER files

[John Abd-El-Malek]

Just wanted to give a friendly warning, the same I gave to Nirnimesh, that
we don't want to do any extra processing in Rietveld.  Otherwise it'll lead
to the 500s that people (don't) miss.

On Fri, Jun 12, 2009 at 12:40 PM, Marc-Antoine Ruel wrote:

>
> -> chromium-dev
>
> On Fri, Jun 12, 2009 at 1:18 PM, Jim Roskind wrote:
> > I really like Erik's suggestion. Automatic assistance, without having to
> > learn to use a pile of new tools, and manually enter file names (yet
> again)
> > in svn blame, etc.
>
> Patches to Rietveld are welcome, but implementing this would be a
> significant effort.
>
>
> > It would be very sweet if, whenever I did a gcl upload, and then looked
> at
> > my uploaded changes, that I could automatically see who had provided
> (most
> > recently) the lines I was editing, and/or who was hacking recently on
> each
> > file.
>
> Patches to Rietveld are welcome, but implementing this would be a
> significant effort. (e.g. a svn blame beside the side-by-side diff
> view). Instead, run this script:
>
>  CUT HERE ---
> #!/bin/python
> # Copyright (c) 2009 Marc-Antoine Ruel. No rights reserved. :)
> import re
> import subprocess
>
> __author__ = 'mar...@chromium.org'
>
> def SVN(args):
>  return subprocess.Popen(['svn'] + args,
>  stdout=subprocess.PIPE).communicate()[0].splitlines()
>
> files = SVN(['status'])
> # Filter unwanted files.
> files = filter(lambda x: x[0] not in ('?', 'D', 'A', 'C'), files)
> files = map(lambda x: x[7:].strip(), files)
>
> for i in files:
>  hunks = []
>  # Strip the header.
>  diff = SVN(['diff', i])[4:]
>  # Parse hunks.
>  for line in diff:
>if line[0] in (' ', '+', '-', '\\'):
>  hunks[-1].append(line)
>elif line[0] == '@':
>  hunks.append([line])
>  if not hunks:
>continue
>  # Grab only the attribution, not the content.
>  f = lambda x: re.match(r"^ (\d+ [...@]+).*$", x).group(1) + ' '
>  blame = map(f, SVN(['blame', i]))
>
>  print i
>  for hunk in hunks:
>print hunk[0]
>start_line = int(re.match(r"@@ -(\d+),.*", hunk[0]).group(1))
>for line in hunk[1:]:
>  if line[0] in (' ', '-'):
>print blame[start_line] + line
>start_line += 1
>  else:
>print (' ' * len(blame[start_line])) + line
>print ''
> --- CUT HERE ---
>
> You have to set your console to 100+ column to have this script
> usable. Alt-space, Properties (or defaults), Config.
>
>
> > It would be very nice for each file I edited, if I could see a list of
> the
> > most recent folks to have committed to that file (head of svn log)
> and
> > perhaps links to change lists.  That could give me clues about who did
> > reviews last time ;-).
>
> #!/bin/sh
> for i in $(svn status | grep -v '^A' | cut -c 9-); do svn log -q
> --limit 2 $i; done | grep r | uniq | sort -r
>
>
> Now back to work...
>
> 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: changing chrome_exe to chrome, converting chrome.exe to gyp

[John Abd-El-Malek]

+1 this is affecting a lot of people.

On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx  wrote:

>
> I notice that when I load chrome.sln and do a build, not all the
> dependencies are built anymore. For instance, theme_dll isn't built
> (not listed in the proj deps), is this expected?
>
> On Jun 18, 12:38 am, Steven Knight  wrote:
> > Okay, it looks like this change is sticking, at least until someone
> > discovers Yet Another Unintended Side Effect.  So heed the warnings in
> the
> > previous message, quoted below.
> > Git users on Linux:  this requires an update to gyp to work properly, so
> > make sure you "gclient sync" after you "git pull", or whatever the right
> > combination of commands is.  If you see Python stack traces from gyp
> > accompanied by complaints about looking up a "Dir as a File", make sure
> the
> > tools/gyp subdirectory is at r521.
> >
> > --SK
> >
> >
> >
> > On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight 
> wrote:
> > > Heads up, again, dept.:
> > > In the next in an ongoing series of attempts to convert chrome.exe to
> gyp,
> > > I'm going to (try to) land two changes now that you should be aware of:
> >
> > > 1)  convert the 'app' target in the chrome.gyp file to being named
> > > 'chrome'. 2)  actually convert the 'chrome_exe' project to using a
> > > gyp-generated chrome.vcproj file, instead of the checked-in one.
> >
> > > When the first change lands, Mac developers will need to look for the
> new
> > > 'chrome' target instead of 'app', and Linux developers who have been
> typing
> > > 'hammer app' (or 'make app' if you're using the Makefile generator)
> will
> > > need to type 'hammer chrome' ('make chrome').  The default behaviors of
> > > building everything should be unaffected.
> >
> > > When the second change lands, Visual Studio users will need to use the
> > > 'chrome' project, instead of the former 'chrome_exe' project.  NOTE:
> > >  because the underlying .vcproj file will be completely different, any
> local
> > > settings you've configured into the old 'chrome_exe' project will NOT
> be
> > > transferred to the new 'chrome' project.  You'll have to make a note of
> any
> > > custom settings before updating and re-apply them to the new 'chrome'
> > > project.
> >
> > > There's always the chance that one or both of these changes will have
> to be
> > > reverted if unintended side effects pop up.  I'll send out confirming
> email
> > > with the final state of things.
> >
> > > --SK
> >
>

--~--~-~--~~~---~--~~
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: changing chrome_exe to chrome, converting chrome.exe to gyp

[John Abd-El-Malek]

Another missing dependency, in the runtime sense, is unit_tests
on test_chrome_plugin.  Right now if you just compile that project from a
clean build, it'll crash.

On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek  wrote:

> +1 this is affecting a lot of people.
>
>
> On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx wrote:
>
>>
>> I notice that when I load chrome.sln and do a build, not all the
>> dependencies are built anymore. For instance, theme_dll isn't built
>> (not listed in the proj deps), is this expected?
>>
>> On Jun 18, 12:38 am, Steven Knight  wrote:
>> > Okay, it looks like this change is sticking, at least until someone
>> > discovers Yet Another Unintended Side Effect.  So heed the warnings in
>> the
>> > previous message, quoted below.
>> > Git users on Linux:  this requires an update to gyp to work properly, so
>> > make sure you "gclient sync" after you "git pull", or whatever the right
>> > combination of commands is.  If you see Python stack traces from gyp
>> > accompanied by complaints about looking up a "Dir as a File", make sure
>> the
>> > tools/gyp subdirectory is at r521.
>> >
>> > --SK
>> >
>> >
>> >
>> > On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight 
>> wrote:
>> > > Heads up, again, dept.:
>> > > In the next in an ongoing series of attempts to convert chrome.exe to
>> gyp,
>> > > I'm going to (try to) land two changes now that you should be aware
>> of:
>> >
>> > > 1)  convert the 'app' target in the chrome.gyp file to being named
>> > > 'chrome'. 2)  actually convert the 'chrome_exe' project to using a
>> > > gyp-generated chrome.vcproj file, instead of the checked-in one.
>> >
>> > > When the first change lands, Mac developers will need to look for the
>> new
>> > > 'chrome' target instead of 'app', and Linux developers who have been
>> typing
>> > > 'hammer app' (or 'make app' if you're using the Makefile generator)
>> will
>> > > need to type 'hammer chrome' ('make chrome').  The default behaviors
>> of
>> > > building everything should be unaffected.
>> >
>> > > When the second change lands, Visual Studio users will need to use the
>> > > 'chrome' project, instead of the former 'chrome_exe' project.  NOTE:
>> > >  because the underlying .vcproj file will be completely different, any
>> local
>> > > settings you've configured into the old 'chrome_exe' project will NOT
>> be
>> > > transferred to the new 'chrome' project.  You'll have to make a note
>> of any
>> > > custom settings before updating and re-apply them to the new 'chrome'
>> > > project.
>> >
>> > > There's always the chance that one or both of these changes will have
>> to be
>> > > reverted if unintended side effects pop up.  I'll send out confirming
>> email
>> > > with the final state of things.
>> >
>> > > --SK
>> >>
>>
>

--~--~-~--~~~---~--~~
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: changing chrome_exe to chrome, converting chrome.exe to gyp

[John Abd-El-Malek]

Yeah it happened to me before as well, I just figured I'd complain now..
 Note another missing dependency is on crash_service.exe
, npapi_layout_test_plugin, and npapi_test_plugin

On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow  wrote:

> I actually had this problem _before_ this change.  Guess I should have
> brought it up, but I figured it was just something funny on my system.
>
> On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek wrote:
>
>> +1 this is affecting a lot of people.
>>
>>
>> On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx wrote:
>>
>>>
>>> I notice that when I load chrome.sln and do a build, not all the
>>> dependencies are built anymore. For instance, theme_dll isn't built
>>> (not listed in the proj deps), is this expected?
>>>
>>> On Jun 18, 12:38 am, Steven Knight  wrote:
>>> > Okay, it looks like this change is sticking, at least until someone
>>> > discovers Yet Another Unintended Side Effect.  So heed the warnings in
>>> the
>>> > previous message, quoted below.
>>> > Git users on Linux:  this requires an update to gyp to work properly,
>>> so
>>> > make sure you "gclient sync" after you "git pull", or whatever the
>>> right
>>> > combination of commands is.  If you see Python stack traces from gyp
>>> > accompanied by complaints about looking up a "Dir as a File", make sure
>>> the
>>> > tools/gyp subdirectory is at r521.
>>> >
>>> > --SK
>>> >
>>> >
>>> >
>>> > On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight 
>>> wrote:
>>> > > Heads up, again, dept.:
>>> > > In the next in an ongoing series of attempts to convert chrome.exe to
>>> gyp,
>>> > > I'm going to (try to) land two changes now that you should be aware
>>> of:
>>> >
>>> > > 1)  convert the 'app' target in the chrome.gyp file to being named
>>> > > 'chrome'. 2)  actually convert the 'chrome_exe' project to using a
>>> > > gyp-generated chrome.vcproj file, instead of the checked-in one.
>>> >
>>> > > When the first change lands, Mac developers will need to look for the
>>> new
>>> > > 'chrome' target instead of 'app', and Linux developers who have been
>>> typing
>>> > > 'hammer app' (or 'make app' if you're using the Makefile generator)
>>> will
>>> > > need to type 'hammer chrome' ('make chrome').  The default behaviors
>>> of
>>> > > building everything should be unaffected.
>>> >
>>> > > When the second change lands, Visual Studio users will need to use
>>> the
>>> > > 'chrome' project, instead of the former 'chrome_exe' project.  NOTE:
>>> > >  because the underlying .vcproj file will be completely different,
>>> any local
>>> > > settings you've configured into the old 'chrome_exe' project will NOT
>>> be
>>> > > transferred to the new 'chrome' project.  You'll have to make a note
>>> of any
>>> > > custom settings before updating and re-apply them to the new 'chrome'
>>> > > project.
>>> >
>>> > > There's always the chance that one or both of these changes will have
>>> to be
>>> > > reverted if unintended side effects pop up.  I'll send out confirming
>>> email
>>> > > with the final state of things.
>>> >
>>> > > --SK
>>>
>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: changing chrome_exe to chrome, converting chrome.exe to gyp

[John Abd-El-Malek]

On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek  wrote:

> Yeah it happened to me before as well, I just figured I'd complain now..
>  Note another missing dependency is on crash_service.exe
> , npapi_layout_test_plugin, and npapi_test_plugin


btw just to be clear, these are missing dependencies on ui_tests.


>
>
> On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow  wrote:
>
>> I actually had this problem _before_ this change.  Guess I should have
>> brought it up, but I figured it was just something funny on my system.
>>
>> On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek wrote:
>>
>>> +1 this is affecting a lot of people.
>>>
>>>
>>> On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx wrote:
>>>
>>>>
>>>> I notice that when I load chrome.sln and do a build, not all the
>>>> dependencies are built anymore. For instance, theme_dll isn't built
>>>> (not listed in the proj deps), is this expected?
>>>>
>>>> On Jun 18, 12:38 am, Steven Knight  wrote:
>>>> > Okay, it looks like this change is sticking, at least until someone
>>>> > discovers Yet Another Unintended Side Effect.  So heed the warnings in
>>>> the
>>>> > previous message, quoted below.
>>>> > Git users on Linux:  this requires an update to gyp to work properly,
>>>> so
>>>> > make sure you "gclient sync" after you "git pull", or whatever the
>>>> right
>>>> > combination of commands is.  If you see Python stack traces from gyp
>>>> > accompanied by complaints about looking up a "Dir as a File", make
>>>> sure the
>>>> > tools/gyp subdirectory is at r521.
>>>> >
>>>> > --SK
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight 
>>>> wrote:
>>>> > > Heads up, again, dept.:
>>>> > > In the next in an ongoing series of attempts to convert chrome.exe
>>>> to gyp,
>>>> > > I'm going to (try to) land two changes now that you should be aware
>>>> of:
>>>> >
>>>> > > 1)  convert the 'app' target in the chrome.gyp file to being named
>>>> > > 'chrome'. 2)  actually convert the 'chrome_exe' project to using a
>>>> > > gyp-generated chrome.vcproj file, instead of the checked-in one.
>>>> >
>>>> > > When the first change lands, Mac developers will need to look for
>>>> the new
>>>> > > 'chrome' target instead of 'app', and Linux developers who have been
>>>> typing
>>>> > > 'hammer app' (or 'make app' if you're using the Makefile generator)
>>>> will
>>>> > > need to type 'hammer chrome' ('make chrome').  The default behaviors
>>>> of
>>>> > > building everything should be unaffected.
>>>> >
>>>> > > When the second change lands, Visual Studio users will need to use
>>>> the
>>>> > > 'chrome' project, instead of the former 'chrome_exe' project.  NOTE:
>>>> > >  because the underlying .vcproj file will be completely different,
>>>> any local
>>>> > > settings you've configured into the old 'chrome_exe' project will
>>>> NOT be
>>>> > > transferred to the new 'chrome' project.  You'll have to make a note
>>>> of any
>>>> > > custom settings before updating and re-apply them to the new
>>>> 'chrome'
>>>> > > project.
>>>> >
>>>> > > There's always the chance that one or both of these changes will
>>>> have to be
>>>> > > reverted if unintended side effects pop up.  I'll send out
>>>> confirming email
>>>> > > with the final state of things.
>>>> >
>>>> > > --SK
>>>>
>>>>
>>>
>>> >>>
>>>
>>
>

--~--~-~--~~~---~--~~
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: changing chrome_exe to chrome, converting chrome.exe to gyp

[John Abd-El-Malek]

I'll add the dependencies I was complaining about :)

On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight  wrote:

> All--
> When you notice missing dependencies, pleased add them to the necessary
> .gyp file(s)!  One of the main reasons we've been trying to land all this
> stuff is so that tracking down all these pieces isn't single-threaded
> through one person (or two).  If you're not comfortable making the change
> yourself, then please file a bug so the dependency problems get tracked and
> fixed in an organized fashion.
>
> Re:  unnecessary rebuilds:  please file bugs so they don't get lost.
>  Please include the target you were building, and the the libs/targets that
> were rebuilt unnecessarily.  You don't have to be exhaustive about the list,
> it's more important here that at least some information gets collected and
> doesn't languish on the ML or get dropped on the floor.
>
> I'm working on a buildbot script that will test for missing dependencies by
> building every target from scratch individually, and will then test for
> unnecessary rebuilds by rebuilding each target after no updates.  That's
> been taking a back seat to just getting the conversion completed, but I've
> accelerated my work on it as we wind down to the last few targets.
>
> --SK
>
>
> On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek wrote:
>
>>
>>
>> On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek wrote:
>>
>>> Yeah it happened to me before as well, I just figured I'd complain now..
>>>  Note another missing dependency is on crash_service.exe
>>> , npapi_layout_test_plugin, and npapi_test_plugin
>>
>>
>> btw just to be clear, these are missing dependencies on ui_tests.
>>
>>
>>>
>>>
>>> On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow  wrote:
>>>
>>>> I actually had this problem _before_ this change.  Guess I should have
>>>> brought it up, but I figured it was just something funny on my system.
>>>>
>>>> On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek 
>>>> wrote:
>>>>
>>>>> +1 this is affecting a lot of people.
>>>>>
>>>>>
>>>>> On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> I notice that when I load chrome.sln and do a build, not all the
>>>>>> dependencies are built anymore. For instance, theme_dll isn't built
>>>>>> (not listed in the proj deps), is this expected?
>>>>>>
>>>>>> On Jun 18, 12:38 am, Steven Knight  wrote:
>>>>>> > Okay, it looks like this change is sticking, at least until someone
>>>>>> > discovers Yet Another Unintended Side Effect.  So heed the warnings
>>>>>> in the
>>>>>> > previous message, quoted below.
>>>>>> > Git users on Linux:  this requires an update to gyp to work
>>>>>> properly, so
>>>>>> > make sure you "gclient sync" after you "git pull", or whatever the
>>>>>> right
>>>>>> > combination of commands is.  If you see Python stack traces from gyp
>>>>>> > accompanied by complaints about looking up a "Dir as a File", make
>>>>>> sure the
>>>>>> > tools/gyp subdirectory is at r521.
>>>>>> >
>>>>>> > --SK
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight 
>>>>>> wrote:
>>>>>> > > Heads up, again, dept.:
>>>>>> > > In the next in an ongoing series of attempts to convert chrome.exe
>>>>>> to gyp,
>>>>>> > > I'm going to (try to) land two changes now that you should be
>>>>>> aware of:
>>>>>> >
>>>>>> > > 1)  convert the 'app' target in the chrome.gyp file to being named
>>>>>> > > 'chrome'. 2)  actually convert the 'chrome_exe' project to using a
>>>>>> > > gyp-generated chrome.vcproj file, instead of the checked-in one.
>>>>>> >
>>>>>> > > When the first change lands, Mac developers will need to look for
>>>>>> the new
>>>>>> > > 'chrome' target instead of 

[chromium-dev] Re: HTML5 Web Socket design doc

[John Abd-El-Malek]

On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:

> Hi,
>
> yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
> design docs
>
>  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
>  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm


Regarding the "WebKit API", note that no WebCore data types can be used
there.  So you'll need to create wrapper classes that use data types
available in the WebKit API (i.e. WebUrl, WebString).


> 
>
> We'll send WebKit part to webkit-dev, if it looks ok.
> We'd welcome if you could give us feedback on our design docs.
>
> Thanks,
> ukai
>
> >
>

--~--~-~--~~~---~--~~
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: HTML5 Web Socket design doc

[John Abd-El-Malek]

2009/6/24 Drew Wilson 

> BTW, I checked in with IanH - it sounds like WebSockets are also on the
> Worker roadmap, so that's something to keep in mind while you iterate on
> your design.
> +1 to avoiding WebCore/loader, but also +1 to refactoring to enable as much
> common code as possible cross-platform - I'm looking at the Chromium worker
> code now, and there's a chunk of duplicated logic from the WebKit worker
> implementation, which is a bit of a maintenance headache.
>

I'm curious, which parts of the code are you talking about?


>
> -atw
>
> 2009/6/24 Michael Nordman 
>
> Only skimmed thusfar as well... but from what i've seen, looks reasonable
>> to me.
>> * A version of the diagram you have in the chrome doc would be nice in the
>> webkit doc too.
>>
>> * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
>> is a refcounted object and this design looks modeled off of that (which may
>> be why you've spec'd it this way). Unless your design actually needs
>> refcounting on this class, you may be able to simplify things without it.
>> From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
>>
>> > should we reuse WebCore/loader instead of adding new component?
>>
>> The loader is somewhat notorious for its complexity. I think you've made a
>> good decision to keep this out of there and to design the websocket system
>> in a good clean modular fashion.
>>
>> > which component is responsible of web socket protocol framing?  This
>> design assumes WebSocketChannel serializes/deserializes message in web
>> socket frame.
>>
>> Since WebSocketHandle is inevitably going to be platform specific, any
>> code you want to be shared code shouldn't be slated for that class. To the
>> extent the 'web socket protocol framing' can be done indepedent of the
>> 'platform' socket handle (which it looks like it can be), it would be a good
>> thing to put it in WebSocketChannel so its shared core common code goodness.
>>
>> > Regarding the "WebKit API", note that no WebCore data types can be used
>> there. So you'll need to create wrapper classes.
>>
>> I see you have speced WebKit:: wrapper classes with the same name as the
>> corresponding WebCore:: classes.
>>
>> I wonder if that same naming could be confusingt? The naming convention
>> darin has been employing would be WebKit::WebWebSocketHandle, which
>> certainly looks odd.
>>
>> * virtual void didReceiveData(const String& msg) {}
>>
>> Maybe rename this to channel client api to didReceiveMessage() to help
>> distinguish between raw 'data' being surface by the 'handle', and complete
>> 'messages' being surfaced by the 'channel'.
>>
>>
>> On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) > > wrote:
>>
>>> Hi,
>>>
>>> yuzo, tyoshino and I start working to implement HTML5 Web Socket and
>>> write design docs
>>>
>>>  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
>>>  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
>>>
>>> We'll send WebKit part to webkit-dev, if it looks ok.
>>> We'd welcome if you could give us feedback on our design docs.
>>>
>>> Thanks,
>>> ukai
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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: HTML5 Web Socket design doc

[John Abd-El-Malek]

2009/6/24 Drew Wilson 

> I'm looking at the code in webworker_impl.cc and webworkerclient_impl.cpp,
> vs the code in WebCore/workers/WorkerMessagingProxy.cpp.
> As an example:
>
> Chrome version:
> void WebWorkerClientImpl::postMessageToWorkerContext(
> const WebCore::String& message) {
>   // Worker.terminate() could be called from JS before the context is
> started.
>   if (asked_to_terminate_)
> return;
>
>   ++unconfirmed_message_count_;
>
>   if (!WTF::isMainThread()) {
> WebWorkerImpl::DispatchTaskToMainThread(
> WebCore::createCallbackTask(&PostMessageToWorkerContextTask, this,
> message));
> return;
>   }
>   webworker_->postMessageToWorkerContext(
>   webkit_glue::StringToWebString(message));
> }
>
> WebKit version:
> void WorkerMessagingProxy::postMessageToWorkerContext(const String&
> message)
> {
> if (m_askedToTerminate)
> return;
>
> if (m_workerThread) {
> ++m_unconfirmedMessageCount;
>
>  
> m_workerThread->runLoop().postTask(MessageWorkerContextTask::create(message));
> } else
>
>  m_queuedEarlyTasks.append(MessageWorkerContextTask::create(message));
> }
>
>
> The duplications become even more apparent as I evolve these APIs to
> support MessagePorts. I'm just seeing similar logic (checking for terminated
> tasks, tracking undelivered messages, and soon disentangling message ports
> and dealing with errors) that has to be updated in parallel in both trees.
>
> Not a big deal, either way. Now that the Chrome implementation is pretty
> stable, we might want to refactor the WorkerProxy APIs to see if we can
> share more code across implementations.
>

It'd be great of course if unconfirmed_message_count_
and asked_to_terminate_ weren't needed, but it's used to avoid a large
number of cross process calls (the equivalent variables in WebKit would be
in a different process).  Almost all the rest of the file is converting back
and forth between WebCore and Chrome data types in the glue layer, which is
a necessary pain.


> -atw
>
> 2009/6/24 John Abd-El-Malek 
>
>
>>
>> 2009/6/24 Drew Wilson 
>>
>>> BTW, I checked in with IanH - it sounds like WebSockets are also on the
>>> Worker roadmap, so that's something to keep in mind while you iterate on
>>> your design.
>>> +1 to avoiding WebCore/loader, but also +1 to refactoring to enable as
>>> much common code as possible cross-platform - I'm looking at the Chromium
>>> worker code now, and there's a chunk of duplicated logic from the WebKit
>>> worker implementation, which is a bit of a maintenance headache.
>>>
>>
>> I'm curious, which parts of the code are you talking about?
>>
>>
>>>
>>> -atw
>>>
>>> 2009/6/24 Michael Nordman 
>>>
>>> Only skimmed thusfar as well... but from what i've seen, looks reasonable
>>>> to me.
>>>> * A version of the diagram you have in the chrome doc would be nice in
>>>> the webkit doc too.
>>>>
>>>> * Does WebSocketHandle really need to be refcounted. I know
>>>> ResourceHandle is a refcounted object and this design looks modeled off of
>>>> that (which may be why you've spec'd it this way). Unless your design
>>>> actually needs refcounting on this class, you may be able to simplify 
>>>> things
>>>> without it. From the looks of it, WebSocketChannel 'owns' the
>>>> WebSocketHandle.
>>>>
>>>> > should we reuse WebCore/loader instead of adding new component?
>>>>
>>>> The loader is somewhat notorious for its complexity. I think you've made
>>>> a good decision to keep this out of there and to design the websocket 
>>>> system
>>>> in a good clean modular fashion.
>>>>
>>>> > which component is responsible of web socket protocol framing?  This
>>>> design assumes WebSocketChannel serializes/deserializes message in web
>>>> socket frame.
>>>>
>>>> Since WebSocketHandle is inevitably going to be platform specific, any
>>>> code you want to be shared code shouldn't be slated for that class. To the
>>>> extent the 'web socket protocol framing' can be done indepedent of the
>>>> 'platform' socket handle (which it looks like it can be), it would be a 
>>>> good
>>>> thing to put it in WebSocketChannel so its shared core common code 
>>>> goo

[chromium-dev] Re: HTML5 Web Socket design doc

[John Abd-El-Malek]

2009/6/25 Fumitoshi Ukai (鵜飼文敏) 

> Thanks for review.
>
> 2009/6/25 Michael Nordman 
>
>> Only skimmed thusfar as well... but from what i've seen, looks reasonable
>> to me.
>> * A version of the diagram you have in the chrome doc would be nice in the
>> webkit doc too.
>>
>
> Sure.  I've added a diagram in webkit part.
>
>
>> * Does WebSocketHandle really need to be refcounted. I know ResourceHandle
>> is a refcounted object and this design looks modeled off of that (which may
>> be why you've spec'd it this way). Unless your design actually needs
>> refcounting on this class, you may be able to simplify things without it.
>> From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
>>
>
> Yes.  I missed to add public RefCounted as base class of
> WebSocketHandle.
>  Thanks.
>
>  > should we reuse WebCore/loader instead of adding new component?
>>
>> The loader is somewhat notorious for its complexity. I think you've made a
>> good decision to keep this out of there and to design the websocket system
>> in a good clean modular fashion.
>>
>> > which component is responsible of web socket protocol framing?  This
>> design assumes WebSocketChannel serializes/deserializes message in web
>> socket frame.
>>
>> Since WebSocketHandle is inevitably going to be platform specific, any
>> code you want to be shared code shouldn't be slated for that class. To the
>> extent the 'web socket protocol framing' can be done indepedent of the
>> 'platform' socket handle (which it looks like it can be), it would be a good
>> thing to put it in WebSocketChannel so its shared core common code goodness.
>>
>
> I see.
> I've one question: Web socket handshaking is also platform independent.
> Should we do the handshaking in WebSocketChannel and WebSocketHandle just
> provides almost raw TCP socket?
> Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
> platform code?
>
> > Regarding the "WebKit API", note that no WebCore data types can be used
>> there. So you'll need to create wrapper classes.
>>
>
The WebKit API classes still derive from WebCore, which isn't possible.  The
WebKit API is an abstraction around WebCore classes, so it can't use any
WebCore types in it.


>> I see you have speced WebKit:: wrapper classes with the same name as the
>> corresponding WebCore:: classes.
>>
>> I wonder if that same naming could be confusingt? The naming convention
>> darin has been employing would be WebKit::WebWebSocketHandle, which
>> certainly looks odd.
>>
>
> Ok.  I follow the naming convention to be WebKit::WebWebSocketHandle.
>

hmm, I actually find WebWeb very unwieldy.  I vote for
WebKit::WebSocketHandle.


>
>
>>  * virtual void didReceiveData(const String& msg) {}
>>
>> Maybe rename this to channel client api to didReceiveMessage() to help
>> distinguish between raw 'data' being surface by the 'handle', and complete
>> 'messages' being surfaced by the 'channel'.
>>
>
> Sure. Fixed.
>
> Thanks!
> ukai
>
>
>>
>>
>> On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) > > wrote:
>>
>>> Hi,
>>>
>>> yuzo, tyoshino and I start working to implement HTML5 Web Socket and
>>> write design docs
>>>
>>>  WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
>>>  Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
>>>
>>> We'll send WebKit part to webkit-dev, if it looks ok.
>>> We'd welcome if you could give us feedback on our design docs.
>>>
>>> Thanks,
>>> ukai
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
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 do I deploy an NPAPI plugin over the internet from HTML ?

[John Abd-El-Malek]

On Thu, Jun 25, 2009 at 1:54 AM, Non-Stick  wrote:

>
> OK.  Thanks for that Matt.  At least now I know I was using the wrong
> mechanism.
>
> So what is the recommended way to download and install an NPAPI Plugin
> over the internet under Chrome ?


There's no way to make Chrome download your plugin automatically.  You're
going to have to build an installer for your plugin and point your users to
it if it's not available.


>
>
> There are 4 files that I need to download (the plugin dll plus 3
> helper files):
> npmyplugin.dll
> mylibrary.dll
> myprogA.exe
> myprogB.exe
>
> >
>

--~--~-~--~~~---~--~~
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: cygwin dependence missing?

[John Abd-El-Malek]

It looks like it had trouble writing to /tmp.  I don't think there are
missing binaries, looks like a space/permission issue.  Is there enough
space available?

2009/6/29 David Jones 

> I reviewed my layout-tests' output, and found some errors like:
> 090629 14:28:30 __init__.py:1032 ERROR
> LayoutTests/http/tests/xmlhttprequest/xml-encoding.html failed:
>   Text diff mismatch
>   Simplified text diff mismatch
> /cygdrive/e/mychromesrc/src/third_party/cygwin/bin/wdiff: /tmp/t101c.0: No
> such file or directory
>
> I think I missed something about cygwin, right?
> How to make up?
>
>
> --
> 200万种商品,最低价格,疯狂诱惑你>
>

--~--~-~--~~~---~--~~
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 do I deploy an NPAPI plugin over the internet from HTML ?

[John Abd-El-Malek]

Chrome and Safari don't support the pluginspage attribute.  The best way to
get this small feature request on our radar is to file a bug.

On Tue, Jun 30, 2009 at 3:04 PM, Non-Stick  wrote:

>
> > Can you create a test page that works differently in Firefox and
> > Chrome?  If so, that's a strong argument that we should change our
> > behavior to match Firefox.
>
> Yes, I have been using such pages for the past 2 weeks in an endeavour
> to get my NPAPI Plugin to download over the internet under Chrome ...
>
> If I use Chrome to load the same page that I use for "Firefox" (which
> references a .XPI file which is the Firefox recommended packaging), it
> fails to install the plugin saying " "No plugin available to display
> this content".  The page contains an EMBED tag similar to the
> following:
>
>width=640 height=480
>pluginspage="http://mysite.com/test/npapi/firefox/
> npmyplugin.xpi">
>
> If I use a more Chrome-tailored EMBED tag (that references a .CRX
> file), it similarly fails to install the plugin saying "No plugin
> available to display this content".  The page contains an EMBED tag
> similar to the following:
>
>width=640 height=480
>   pluginspage="http://mysite.com/test/npapi/chrome/
> npmyplugin.crx">
>
> > If you can create one that works
> > differently in Safari and Chrome, that's an even stronger argument
> > because we aim to be as compatible as possible with Safari.
>
> I haven't got round to supporting Safari yet, so cannot offer a view
> on that area at the moment.
>
> >
>

--~--~-~--~~~---~--~~
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: Any way to search rietveld issues?

[John Abd-El-Malek]

This functionality doesn't exist right now.  However Rietveld is open
source, so if anyone is interested in hacking something together, I'd be
more than happy to give feedback and code reviews.

On Mon, Jul 6, 2009 at 6:24 PM, Marshall Greenblatt
wrote:

> On Mon, Jul 6, 2009 at 8:40 PM, Mohamed Mansour  wrote:
>
>> The best way to search rietveld is through google groups:
>> http://groups.google.ca/group/chromium-reviews
>>
>
> That doesn't work very well for my purposes (seeing only open issues).  I'm
> hoping for something like the codereview.chromium.org table view with
> added search capability.  I wonder if it's possible to retrieve more than
> just the most recent issues as an RSS feed?  That would provide an easy
> approach for building such an application externally...
>
>
>> 
>>
>> As far as I know ;x
>>
>> -- Mohamed Mansour
>>
>>
>> On Mon, Jul 6, 2009 at 7:37 PM, Marshall Greenblatt <
>> magreenbl...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> Is there any way to search rietveld issues?  For instance, I would find
>>> it particularly useful if I could search for all open issues that touch
>>> certain source paths.
>>>
>>> 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: Any way to search rietveld issues?

[John Abd-El-Malek]

There isn't a way to index data at the moment through the public API,
although I have seen hacks on the google group for app engine.

On Mon, Jul 6, 2009 at 7:54 PM, Marshall Greenblatt
wrote:

> On Mon, Jul 6, 2009 at 9:50 PM, John Abd-El-Malek wrote:
>
>> This functionality doesn't exist right now.  However Rietveld is open
>> source, so if anyone is interested in hacking something together, I'd be
>> more than happy to give feedback and code reviews.
>
>
> Is there an existing "index and search me" API that Rietveld could use or
> would it be necessary to create the search capability from scratch?
>
>
>>
>>
>> On Mon, Jul 6, 2009 at 6:24 PM, Marshall Greenblatt <
>> magreenbl...@gmail.com> wrote:
>>
>>> On Mon, Jul 6, 2009 at 8:40 PM, Mohamed Mansour wrote:
>>>
>>>> The best way to search rietveld is through google groups:
>>>> http://groups.google.ca/group/chromium-reviews
>>>>
>>>
>>> That doesn't work very well for my purposes (seeing only open issues).
>>> I'm hoping for something like the codereview.chromium.org table view
>>> with added search capability.  I wonder if it's possible to retrieve more
>>> than just the most recent issues as an RSS feed?  That would provide an easy
>>> approach for building such an application externally...
>>>
>>>
>>>> <http://groups.google.ca/group/chromium-reviews>
>>>>
>>>> <http://groups.google.ca/group/chromium-reviews>As far as I know ;x
>>>>
>>>> -- Mohamed Mansour
>>>>
>>>>
>>>> On Mon, Jul 6, 2009 at 7:37 PM, Marshall Greenblatt <
>>>> magreenbl...@gmail.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Is there any way to search rietveld issues?  For instance, I would find
>>>>> it particularly useful if I could search for all open issues that touch
>>>>> certain source paths.
>>>>>
>>>>> 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] Updating Rietveld by replying to codereview emails

[John Abd-El-Malek]

Just a heads up that you can now reply to code review emails and your reply
will show up on Rietveld.

--~--~-~--~~~---~--~~
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: Updating Rietveld by replying to codereview emails

[John Abd-El-Malek]

Note: this finds the Rietveld issue number by looking for the last
http://codereview.chromium.org/ url in the email.  So make sure to leave
that url in the email, and if you add another url to a different issue,
don't put it at the end.

On Mon, Jul 6, 2009 at 9:11 PM, John Abd-El-Malek  wrote:

> Just a heads up that you can now reply to code review emails and your reply
> will show up on Rietveld.

--~--~-~--~~~---~--~~
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: Updating Rietveld by replying to codereview emails

[John Abd-El-Malek]

They put the id in the subject, but I wanted to avoid doing that.  The
smaller the subject, the more chance of seeing the "lgtm" or objections of
others without reading the email.

On Wed, Jul 8, 2009 at 6:17 PM, Jeremy Orlow  wrote:

> Hm...I wonder how mondrian (an internal Google tool) does it...
> Maybe the chromium-revi...@googlegroups.com could be changed to
> chromium-reviews+@googlegroups.com and that could be
> used instead?
>
> On Wed, Jul 8, 2009 at 5:44 PM, John Abd-El-Malek wrote:
>
>> Note: this finds the Rietveld issue number by looking for the last
>> http://codereview.chromium.org/ url in the email.  So make sure to leave
>> that url in the email, and if you add another url to a different issue,
>> don't put it at the end.
>>
>> On Mon, Jul 6, 2009 at 9:11 PM, John Abd-El-Malek wrote:
>>
>>> Just a heads up that you can now reply to code review emails and your
>>> reply will show up on Rietveld.
>>
>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Access to window handles from plugins?

[John Abd-El-Malek]

On Fri, Jul 17, 2009 at 10:45 AM, Daniel Wagner-Hall wrote:

>
> Hi,
>
> Can anyone help me with this? How can I get the window handle of an
> element from its JS DOM node?


DOM elements, with the exception of plugins and select controls, don't have
window handles because they're not implemented as native controls (otherwise
we'd run out of OS handles on some pages).

Are you asking specifically about a plugin node?

>
>
> Perhaps a little background might help! I'm currently working on
> WebDriver, a browser testing automation tool[1], to add Chrome
> support.  As suggested by the chrome team, this is being written as an
> extension with an embedded NPAPI plugin.  The original driver worked
> with the AutomationProxy, but this is not available in release
> binaries, which means that a user would need to compile a custom
> version of Chrome; obviously a less than ideal user experience :)
>
> We use a native interactions library for sending keys/clicks/etc at
> the OS level, which requires a window handle to the window containing
> the element to do its thing. This library is shared between all the
> drivers for a particular platform (at the moment, only Windows, but X
> support is coming soon).
>
> Thanks,
>
> Daniel Wagner-Hall
>
> 1: http://code.google.com/p/webdriver/
>
> >
>

--~--~-~--~~~---~--~~
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: Access to window handles from plugins?

[John Abd-El-Malek]

On Fri, Jul 17, 2009 at 12:06 PM, Daniel Wagner-Hall wrote:

>
> I can happily get the plugin's window handle using standard NPAPI
> calls, I'm trying to get the window handle of arbitrary tabs (and
> indeed frames) which my extension has loaded
>
> Specifically, I am opening pages, at the moment using window.open in
> the background page (though this may change to something slightly more
> clean, I haven't really considered what/how yet), and manipulating
> them with Javascript (e.g. grabbing their title).  I can interact with
> them through Javascript from the background page, but would like to be
> able to generate native OS events to the window handle of the
> windows/tabs which I open...
>
> From my experimenting with Spy++ and the results of NPAPI SetWindow
> calls, the HWND returned for the plugin has no parent which can be
> conveniently used, though there may be some clever scheme used which
> I'm just not seeing by not knowing how things really work.


This wouldn't be robust, as Chrome has switched the window hierarchy in the
past and it might occur again in the future (even to the extreme of that
plugin window not having a parent).

What you probably want to do is call NPN_GetValue on NPNVnetscapeWindow to
get the HWND of the page where the calling plugin is hosted.  To get the
HWND of other windows that you open, you can embed a plugin instance in
them, and script them using JS which ends up calling into binary code, which
then calls NPN_GetValue.


>
> >
>

--~--~-~--~~~---~--~~
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: valgrind help office hours

[John Abd-El-Malek]

I have a leak after a check-in.  I tried following the instructions on my
Linux box, but couldn't (I hardly develop on Linux).

jabdelma...@jabdelmalek:/usr/local/google/chrome/src$ sh
tools/valgrind/chrome_tests.sh  --generate_suppressions -t ui
Usage: chrome_tests.py -b  -t  [-t  ...]

chrome_tests.py: error: no such option: --generate_suppressions


I had tried to follow the getting started instructions in installing and
building valgrind from source so that it works in ui_tests, but the first
line fails for me:

jabdelma...@jabdelmalek:/usr/local/google/chrome/src$ sh autogen.sh
sh: autogen.sh: No such file or directory


So I'm unable to fix the regressions from my checkin.  I think it's
difficult to require people to keep the tree green on all these builders,
if it's this hard for developers on other platforms to reproduce the
problems.

On Mon, Jul 20, 2009 at 10:40 AM, Dan Kegel  wrote:

>
> On Mon, Jul 20, 2009 at 3:48 PM, Dan Kegel wrote:
> > If you'd like to help with the stability fixit week
> > ( http://code.google.com/p/chromium/wiki/StabilityFixitWeek )
> > but valgrind is giving you trouble,
> > I'll be available from 10am to 4pm PST today to help;
> > contact me via email, chat, or IRC with your
> > chromium valgrind questions and I'll try to answer them.
>
> forgot to mention: my preferred chromium chat is daniel.r.ke...@gmail.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: valgrind help office hours

[John Abd-El-Malek]

On Mon, Jul 20, 2009 at 7:31 PM, Thomas Van Lenten wrote:

>
>
> On Mon, Jul 20, 2009 at 10:04 PM, John Abd-El-Malek wrote:
>
>> I have a leak after a check-in.  I tried following the instructions on my
>> Linux box, but couldn't (I hardly develop on Linux).
>>
>> jabdelma...@jabdelmalek:/usr/local/google/chrome/src$ sh
>> tools/valgrind/chrome_tests.sh  --generate_suppressions -t ui
>> Usage: chrome_tests.py -b  -t  [-t  ...]
>>
>> chrome_tests.py: error: no such option: --generate_suppressions
>>
>>
>> I had tried to follow the getting started instructions in installing and
>> building valgrind from source so that it works in ui_tests, but the first
>> line fails for me:
>>
>> jabdelma...@jabdelmalek:/usr/local/google/chrome/src$ sh autogen.sh
>> sh: autogen.sh: No such file or directory
>
>
> Did you checkout the valgrind source into this dir?  The directions you're
> starting with are talking about building it in the directory you downloaded
> the source too.
>

I just followed the Getting Started instructions under Linux.  Perhaps the
instructions need to call out where to get the source from (i.e. the ones
there are incomplete).


>
> In a lot of cases, simply by looking at the data from the bots you can see
> what the leak is likely to be to fix it without having to run locally.  When
> you do need to run it under valgrind, the stdio log from the bot can help
> give you the command line the bot is using which you can then start with
> locally.
>

But as per my first problem, I couldn't even do that.


>
> TVL
>
>
>>
>>
>>
>> So I'm unable to fix the regressions from my checkin.  I think it's
>> difficult to require people to keep the tree green on all these builders,
>> if it's this hard for developers on other platforms to reproduce the
>> problems.
>>
>>
>> On Mon, Jul 20, 2009 at 10:40 AM, Dan Kegel  wrote:
>>
>>>
>>> On Mon, Jul 20, 2009 at 3:48 PM, Dan Kegel wrote:
>>> > If you'd like to help with the stability fixit week
>>> > ( http://code.google.com/p/chromium/wiki/StabilityFixitWeek )
>>> > but valgrind is giving you trouble,
>>> > I'll be available from 10am to 4pm PST today to help;
>>> > contact me via email, chat, or IRC with your
>>> > chromium valgrind questions and I'll try to answer them.
>>>
>>> forgot to mention: my preferred chromium chat is
>>> daniel.r.ke...@gmail.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: out of process (v8) proxy resolving

[John Abd-El-Malek]

The plug-in sandbox is too weak to be robust, see the other thread about it.
 As long as it has access to HWNDs, it's very easy to break out of it.

On Wed, Jul 29, 2009 at 10:43 AM, Adam Barth  wrote:

>
> I wonder if we could use something like the plug-in sandbox for the
> main browser process in the intermediate term.  That way the browser
> could still have HWNDs and the like.
>
> Adam
>
>
> On Wed, Jul 29, 2009 at 9:44 AM, Linus Upson wrote:
> > I realize this is not a small request, but it would be better if we could
> > move to a model where the browser was sandboxed and talked to a much
> simpler
> > process to carry out trusted operations on its behalf.
> > Linus
> >
> > On Wed, Jul 29, 2009 at 3:29 AM, Eric Roman  wrote:
> >>
> >> Here is a design document for http://crbug.com/11746
> >>
> >>
> >>
> http://sites.google.com/a/chromium.org/dev/developers/design-documents/out-of-process-v8-pac
> >>
> >> Feedback welcome.
> >>
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: Quota UI for LocalStorage (and others in the future)

[John Abd-El-Malek]

On Tue, Jul 28, 2009 at 8:40 PM, Jeremy Orlow  wrote:

> I'm starting to think ahead to how quotas will work with LocalStorage (and
> I assume database and maybe even AppCache).  To begin with, I'll probably
> just set a fixed quota (5mb is pretty standard), but some apps will surely
> desire more space than that, so I think we'll need a more robust solution
> fairly quickly.  (Maybe even before it comes out from behind the
> --enable-local-storage flag.)
> The question is how should we handle quotas from a UI perspective.
>
> One approach that seems obvious to a lot of people I've talked to is asking
> the user (maybe via an info bar?) whenever an origin hits its limit (before
> we decide whether to return a quota exceeded error or not).  The problem is
> that WebKit (in the renderer) can't block on the UI thread (since it may be
> blocked on WebKit).  Maybe it's safe to pump plugin related events while in
> the middle of a JavaScript context?  If not, then I'm not sure if any
> just-in-time solution like this is going to be viable.
>

It is possible to stop JS execution to wait on the browser process, just
like what we do for alerts/showModalDialog.  This involves running a nested
message loop, which we try to avoid unless absolutely necessary because of
reentrancy issues (but in this case, it's necessary so it's ok).


>
> We could implement heuristics that predict when LocalStorage is about to
> run out of space, but if we don't predict it in time, we will have to send a
> quota exceeded exception to the script.  A lot of common use cases like you
> syncing gmail for the first time would make this difficult to do well, I
> think.
>
> Safari buries the setting in the preferences menu.  That would be better
> than nothing, I suppose.
>
> Any other ideas?
>
> Jeremy
>
> >
>

--~--~-~--~~~---~--~~
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: gcl change that you should be aware of

[John Abd-El-Malek]

whoa, please revert this change.  if I have a big changelist, now every time
I run gcl I have to expend effort to make sure no new files crept in.  this
will lead to more build failures as people check in other files accidently.

On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge  wrote:

> Howdy,
> Quick little change to gcl that everyone should be aware of.  When you
> execute the script it will now automatically pull all physically modified
> files into the "Paths in this changelist" section, which means no more
> copying and pasting the files you changed into your CL.  The behavior is
> closer to that of P4 (where we delete files as opposed to adding them).  All
> the unchanged files are still below.
>
> Kind Regards,
>
> Anthony Laforge
> Technical Program Manager
> Mountain View, CA
>
> >
>

--~--~-~--~~~---~--~~
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: Running UI test in parallel (experimental)

[John Abd-El-Malek]

This is very cool, but I ran into a few problems when I tried to run it:
a:\chrome2\src\chrome>tools\test\smoketests.py --tests=ui

>> You must have your local path of trunk/src/tools/python added to your
PYTHONPATH.<<

Traceback (most recent call last):
  File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 32, in

import google.httpd_utils
ImportError: No module named google.httpd_utils


hmmm, never needed PYTHONPATH set before.  Can't this script set it itself?
 Setting it manually will fail when I move depot locations etc..  But
anyways, I set it and then

a:\chrome2\src\chrome>set PYTHONPATH=a:\chrome\src\tools\python

a:\chrome2\src\chrome>tools\test\smoketests.py --tests=ui
Traceback (most recent call last):
  File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 274, in

result = main(options, args)
  File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 155, in main
sys.path.insert(0, _BuildbotScriptPath('slave'))
  File "A:\chrome2\src\chrome\tools\test\smoketests.py", line 84, in
_BuildbotScriptPath
'scripts', sub_dir)
  File "a:\chrome\src\tools\python\google\path_utils.py", line 72, in
FindUpward
parent = FindUpwardParent(start_dir, *desired_list)
  File "a:\chrome\src\tools\python\google\path_utils.py", line 55, in
FindUpwardParent
(desired_path, start_dir))
google.path_utils.PathNotFound: Unable to find tools\buildbot\scripts\slave
above A:\chrome2\src\chrome\tools\test



tools\buildbot isn't in the public tree I think, since I don't find it
here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/.  So
external contributors can't use this?  Also, why should this script depend
on the buildbot scripts?  I don't have them so I can't try this out.

Can't we just have a minimal python script that runs ui_tests in parallel?

On Wed, Jul 29, 2009 at 3:28 PM, Huan Ren  wrote:

>
> I just checked in a change to run ui_tests in parallel based on
> sharding mechanism provided by GTest. Each ui_tests instance has its
> own user data dir, and the number of ui_tests instances is
> NUMBER_OF_PROCESSORS. I have updated
> src/chrome/tools/test/smoketests.py so you can run it through command
> line:
>
> python.exe smoketests.py --tests=ui [--verbose]
>
> Running ui_tests.exe directly is still the old behavior of
> sequentially running. On my 4 core machine, the running time has been
> reduced by half, from 832 secs to 443 secs. But I need to make sure
> all tests can run reliably in this parallel fashion. So if you try it
> out, I will be interested to know how fast the performance is improved
> and what additional tests are failing.
>
> Huan
>
> P.S. this change is for Windows platform as I think Linux/Mac is
> already using GTest sharding.
>
> >
>

--~--~-~--~~~---~--~~
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: Can't edit others' codereviews?

[John Abd-El-Malek]

Intentional but I have a TODO in the Chromium branch of Rietveld to update
this.  I just synced ~60 changes from trunk to our branch, and now we get a
close button to the left of each issue.  Since everyone with a @chromium
account could edit an issue, I thought it was too easy to accidentally close
others' issues.  So I disabled the give-every-chromium-user-full-access
change.
We can get rid of the close button to the left of issues in our branch, or
with a little bit of work only show it for your issues.  I didn't have time
to do this so I just removed the full access for everyone for now.

What is the preferred behavior?  Whoever feels strongly about this can reply
to this thread or to me and I can implement the popular option.  I don't
feel strongly about any of the options.

On Sat, Aug 15, 2009 at 2:24 PM, Peter Kasting  wrote:

> I noticed yesterday and today the codereviews I'm looking at sent by other
> people) no longer give me the option to "Edit".  Is this an intentional
> change?  Now I can't assign reviewers when appropriate.
> 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: Can't edit others' codereviews?

[John Abd-El-Malek]

This does affect closing, adding reviewers, changing the description, and
deleting-with-no-undo.  Given the feedback on this thread, I'll restore
almost-full functionality to all chromium accounts (except for delete, I'll
make it only work for the owner since it's irreversible).

On Sun, Aug 16, 2009 at 3:14 PM, Mark Mentovai  wrote:

> John Abd-El-Malek wrote:
> > Intentional but I have a TODO in the Chromium branch of Rietveld to
> update
> > this.  I just synced ~60 changes from trunk to our branch, and now we get
> a
> > close button to the left of each issue.  Since everyone with a @chromium
> > account could edit an issue, I thought it was too easy to accidentally
> close
> > others' issues.  So I disabled the give-every-chromium-user-full-access
> > change.
>
> But they're still reopenable, right?  We're talking about close, not
> delete-there-is-no-undo?  If so, it doesn't really sound like a
> problem to me at all.
>
> I don't think that restricting our access to edit and close issues is
> a reasonable solution to this.  Personally, I rarely edited others'
> descriptions, but I frequently closed issues for others when
> committing their changes for them.
>
> Mark
>

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

[chromium-dev] Re: Plugin control flow and race conditions

[John Abd-El-Malek]

On Mon, Aug 17, 2009 at 11:43 AM, bsmedberg  wrote:

>
> At Mozilla we're currently working on implementing multi-process
> plugin hosts similar to the model used by Chromium. However, we're
> having trouble working through the many potential race conditions
> introduced by having multiple processes (and therefore multiple flows
> of control). I've read
> http://dev.chromium.org/developers/design-documents/plugin-architecture
> but that doesn't seem to address most of the issues we're facing.
>

For the detailed view of how we solve these issues, the best place to look
at is the code.  Specifically, plugin_channel.cc & ipc_sync_channel.cc.

To avoid deadlock, when one process is sending a synchronous message, it
responds to other synchronous messages in the meantime.  However to avoid
unnecessary reentrancy, we disable this for synchronous messages from the
plugin process unless that process is itself responding to synchronous
messages.  We did this because otherwise a plugin process could try to force
layout while it's already happening, which is not expected in WebKit.  You
can find more about this in PluginChannel's constructor, we call
SendUnblockingOnlyDuringDispatch which makes it so that synchronous

>
> The most obvious problem is that both processes may send a synchronous
> IPC message at the same time. Assuming that these don't deadlock, the
> native stack for the two calls would end up interleaved. What happens
> when the renderer process and the plugin process send conflicting
> messages at roughly the same time? For example: the browser finishes a
> network request with NPP_DestroyStream and the plugin (responding to a
> UI event, perhaps) calls NPN_DestroyStream simultaneously? I can't
> imagine that a plugin would expect to receive aa NPP_DestroyStream
> message after it has already called NPN_DestroyStream, and this is
> likely to cause erratic plugin behavior.
>

This specific case is not really a problem.  If you look at our
implementation of PluginInstance::NPP_DestroyStream(), we set NPStream.ndata
to NULL.  The second call would early exit if it's already null.


> Are the IPC delegates/stubs responsible for checking the state of each
> call and avoiding improper nesting? Do you have any procedure/system
> for detecting with racy improper nesting? For example, racing pairs
> NPP_Write/NPN_DestroyStream and NPN_RequestRead/NPP_DestroyStream are
> equally unexpected. And all these example come only from the NPStream
> interface; I haven't even begun to examine potential message races in
> the core NPP APIs or the NPObject APIs.
>

We did run into a bunch of these issues early on, but they were all easy to
workaround (i.e. always checking first if the stream is destroyed, since it
could be called afterwards in the situations that you describe).

The hardest issues we've had to solve are related to performance.  The
initial release had poor performance when scrolling with lots of
windowed/windowless plugins.  To solve this, we moved to an asynchronous
painting/scrolling model.  While adding extra complexity and memory usage,
the user experience when scrolling is much better.  The techniques we used
should be applicable in your implementation as well, we can talk more about
this when you're ready (plugin lunch? :) ).


> --BDS
>
> >
>

--~--~-~--~~~---~--~~
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: Can't edit others' codereviews?

[John Abd-El-Malek]

On Tue, Aug 18, 2009 at 5:37 AM, Evan Martin  wrote:

> On Sat, Aug 15, 2009 at 11:44 PM, Nico Weber wrote:
> > `git cl patch` reuses existing issues, so when landing stuff for other
> > people, I used to edit the issue on codereview to add "Patch by
> > someone+usuallytru...@example.org "
> before landing. So for me editing
> > other people's issues is useful.
>
> $ git cl dcommit --help | grep -- -c
>  -c CONTRIBUTOR  external contributor for patch (appended to description)
>
> My typical workflow is:
>  grep trung AUTHORS
>  
>  git cl dcommit -c ""
>
> I think it'd be neat to somehow use git's distinction of author vs
> committer such that when you patch in a cl (with "git cl patch") it
> plumbs the rietveld-side author info into the local git commit info
> and from there into the svn commit, but I think the mapping of
> rietveld username to AUTHORS username isn't very clear.
>

A little hacky, but you could reuse the url used for autocomplete in
reviewers/CC boxes.  i.e.
http://codereview.chromium.org/account?q=Evan%20Martin returns
e...@chromium.org (Evan Martin)


>
> PS: Personal OKR of responding to 100% of messages mentioning git
> remains green.  :D
>

--~--~-~--~~~---~--~~
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 render Message between Browser and Renderer

[John Abd-El-Malek]

Have you tried using the ipc logger (about:ipc in debug builds)?  You can
look at all the messages and their content.

On Tue, Aug 18, 2009 at 11:16 AM, hap 497  wrote:

> Thanks. I did debug on Renderer process.
> As a matter for fact,
> This breakpoint 'WebFrameLoaderClient::dispatchWillSendRequest() " breaks,
> but
> this 'WebFrameLoaderClient::dispatchWillSubmitForm()' does not.
>
> I was doing a 'google search' (i.e. enter text in search box, and click
> 'Search' in google home page)
>
> On Tue, Aug 18, 2009 at 5:45 AM, Evan Martin  wrote:
>
>> Just a guess, but since that code runs in the renderer, it's likely
>> you're debugging the wrong process.
>> See "Multi-process issues" in
>> http://dev.chromium.org/developers/how-tos/debugging .
>>
>> On Mon, Aug 17, 2009 at 11:03 PM, hap 497 wrote:
>> > Hi,
>> >
>> > I appreciate if someone can help me understand what is the Message send
>> from
>> > Browser to Renderer in the case of html form submission.
>> > I think the message ViewMsg_Navigate_Params is for HTTP get only, not
>> for
>> > HTTP post, since I dont' see any attribute in that struct to store form
>> > submission data.
>> >
>> > And I read this
>> > http://dev.chromium.org/developers/design-documents/form-auto,  it said
>> "
>> > WebFrameLoaderClient::dispatchWillSubmitForm() passes the AutofillForm
>> as
>> > the argument of its delegate's function OnAutofillFormSubmitted()". So I
>> > tried setting breakpoints in
>> WebFrameLoaderClient::dispatchWillSubmitForm(),
>> > but it never breaks when I do a 'google search' in chromium. I only see
>> void
>> > WebFrameLoaderClient::dispatchWillSendRequest() get breaks.  Can you
>> please
>> > tell me why is that?
>> >
>> > Thank you for any help.
>> >
>> >
>> > >
>> >
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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: running reliability tests

[John Abd-El-Malek]

The information on how to do this is currently on the internal wiki,
although it seems there's no reason it shouldn't be moved to the public wiki
(not it :) ).
http://wiki.corp.google.com/twiki/bin/view/Main/ChromeDebuggingChromeBotCrashes

On Tue, Aug 18, 2009 at 3:42 PM, James Hawkins wrote:

>
> Hi,
>
> How can I run the reliability tests, specifically the automated UI
> tests, locally?
>
> Thanks,
> James Hawkins
>
> >
>

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

[chromium-dev] PSA: do not include X_messages.h in other headers

[John Abd-El-Malek]

Including files like render_messages.h and automation_messages.h from other
header files is unnecessary and slows down the build (adds about ~100K lines
of headers to each cc file).  Last time I removed all these occurrences, it
improved the build time by 15%.  Looks like a few more crept in now, so I'm
removing them.  Please be careful not to reintroduce this, and look out for
this in code reviews (yes, it would be great to have an automated way of
catching this, patches welcome).

--~--~-~--~~~---~--~~
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: PSA: do not include X_messages.h in other headers

[John Abd-El-Malek]

Great!  Please try to add this to an existing check, or do it in a way that
doesn't involve the files being read once for each presubmit check, as the
presubmit step is already too slow.

On Thu, Aug 20, 2009 at 11:16 AM, Paweł Hajdan Jr.
wrote:

> Cool! Thanks so much. I'm going to write a presubmit check for that.
>
> On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek  wrote:
>
>> Including files like render_messages.h and automation_messages.h from
>> other header files is unnecessary and slows down the build (adds about ~100K
>> lines of headers to each cc file).  Last time I removed all these
>> occurrences, it improved the build time by 15%.  Looks like a few more
>> crept in now, so I'm removing them.  Please be careful not to reintroduce
>> this, and look out for this in code reviews (yes, it would be great to have
>> an automated way of catching this, patches welcome).
>> >>
>>
>

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