[chromium-dev] Burned out trying to do SendWithTimeout
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] 2.0.169.1 released to the dev channel
We just pushed the Omaha config changes for 2.0.169.1 to become the new dev channel release. Thank you to everyone for your hard work! Jon --~--~-~--~~~---~--~~ 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: Burned out trying to do SendWithTimeout
It is really complicated. I don't think we should work on this now. Let's get the rest of the high priority work out of the way, and then return to this. -Darin 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: Burned out trying to do SendWithTimeout
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] [extensions] Design doc: API pattern proposal
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] StatusBubble?
Is anyone doing StatusBubble on the Mac? If not, I claim it. 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: [extensions] Design doc: API pattern proposal
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: [extensions] Design doc: API pattern proposal
Why put all the methods in the global scope instead of on objects (e.g. ChromeBookmarks.getAll())? Ojan 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] Status Bubble GTK?
Evan— I was looking at StatusBubbleGtk to get some thoughts about the Mac one, and I saw your note that you were probably taking the wrong approach. What do you mean by that? In what sense? 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: [extensions] Design doc: API pattern proposal
On Thu, Mar 12, 2009 at 1:57 PM, Ojan Vafai wrote: > Why put all the methods in the global scope instead of on objects (e.g. > ChromeBookmarks.getAll())? They are on objects: The proposal is, eg: window.extensions.bookmarks.getAllBookmarks() (getAll() would work too). The reason to not put them on the Bookmark struct is that the core idea is the difference between a service-style API and an OO-style API. In the service-style API, the objects are just data. - 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: Status Bubble GTK?
Basically, what I wrote was a quick hack just because I was tired of not seeing where links go, and someone will need to think about harder what exact kinds of behaviors we want. I don't exactly understand how it works on windows, except that the status bubble can slide out of the main window which (at least in the X world) means it's not a child of the top-level window. On X I don't believe (though I'm no expert) we can control new windows to enough degree to make the positioning of a new window in a way that doesn't make it janky. Because of this, I suspect the right way to do it is to make the status bubble a child of the main window, and drop the "pop out of the main window" behavior, or to special-case it when you move the mouse over it but pop it back in if you start dragging the window. In any case, what I have done (a popup window that appears topmost) is not what I think we want. On Thu, Mar 12, 2009 at 1:57 PM, Avi Drissman wrote: > Evan— > > I was looking at StatusBubbleGtk to get some thoughts about the Mac one, and > I saw your note that you were probably taking the wrong approach. What do > you mean by that? In what sense? > > 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: Status Bubble GTK?
this seems wrong. surely you can create a top-level window that has no window decorations. then you can just position that however you like. is the problem with managing the z-order? -darin On Thu, Mar 12, 2009 at 2:11 PM, Evan Martin wrote: > > Basically, what I wrote was a quick hack just because I was tired of > not seeing where links go, and someone will need to think about harder > what exact kinds of behaviors we want. > > I don't exactly understand how it works on windows, except that the > status bubble can slide out of the main window which (at least in the > X world) means it's not a child of the top-level window. On X I don't > believe (though I'm no expert) we can control new windows to enough > degree to make the positioning of a new window in a way that doesn't > make it janky. > > Because of this, I suspect the right way to do it is to make the > status bubble a child of the main window, and drop the "pop out of the > main window" behavior, or to special-case it when you move the mouse > over it but pop it back in if you start dragging the window. In any > case, what I have done (a popup window that appears topmost) is not > what I think we want. > > On Thu, Mar 12, 2009 at 1:57 PM, Avi Drissman wrote: > > Evan— > > > > I was looking at StatusBubbleGtk to get some thoughts about the Mac one, > and > > I saw your note that you were probably taking the wrong approach. What do > > you mean by that? In what sense? > > > > 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: Status Bubble GTK?
OK. I'm going to do it on the Mac as a child window, so it'll be bound to the parent but still independent in positioning. Sounds like that plan is fine. Thanks, Avi On Thu, Mar 12, 2009 at 5:11 PM, Evan Martin wrote: > Basically, what I wrote was a quick hack just because I was tired of > not seeing where links go, and someone will need to think about harder > what exact kinds of behaviors we want. > > I don't exactly understand how it works on windows, except that the > status bubble can slide out of the main window which (at least in the > X world) means it's not a child of the top-level window. On X I don't > believe (though I'm no expert) we can control new windows to enough > degree to make the positioning of a new window in a way that doesn't > make it janky. > > Because of this, I suspect the right way to do it is to make the > status bubble a child of the main window, and drop the "pop out of the > main window" behavior, or to special-case it when you move the mouse > over it but pop it back in if you start dragging the window. In any > case, what I have done (a popup window that appears topmost) is not > what I think we want. > > On Thu, Mar 12, 2009 at 1:57 PM, Avi Drissman wrote: > > Evan— > > > > I was looking at StatusBubbleGtk to get some thoughts about the Mac one, > and > > I saw your note that you were probably taking the wrong approach. What do > > you mean by that? In what sense? > > > > 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: Status Bubble GTK?
Yes, though I only played around with it a bit. The window can be either a normal top-level window (in which case the window manager tries to manage it, especially in the tiling situation) or a popup. It seems popups want to be topmost, though I'm not certain about it. On Thu, Mar 12, 2009 at 2:13 PM, Darin Fisher wrote: > this seems wrong. surely you can create a top-level window that has no > window decorations. then you can just position that however you like. is > the problem with managing the z-order? > -darin > > > On Thu, Mar 12, 2009 at 2:11 PM, Evan Martin wrote: >> >> Basically, what I wrote was a quick hack just because I was tired of >> not seeing where links go, and someone will need to think about harder >> what exact kinds of behaviors we want. >> >> I don't exactly understand how it works on windows, except that the >> status bubble can slide out of the main window which (at least in the >> X world) means it's not a child of the top-level window. On X I don't >> believe (though I'm no expert) we can control new windows to enough >> degree to make the positioning of a new window in a way that doesn't >> make it janky. >> >> Because of this, I suspect the right way to do it is to make the >> status bubble a child of the main window, and drop the "pop out of the >> main window" behavior, or to special-case it when you move the mouse >> over it but pop it back in if you start dragging the window. In any >> case, what I have done (a popup window that appears topmost) is not >> what I think we want. >> >> On Thu, Mar 12, 2009 at 1:57 PM, Avi Drissman wrote: >> > Evan— >> > >> > I was looking at StatusBubbleGtk to get some thoughts about the Mac one, >> > and >> > I saw your note that you were probably taking the wrong approach. What >> > do >> > you mean by that? In what sense? >> > >> > 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: Status Bubble GTK?
I see... there has to be a way with window manager hints to make this work :-) Anyways, this isn't the most important thing to worry about now, but it sure is sad to lose out on such a cool feature of Chrome (that the status bar won't obscure what the mouse is over). -Darin On Thu, Mar 12, 2009 at 2:17 PM, Evan Martin wrote: > Yes, though I only played around with it a bit. The window can be > either a normal top-level window (in which case the window manager > tries to manage it, especially in the tiling situation) or a popup. > It seems popups want to be topmost, though I'm not certain about it. > > On Thu, Mar 12, 2009 at 2:13 PM, Darin Fisher wrote: > > this seems wrong. surely you can create a top-level window that has no > > window decorations. then you can just position that however you like. > is > > the problem with managing the z-order? > > -darin > > > > > > On Thu, Mar 12, 2009 at 2:11 PM, Evan Martin wrote: > >> > >> Basically, what I wrote was a quick hack just because I was tired of > >> not seeing where links go, and someone will need to think about harder > >> what exact kinds of behaviors we want. > >> > >> I don't exactly understand how it works on windows, except that the > >> status bubble can slide out of the main window which (at least in the > >> X world) means it's not a child of the top-level window. On X I don't > >> believe (though I'm no expert) we can control new windows to enough > >> degree to make the positioning of a new window in a way that doesn't > >> make it janky. > >> > >> Because of this, I suspect the right way to do it is to make the > >> status bubble a child of the main window, and drop the "pop out of the > >> main window" behavior, or to special-case it when you move the mouse > >> over it but pop it back in if you start dragging the window. In any > >> case, what I have done (a popup window that appears topmost) is not > >> what I think we want. > >> > >> On Thu, Mar 12, 2009 at 1:57 PM, Avi Drissman wrote: > >> > Evan— > >> > > >> > I was looking at StatusBubbleGtk to get some thoughts about the Mac > one, > >> > and > >> > I saw your note that you were probably taking the wrong approach. What > >> > do > >> > you mean by that? In what sense? > >> > > >> > 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: Status Bubble GTK?
On Thu, Mar 12, 2009 at 2:34 PM, Darin Fisher wrote: > Anyways, this isn't the most important thing to worry about now, but it > sure is sad to lose out on such a cool feature of Chrome (that the status > bar won't obscure what the mouse is over). > It's easy to make that happen, you just slide the status bar into the bottom of the window. True, you miss the ability to slide it out of the window altogether, but that's a minor loss (and for maximized-mode/fullscreen users, no loss at all). 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: Status Bubble GTK?
On Thu, Mar 12, 2009 at 2:34 PM, Darin Fisher wrote: > I see... there has to be a way with window manager hints to make this work > :-) I hope so, too. I played around with it for a while in a test app, and then decided that doing it Right was going to be a lot of effort and I'd be better off fixing gaping holes than polishing this. I made it extra-ugly just so nobody would take it too seriously. We might be getting a 20% who's written a window manager before; I was trying to interest him in this problem as a starter project. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] windowless plugin drawing
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: windowless plugin drawing
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] Chrome was on Jeopardy tonight
Thought I let you guys know. Amazing! Daniel A. White --~--~-~--~~~---~--~~ 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: Chrome was on Jeopardy tonight
Congratulations on entering the zeitgeist! It's certainly an exciting time for web browsers and the web. cheers, mike - Original Message - From: chromium-dev@googlegroups.com To: Chromium-dev Sent: Thu Mar 12 16:55:41 2009 Subject: [chromium-dev] Chrome was on Jeopardy tonight Thought I let you guys know. Amazing! Daniel A. White --~--~-~--~~~---~--~~ 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: Chrome was on Jeopardy tonight
On Thu, Mar 12, 2009 at 4:55 PM, Daniel A. White wrote: > Thought I let you guys know. Amazing! What was the answer? (I'm assuming the question was "What is Google Chrome?") 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: Chrome was on Jeopardy tonight
If I remember it was like "This Internet giant's Web browser has Incognito which allows users to surf anonymously". The first guy to ring in said "What is Yahoo!?" Sorry. Daniel A. White On Thu, Mar 12, 2009 at 8:40 PM, Peter Kasting wrote: > On Thu, Mar 12, 2009 at 4:55 PM, Daniel A. White > wrote: > >> Thought I let you guys know. Amazing! > > > What was the answer? (I'm assuming the question was "What is Google > Chrome?") > > 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: Chrome was on Jeopardy tonight
On Thu, Mar 12, 2009 at 6:02 PM, Daniel A. White wrote: > If I remember it was like "This Internet giant's Web browser has Incognito > which allows users to surf anonymously". The first guy to ring in said "What > is Yahoo!?" Sorry. Heh. Sucks that they got the function of Incognito mode absolutely backwards (you certainly aren't anonymous). 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: Chrome was on Jeopardy tonight
Well in the category they really tried mixing DirectX and having some way of explaining "What is ActiveX?" that I didn't get. Daniel A. White On Thu, Mar 12, 2009 at 9:04 PM, Peter Kasting wrote: > On Thu, Mar 12, 2009 at 6:02 PM, Daniel A. White > wrote: > >> If I remember it was like "This Internet giant's Web browser has Incognito >> which allows users to surf anonymously". The first guy to ring in said "What >> is Yahoo!?" Sorry. > > > Heh. Sucks that they got the function of Incognito mode absolutely > backwards (you certainly aren't anonymous). > > PK > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
