On Wed, Sep 17, 2008 at 8:06 PM, Dan Kegel [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher [EMAIL PROTECTED] wrote:
One more data point: we'll also need to support SSL over SOCKS one
day, and that means that the ClientSocket passed to SSLClientSocket
will not be a
On Wed, Sep 17, 2008 at 11:52 PM, Darin Fisher [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 8:06 PM, Dan Kegel [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher [EMAIL PROTECTED] wrote:
One more data point: we'll also need to support SSL over SOCKS one
day, and that
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?
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
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
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/
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
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
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
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
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
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
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
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.
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
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 cairo.h, which picks up our
webkit/port/platform/cairo.h , which begins with this comment:
// We compile WebKit with PLATFORM(CAIRO) defined.
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
17 matches
Mail list logo
