[chromium-dev] Re: WebMouseEvent vs. PlatformMouseEvent

[Darin Fisher]

The two interfaces are intentionally similar.  Here's why the two exist...

PlatformMouseEvent is a WebCore type.  WebMouseEvent is defined by
Chrome's webkit/glue layer to abstract away the WebCore types.  This
is valuable since the underlying WebCore types change frequently.  The
abstraction layer insulates the rest of Chrome from those kinds of
changes.

This actually explains the whole purpose of webkit/glue ;-)

-Darin



On Thu, Sep 18, 2008 at 6:08 PM, Mark Wang <[EMAIL PROTECTED]> wrote:
>
> Hi all --
>
> In going through the Chrome UI code, I'm noticing these two classes;
> both apparently seem to be a platform-independent abstraction of a
> mouse event, and that both are in use.
>
> Is there much functional difference between the two?  In quickly
> glancing through the headers, they seem to overlap a bit.  Will they
> be coalesced into one or do they serve two distinct purposes?
>
> Thanks,
>
> Mark
> >
>

--~--~-~--~~~---~--~~
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: SSLClientSocket, TCPClientSocket design choices on linux

[Darin Fisher]

On Thu, Sep 18, 2008 at 2:36 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 17, 2008 at 3:12 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
>>
>>> In previous discussion with Darin, it seemed we
>>> wanted to use epoll rather than poll.   This
>>> implies that we want to not use NSPR for our
>>> network I/O, and thus implies that we want to
>>> write an NSPR I/O layer so we can do our own
>>> network I/O rather than letting nss do it via nspr.
>>
>> can't we avoid NSPR?  or does the NSS shipped with existing Linux
>> boxes give us no alternative API to get at the SSL state machine?
>
> Since we don't have access to the SSL state machine
> inside NSS's SSL library, we have to use PRFileDesc
> and PR_Recv and PR_Send, but we don't need to use
> PR_Poll.  We can call the 'poll' method of PRFileDesc
> directly to get the POLLIN/POLLOUT or EPOLLIN/EPOLLOUT
> flags we should use with the poll() or epoll() system
> call.
>
> This does require that SSLClientSocket be NOT layered
> on top of TCPClientSocket on Linux, because SSLClientSocket
> needs to use the underlying Unix fd (wrapped in a
> PRFileDesc) directly.
>
> If we really need access to the SSL state machine inside
> NSS's SSL library, we'll need to modify the SSL library.
> Fortunately, we would only need to build two directories
> of the NSS source tree, and we can build them against
> system-provided NSS headers and shared libraries.
> But that's a lot of work.  We should begin with an
> implementation that uses the current PRFileDesc-based
> API.
>
> Wan-Teh

I think it will be very valuable to us to maintain our own layering
here.  It sounds like Dan and you have an idea of how to do it.

Perhaps in parallel--or when time permits--we should work to add the
APIs to NSS that would expose the underlying state machine?  That way,
one day, we will have a cleaner way to do what we prefer?

-Darin

--~--~-~--~~~---~--~~
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] Accessing the invoked method name from the JavaScript callback

[Marshall Greenblatt]

Hi All,

It would be helpful if CppBoundClass provided a means to discover the method
name that was used to invoke a JavaScript callback.  This is particularly
true for the fallback callback.  There are a number of ways in which we
could support this functionality:

1. Set a member variable to the last executed method name in
CppBoundClass::Invoke() before the callback method is called.
2. Return the method name as the first parameter in the argument list
(fallback callback only).
3. Modify "Callback" so that the first parameter to the callback is the
method name.

Option 1 seems like the simplest and least inconsistent/intrusive solution,
but it isn't reentrant.  Will JavaScript execution always run synchronously
within a particular WebFrame?

Thanks,
Marshall

--~--~-~--~~~---~--~~
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] Beta release: 0.2.149.30

[Mark Larson (Google)]

These notes are online at http://googlechromereleases.blogspot.com/.

Google Chrome version 0.2.149.30 was released on 17 September 2008.
Users will get automatic updates over the next few days.

Security Updates
===
[r2042] Fix a potential denial of service with very long title
attributes on tags. The title attribute sets the tooltip text when you
hover the mouse over an element.
Security Rating: Low risk. This can lead to 100% CPU usage or a tab
crash.
More information: http://www.securityfocus.com/bid/30975

Other Changes
===
[r1927] Stop adding content from HTTPS sites to the searchable index.
Google Chrome keeps a searchable history of pages you visit. This
history is only stored locally on your computer. Previously, this
searchable history included the text from secure sites, such as your
online bank (any sites using SSL for security). Google Chrome no
longer saves text from secure pages in its local history. The address
bar and local history search page will no longer find data from secure
sites you have visited.

If you are concerned about data that might have been indexed for
searching before this release, you can follow the Google Chrome Help
Center instructions for clearing your browsing history.
---
[r1978] Don't send sensitive URLs to search suggest services. Google
Chrome stops sending data to a suggest service if the typed URL:
contains a username:password field (http://
username:[EMAIL PROTECTED]/)
has query parameters (the trailing ?param=data following the URL)
is an https URL with any path component (any part following the
hostname, such as /path in https://www.example.com/path)
---
[r1848, r1943, r2003] Fixes to the Google Chrome updater to make
updates more reliable.
---
[r1859] Fix problems with Flash not playing video if too many
connections are opened. For example, using the slider to advance video
on YouTube could cause video to stop playing.
---
[r2059] Allow JavaScript to communicate with Java applets. Fixes bug
580.
---
[r1299] JavaScript: Dispatch contextmenu events after mouseup events.
This fixes the right-click menu not working on Google Spreadsheets.
Fixes bug 745.
---
[r1692] Fix crashes with some plugins --3dvia was the most widely
reported-- when they return an error for NPN_GetValue. Fixes bug 493.

--~--~-~--~~~---~--~~
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] WebMouseEvent vs. PlatformMouseEvent

[Mark Wang]

Hi all --

In going through the Chrome UI code, I'm noticing these two classes;
both apparently seem to be a platform-independent abstraction of a
mouse event, and that both are in use.

Is there much functional difference between the two?  In quickly
glancing through the headers, they seem to overlap a bit.  Will they
be coalesced into one or do they serve two distinct purposes?

Thanks,

Mark
--~--~-~--~~~---~--~~
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: SSLClientSocket, TCPClientSocket design choices on linux

[Dan Kegel]

On Thu, Sep 18, 2008 at 4:15 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
> If you look at the implementation of the 'poll' method in NSS:
> http://mxr.mozilla.org/security/source/security/nss/lib/ssl/sslsock.c#1567
>
> there are two cases that depend on the internal state of the SSL
> PRFileDesc:
>
> 1624 } else if ((new_flags & PR_POLL_READ) && (SSL_DataPending(fd) > 0)) {
> 1625 *p_out_flags = PR_POLL_READ;/* it's ready already. */
> 1626 return new_flags;
> 1627 } else if ((ss->lastWriteBlocked) && (how_flags & PR_POLL_READ) &&
> 1628(ss->pendingBuf.len != 0)) { /* write data waiting
> to be sent */
> 1629 new_flags |=  PR_POLL_WRITE;   /* also select on write. */
> 1630 }
>
> So you'd need to essentially maintain the same state in parallel.

We'll see.  I think it will fall out naturally with no effort on my part.
- Dan

--~--~-~--~~~---~--~~
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: conflicting cairo.h

[Eric Seidel]

We no longer compile with PLATFORM(CAIRO) on the merge branch.  Thus I
expect that can be removed.

-eric

On Thu, Sep 18, 2008 at 4:13 PM, Evan Martin <[EMAIL PROTECTED]> wrote:
>
> I'm playing with building a no-op test_shell that links in GTK.
>
> The GTK header stack pulls in /usr/include/gtk-2.0/gdk/gdkcolor.h,
> which has "#include ", which picks up our
> webkit/port/platform/cairo.h , which begins with this comment:
>
> // We compile WebKit with PLATFORM(CAIRO) defined. This only affects a few
> // places in the shared headers. Therefore, we provide this replacement
> //  that defines the Cairo types used in these shared headers to be
> // the types that we desire.
>
> Does anyone have plans to remove this file, now that we're unforking
> from WebKit?
> Or is it still necessary for some reason?
>
> >
>

--~--~-~--~~~---~--~~
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: SSLClientSocket, TCPClientSocket design choices on linux

[Wan-Teh Chang]

On Thu, Sep 18, 2008 at 3:34 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>
> On Thu, Sep 18, 2008 at 3:26 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
>> I found that I documented the 'poll' method of PRFileDesc
>> http://developer.mozilla.org/en/NSPR_Poll_Method
>
> My guess is I don't need that at all.  I can tell just by looking at
> my buffers what kind of I/O is needed, no need to ask for hints
> from nss or nspr.

If you look at the implementation of the 'poll' method in NSS:
http://mxr.mozilla.org/security/source/security/nss/lib/ssl/sslsock.c#1567

there are two cases that depend on the internal state of the SSL
PRFileDesc:

1624 } else if ((new_flags & PR_POLL_READ) && (SSL_DataPending(fd) > 0)) {
1625 *p_out_flags = PR_POLL_READ;/* it's ready already. */
1626 return new_flags;
1627 } else if ((ss->lastWriteBlocked) && (how_flags & PR_POLL_READ) &&
1628(ss->pendingBuf.len != 0)) { /* write data waiting
to be sent */
1629 new_flags |=  PR_POLL_WRITE;   /* also select on write. */
1630 }

So you'd need to essentially maintain the same state in parallel.

Wan-Teh

--~--~-~--~~~---~--~~
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] conflicting cairo.h

[Evan Martin]

I'm playing with building a no-op test_shell that links in GTK.

The GTK header stack pulls in /usr/include/gtk-2.0/gdk/gdkcolor.h,
which has "#include ", which picks up our
webkit/port/platform/cairo.h , which begins with this comment:

// We compile WebKit with PLATFORM(CAIRO) defined. This only affects a few
// places in the shared headers. Therefore, we provide this replacement
//  that defines the Cairo types used in these shared headers to be
// the types that we desire.

Does anyone have plans to remove this file, now that we're unforking
from WebKit?
Or is it still necessary for some reason?

--~--~-~--~~~---~--~~
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: Will Chrome use OCSP?

[Wan-Teh Chang]

On Thu, Sep 18, 2008 at 3:04 PM, Rick Andrews <[EMAIL PROTECTED]> wrote:
>
> Chrome appears to use CRLs for SSL cert status checking. Are there any
> plans to use OCSP instead, or primarily use OCSP with a fallback to
> CRLs?

We should primarily use OCSP with a fallback to CRLs.

If we aren't doing that, it's because 1) the WinHTTP library
that we're using doesn't give us this level of control on the
revocation checking methods, or 2) we made a mistake in
the new HTTP stack (not used by default).

For WinHTTP, we only have one option flag,
WINHTTP_ENABLE_SSL_REVOCATION, to enable
revocation checking:
http://msdn.microsoft.com/en-us/library/aa384066(VS.85).aspx

So it's all up to WinHTTP to decide whether it should
use CRLs or OCSP.

In the new HTTP stack, we're passing the flags
CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT |
CERT_CHAIN_CACHE_END_CERT to the
CertGetCertificateChain function.  Are those the
right flags to use?  Should we be using the
CERT_CHAIN_REVOCATION_CHECK_OCSP_CERT
flag?  See
http://msdn.microsoft.com/en-us/library/aa376078(VS.85).aspx

Wan-Teh

--~--~-~--~~~---~--~~
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: SSLClientSocket, TCPClientSocket design choices on linux

[Dan Kegel]

On Thu, Sep 18, 2008 at 3:26 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
> I found that I documented the 'poll' method of PRFileDesc
> http://developer.mozilla.org/en/NSPR_Poll_Method

My guess is I don't need that at all.  I can tell just by looking at
my buffers what kind of I/O is needed, no need to ask for hints
from nss or nspr.
- Dan

--~--~-~--~~~---~--~~
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: SSLClientSocket, TCPClientSocket design choices on linux

[Wan-Teh Chang]

On Thu, Sep 18, 2008 at 2:55 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>
> I bet you five bucks we can layer SSLClientSocket on top of
> TCPClientSocket by creating a little nspr i/o layer that
> talks to a memory buffer.  I did this with OpenSSL some time
> ago, I figure I can do it with nss, too.

That'd be nice.  Otherwise, we'd need to change http_network_transaction.cc,
which now constructs SSLClientSocket with a TCPClientSocket as argument.

> Plan: 1) stop reading mail and irc.  2) convert the nss demo app tstclnt.c to
> handle multiple clients and turn it into a little version of strsclnt.c, but
> using nonblocking io.  3) add the nspr i/o layer I mentioned, and
> don't let nss or nspr see any real sockets ever; handle all i/o
> to and from those buffers ourselves.  4) once that works, do the same
> thing in SSLClientSocket.  5) Profit.

I found that I documented the 'poll' method of PRFileDesc
two years ago:
http://developer.mozilla.org/en/NSPR_Poll_Method

Please let me know if you have any questions, and I'll
try to clarify it in that wiki page.

Wan-Teh

--~--~-~--~~~---~--~~
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] Will Chrome use OCSP?

[Rick Andrews]

Chrome appears to use CRLs for SSL cert status checking. Are there any
plans to use OCSP instead, or primarily use OCSP with a fallback to
CRLs?

-Rick Andrews


--~--~-~--~~~---~--~~
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: Endlessly Checking For Updates

[Peter Kasting]

On Thu, Sep 18, 2008 at 2:51 PM, Jiriteach <[EMAIL PROTECTED]> wrote:

> After updating Chrome to 0.2.152.1, heading over to Tools > About
> Chrome, it starts checking for updates.
> Except this keeps going and going!
>
> Any one experiencing this same problem?
>

Yes, everyone using 152.1.  A fix is in progress.

PK

--~--~-~--~~~---~--~~
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: Unit tests for x509_certificate

[Adam Barth]

I'm happy to review changelists as well as I'm partly to blame for the
lack of unit tests.

Adam


On Thu, Sep 18, 2008 at 12:47 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
>
> On Thu, Sep 18, 2008 at 11:32 AM, Avi Drissman <[EMAIL PROTECTED]> wrote:
>> I'm going to land some preliminary work on the x509 support for the Mac (see
>> http://codereview.chromium.org/2963). I want to do some refactoring of the
>> common parts, but there are no unit tests. Amanda and I are going to build
>> some, but wanted to run this by you to make sure that you could have your
>> say. You don't have any tests lying around, do you?
>
> No, I don't have any tests laying around.
>
> I'll review your changelist.
>
> Wan-Teh
>
> >
>

--~--~-~--~~~---~--~~
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: SSLClientSocket, TCPClientSocket design choices on linux

[Dan Kegel]

On Thu, Sep 18, 2008 at 2:36 PM, Wan-Teh Chang <[EMAIL PROTECTED]> wrote:
> Since we don't have access to the SSL state machine
> inside NSS's SSL library, we have to use PRFileDesc
> and PR_Recv and PR_Send, but we don't need to use
> PR_Poll.  We can call the 'poll' method of PRFileDesc
> directly to get the POLLIN/POLLOUT or EPOLLIN/EPOLLOUT
> flags we should use with the poll() or epoll() system
> call.
>
> This does require that SSLClientSocket be NOT layered
> on top of TCPClientSocket on Linux, because SSLClientSocket
> needs to use the underlying Unix fd (wrapped in a
> PRFileDesc) directly.

I bet you five bucks we can layer SSLClientSocket on top of
TCPClientSocket by creating a little nspr i/o layer that
talks to a memory buffer.  I did this with OpenSSL some time
ago, I figure I can do it with nss, too.

Plan: 1) stop reading mail and irc.  2) convert the nss demo app tstclnt.c to
handle multiple clients and turn it into a little version of strsclnt.c, but
using nonblocking io.  3) add the nspr i/o layer I mentioned, and
don't let nss or nspr see any real sockets ever; handle all i/o
to and from those buffers ourselves.  4) once that works, do the same
thing in SSLClientSocket.  5) Profit.
- Dan

--~--~-~--~~~---~--~~
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] Endlessly Checking For Updates

[Jiriteach]

After updating Chrome to 0.2.152.1, heading over to Tools > About
Chrome, it starts checking for updates.
Except this keeps going and going!

Any one experiencing this same problem?

--~--~-~--~~~---~--~~
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: SSLClientSocket, TCPClientSocket design choices on linux

[Wan-Teh Chang]

On Wed, Sep 17, 2008 at 3:12 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
>
>> In previous discussion with Darin, it seemed we
>> wanted to use epoll rather than poll.   This
>> implies that we want to not use NSPR for our
>> network I/O, and thus implies that we want to
>> write an NSPR I/O layer so we can do our own
>> network I/O rather than letting nss do it via nspr.
>
> can't we avoid NSPR?  or does the NSS shipped with existing Linux
> boxes give us no alternative API to get at the SSL state machine?

Since we don't have access to the SSL state machine
inside NSS's SSL library, we have to use PRFileDesc
and PR_Recv and PR_Send, but we don't need to use
PR_Poll.  We can call the 'poll' method of PRFileDesc
directly to get the POLLIN/POLLOUT or EPOLLIN/EPOLLOUT
flags we should use with the poll() or epoll() system
call.

This does require that SSLClientSocket be NOT layered
on top of TCPClientSocket on Linux, because SSLClientSocket
needs to use the underlying Unix fd (wrapped in a
PRFileDesc) directly.

If we really need access to the SSL state machine inside
NSS's SSL library, we'll need to modify the SSL library.
Fortunately, we would only need to build two directories
of the NSS source tree, and we can build them against
system-provided NSS headers and shared libraries.
But that's a lot of work.  We should begin with an
implementation that uses the current PRFileDesc-based
API.

Wan-Teh

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

[Pam Greene]

On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> Hi Mark/Pam,
>
> On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai <[EMAIL PROTECTED]> 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


>
> Thanks,
> Marshall
>
>
> >
>

--~--~-~--~~~---~--~~
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: Unit tests for x509_certificate

[Wan-Teh Chang]

On Thu, Sep 18, 2008 at 11:32 AM, Avi Drissman <[EMAIL PROTECTED]> wrote:
> I'm going to land some preliminary work on the x509 support for the Mac (see
> http://codereview.chromium.org/2963). I want to do some refactoring of the
> common parts, but there are no unit tests. Amanda and I are going to build
> some, but wanted to run this by you to make sure that you could have your
> say. You don't have any tests lying around, do you?

No, I don't have any tests laying around.

I'll review your changelist.

Wan-Teh

--~--~-~--~~~---~--~~
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: Automation of web application testing

[Patrick Johnson]

Also take a look at Selenium, which has support for Google Chrome:

http://selenium.openqa.org/

Patrick


On Thu, Sep 18, 2008 at 7:44 AM, pow <[EMAIL PROTECTED]> wrote:
>
> Came across WebDriver/ChromeDriver
> http://code.google.com/p/webdriver/
> http://groups.google.com/group/webdriver/browse_thread/thread/31f8c7e64f7560aa
>
> On Sep 6, 2:23 pm, pow <[EMAIL PROTECTED]> wrote:
>> Same requirement here. Need to automate web app testing for chrome. Is
>> there an Automation API? Will the Automation API be common for all
>> WebKit based browsers?
>>
>> How does Google test webpages in chrome! On page 9 of Chrome Comic
>> Book (http://www.google.com/googlebooks/chrome/), there is a mention
>> of ChromeBot. Is it comprehensive? is there an open source project for
>> this?
>>
>> Sai also has posted similar requirement for Automation API 
>> athttp://groups.google.com/group/chromium-dev/browse_thread/thread/b2bc...
>>
>> Thanks,
>> pow
>>
>> On Sep 4, 6:50 pm, Natesh <[EMAIL PROTECTED]> wrote:
>>
>> > Hi there,
>>
>> > We use PAMIE to automate the testing of apps developed by our company
>> > for IE. We wish to develop a similar light framework to test apps for
>> > Chrome. Any pointers or tips in that direction would really help.
>>
>> > Thanks
> >
>

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

[Marshall Greenblatt]

Hi Mark/Pam,

On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai <[EMAIL PROTECTED]> 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.

Thanks,
Marshall

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

[Mark Mentovai]

Marshall Greenblatt wrote:
> Does a tool currently exist for verifying and/or formatting source code
> based on the Google style guide?  If not, has any thought been given to
> developing such a tool?

Marshall-

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/).

Mark

--~--~-~--~~~---~--~~
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: Slow Loading

[Mike Belshe]

Try running with "--memory-model=high" and see if that doesn't change
things.  This will instruct Chrome to be greedy in its memory use.
Do you have lots of other apps running?  Or a virus scanner?  That can cause
this as well (and make it very difficult to reproduce!)

Mike

On Thu, Sep 18, 2008 at 8:54 AM, Phanuel <[EMAIL PROTECTED]> wrote:

>
> I've noticed that if I minimize the window for a little bit or switch
> tabs, it takes quite a while to render if I re-open the hidden or
> minimized tab.
>
> On Sep 4, 5:11 pm, GAMEOVER <[EMAIL PROTECTED]> wrote:
> > I just did it and it worked flawlessly for me.
> >
> > On Sep 4, 6:35 am, pokai <[EMAIL PROTECTED]> wrote:
> >
> > > well, i think u may be a little shocked to hear this.
> > > Google chrome is fast, right?
> > > I spotted the Comic Book link after clicking Learn more about Google
> > > from the Chrome's main page. I was looking at the Google Chrome Comic
> > > Book using Google Chrome. After looking through all the pages, I went
> > > back to Chrome's home page. The images took SUPER LONG toload, about
> > > 1 minute,when it only took less than a seconds before that. I tried
> > > all other web sites, it was the same.
> > > After that, I cleared the browser's cache, and, everything was back to
> > > normal. Everything loaded super fast.
> > > I tried it three more times, the same thing happened.
> > > I think that this is a glitch. Can you fix it?
> >
>

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

[Pam Greene]

I'll ask around and see if I can find one we can open-source.

- Pam

On Thu, Sep 18, 2008 at 7:06 AM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Does a tool currently exist for verifying and/or formatting source code
> based on the Google style guide?  If not, has any thought been given to
> developing such a tool?
>
> Something like lint, but perhaps more modular, would be a great help to
> people who don't live and breathe Google style every day.  We could then
> augment gcl to check code changes for style violations and warn/assist users
> in correcting any problems before the patches are uploaded for code review.
>
> Regards,
> Marshall
>
> >
>

--~--~-~--~~~---~--~~
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: Slow Loading

[deanm]

This is by design, Chromium tries to be kind to other applications,
and it notifies the operating system when it is backgrounded (or a tab
is backgrounded), so parts of the resident memory can be swapped out
and the physical memory can be used by other applications on your
system.

The slowness you see is the operating system swapping back in the
pages, since they have been used by other applications while Chromium
was backgrounded.

On Sep 18, 5:54 pm, Phanuel <[EMAIL PROTECTED]> wrote:
> I've noticed that if I minimize the window for a little bit or switch
> tabs, it takes quite a while to render if I re-open the hidden or
> minimized tab.
>
> On Sep 4, 5:11 pm, GAMEOVER <[EMAIL PROTECTED]> wrote:
>
> > I just did it and it worked flawlessly for me.
>
> > On Sep 4, 6:35 am, pokai <[EMAIL PROTECTED]> wrote:
>
> > > well, i think u may be a little shocked to hear this.
> > > Google chrome is fast, right?
> > > I spotted the Comic Book link after clicking Learn more about Google
> > > from the Chrome's main page. I was looking at the Google Chrome Comic
> > > Book using Google Chrome. After looking through all the pages, I went
> > > back to Chrome's home page. The images took SUPER LONG toload, about
> > > 1 minute,when it only took less than a seconds before that. I tried
> > > all other web sites, it was the same.
> > > After that, I cleared the browser's cache, and, everything was back to
> > > normal. Everything loaded super fast.
> > > I tried it three more times, the same thing happened.
> > > I think that this is a glitch. Can you fix it?
--~--~-~--~~~---~--~~
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: Slow Loading

[Phanuel]

I've noticed that if I minimize the window for a little bit or switch
tabs, it takes quite a while to render if I re-open the hidden or
minimized tab.

On Sep 4, 5:11 pm, GAMEOVER <[EMAIL PROTECTED]> wrote:
> I just did it and it worked flawlessly for me.
>
> On Sep 4, 6:35 am, pokai <[EMAIL PROTECTED]> wrote:
>
> > well, i think u may be a little shocked to hear this.
> > Google chrome is fast, right?
> > I spotted the Comic Book link after clicking Learn more about Google
> > from the Chrome's main page. I was looking at the Google Chrome Comic
> > Book using Google Chrome. After looking through all the pages, I went
> > back to Chrome's home page. The images took SUPER LONG toload, about
> > 1 minute,when it only took less than a seconds before that. I tried
> > all other web sites, it was the same.
> > After that, I cleared the browser's cache, and, everything was back to
> > normal. Everything loaded super fast.
> > I tried it three more times, the same thing happened.
> > I think that this is a glitch. Can you fix it?
--~--~-~--~~~---~--~~
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: Suggestion: Chrome Standalone

[Ian Fette]

Note that with that, you're not going to get automatic updates (e.g. you
will be vulnerable to security bugs even after we've patched them for most
users). Also, running on a fat32 partition greatly reduces the capabilities
of the sandbox model that we use to help prevent the installation of malware
and malicious disk access in general.
In short, not recommended.

2008/9/18 ph <[EMAIL PROTECTED]>

>
> This may help:  chrome-on-your-thumb-drive>
> (I hope that's what you meant).
>
> Paweł
>
> On Sep 17, 7:18 pm, Milton Segura <[EMAIL PROTECTED]> wrote:
> > It would be very useful.
> >
>

--~--~-~--~~~---~--~~
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: Automation of web application testing

[pow]

Came across WebDriver/ChromeDriver
http://code.google.com/p/webdriver/
http://groups.google.com/group/webdriver/browse_thread/thread/31f8c7e64f7560aa

On Sep 6, 2:23 pm, pow <[EMAIL PROTECTED]> wrote:
> Same requirement here. Need to automate web app testing for chrome. Is
> there an Automation API? Will the Automation API be common for all
> WebKit based browsers?
>
> How does Google test webpages in chrome! On page 9 of Chrome Comic
> Book (http://www.google.com/googlebooks/chrome/), there is a mention
> of ChromeBot. Is it comprehensive? is there an open source project for
> this?
>
> Sai also has posted similar requirement for Automation API 
> athttp://groups.google.com/group/chromium-dev/browse_thread/thread/b2bc...
>
> Thanks,
> pow
>
> On Sep 4, 6:50 pm, Natesh <[EMAIL PROTECTED]> wrote:
>
> > Hi there,
>
> > We use PAMIE to automate the testing of apps developed by our company
> > for IE. We wish to develop a similar light framework to test apps for
> > Chrome. Any pointers or tips in that direction would really help.
>
> > Thanks
--~--~-~--~~~---~--~~
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] code style verification/formatting tool

[Marshall Greenblatt]

Hi All,

Does a tool currently exist for verifying and/or formatting source code
based on the Google style guide?  If not, has any thought been given to
developing such a tool?

Something like lint, but perhaps more modular, would be a great help to
people who don't live and breathe Google style every day.  We could then
augment gcl to check code changes for style violations and warn/assist users
in correcting any problems before the patches are uploaded for code review.

Regards,
Marshall

--~--~-~--~~~---~--~~
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: Add DumpDocumentString() function to webkit_glue

[Marshall Greenblatt]

Hi Darin,

On Wed, Sep 17, 2008 at 10:48 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:

>
> Why not use the view source rendering mode?  There's an API for that
> on WebFrame.


It seems that the view source rendering mode is only for rendering the
source HTML in the web browser?  That's good for a browser that supports
multiple tabs, but perhaps not so good for a single window browser like
test_shell or the eventual embedded application.  Instead, I'm writing the
source to a temporary file and then launching that file in the default text
viewing application.

Regards,
Marshall

--~--~-~--~~~---~--~~
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] Memory leaks in disk_cache (or tests)

[deanm]

Valgrind never lies

==13767== 32,768 bytes in 2 blocks are definitely lost in loss record
5 of 6
==13767==at 0x4C9900F: operator new[](unsigned)
(vg_replace_malloc.c:268)
==13767==by 0x81031D9: disk_cache::EntryImpl::PrepareTarget(int,
int, int, b
ool) (entry_impl.cc:607)
==13767==by 0x8103876: disk_cache::EntryImpl::WriteData(int, int,
char const
*, int, CallbackRunner >*, bool) (entry_impl.cc:302)
==13767==by 0x80B497B: DiskCacheEntryTest::GrowData()
(entry_unittest.cc:431
)
==13767==by 0x80B6EF1:
DiskCacheEntryTest_GrowData_Test::TestBody() (entry_u
nittest.cc:475)
==13767==by 0x8197403: testing::Test::Run() (gtest.cc:1834)
==13767==by 0x819AF12: testing::internal::TestInfoImpl::Run()
(gtest.cc:1999
)
==13767==by 0x819F5B6:
testing::internal::TestInfoImpl::RunTest(testing::Tes
tInfo*) (gtest-internal-inl.h:574)
==13767==by 0x819B716: void
testing::internal::List::ForEach(void (*)(testing::TestInfo*)) const (gtest-
internal-inl.h:335)
==13767==by 0x819AE0C: testing::TestCase::Run() (gtest.cc:2094)
==13767==by 0x819F59A:
testing::TestCase::RunTestCase(testing::TestCase*) (gtest-internal-
inl.h:687)
==13767==by 0x819B582: void
testing::internal::List::ForEach(void (*)(testing::TestCase*)) const (gtest-
internal-inl.h:335)
==13767==
==13767==



==13767== 278,528 bytes in 17 blocks are definitely lost in loss
record 6 of 6
==13767==at 0x4C9900F: operator new[](unsigned)
(vg_replace_malloc.c:268)
==13767==by 0x8101B84:
disk_cache::EntryImpl::MoveToLocalBuffer(int) (entry_impl.cc:671)
==13767==by 0x8102DFB: disk_cache::EntryImpl::GrowUserBuffer(int,
int, int, bool) (entry_impl.cc:630)
==13767==by 0x8103191: disk_cache::EntryImpl::PrepareTarget(int,
int, int, bool) (entry_impl.cc:602)
==13767==by 0x8103876: disk_cache::EntryImpl::WriteData(int, int,
char const*, int, CallbackRunner >*, bool) (entry_impl.cc:
302)
==13767==by 0x80B68EE: DiskCacheEntryTest::GrowData()
(entry_unittest.cc:465)
==13767==by 0x80B6EF1:
DiskCacheEntryTest_GrowData_Test::TestBody() (entry_unittest.cc:475)
==13767==by 0x8197403: testing::Test::Run() (gtest.cc:1834)
==13767==by 0x819AF12: testing::internal::TestInfoImpl::Run()
(gtest.cc:1999)
==13767==by 0x819F5B6:
testing::internal::TestInfoImpl::RunTest(testing::TestInfo*) (gtest-
internal-inl.h:574)
==13767==by 0x819B716: void
testing::internal::List::ForEach(void (*)(testing::TestInfo*)) const (gtest-
internal-inl.h:335)
==13767==by 0x819AE0C: testing::TestCase::Run() (gtest.cc:2094)
==13767==


--~--~-~--~~~---~--~~
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: Chromium Crossover for Mac and Linux.

[Humberto Cruz]

it's stopped my linux machine... i guess that was because de V8 engine
on the wine emulation
[]s


Stephen King  - "French is the language that turns dirt into romance."


On Thu, Sep 18, 2008 at 08:03, defcon <[EMAIL PROTECTED]> wrote:
>
> neat, hopefully a native version will be released because its a little
> slow
>
> On Sep 16, 6:42 am, Paul <[EMAIL PROTECTED]> wrote:
>> Here is a wine version of Chrome for Mac and Linux:
>>
>> http://www.codeweavers.com/services/ports/chromium/
>>
>> It's made by the guys at Crossover.  It's slow, but it works.
> >
>

--~--~-~--~~~---~--~~
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: Suggestion: Chrome Standalone

[ph]

This may help:  (I hope that's what you meant).

Paweł

On Sep 17, 7:18 pm, Milton Segura <[EMAIL PROTECTED]> wrote:
> It would be very useful.
--~--~-~--~~~---~--~~
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: Chromium Crossover for Mac and Linux.

[defcon]

neat, hopefully a native version will be released because its a little
slow

On Sep 16, 6:42 am, Paul <[EMAIL PROTECTED]> wrote:
> Here is a wine version of Chrome for Mac and Linux:
>
> http://www.codeweavers.com/services/ports/chromium/
>
> It's made by the guys at Crossover.  It's slow, but it works.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---