[chromium-dev] Re: Thoughts on copy/paste
I added a comment to the bug describing how we have solved problems like this in the past. -Darin On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman a...@google.com wrote: Working through crbug.com/8384 (copy/paste), I've had a chance to look at Chromium's current copy/paste system. For those unfamiliar, the copy/paste menu items are always enabled, and send a message to TabContents. WebContents implements those methods by forwarding them to RenderViewHost, which forwards them over IPC to the RenderView, which sends them to the focused WebFrame. He sends it to his Editor (finally in WebCore). Having menu items always selected is workable but rather gauche. And in fact, Editor has canCopy(), canPaste(), and a million other can* methods. And reverse-piping it through WebFrame is easy, but it starts getting sticky once you hit IPC. The problem is that we need to update the menu items when asked, which will be when the user pulls down the menu. Issue #1 is latency, just all those round trips over IPC. We could always do a state getting message, where the results of can* are all coalesced. But the bigger issue #2 is blocking, and locking up the UI if the renderer isn't responding/fast. This feels like it should be a solved problem. Any suggestions as to where to look? 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 copy/paste
On Tue, Mar 10, 2009 at 7:44 AM, Avi Drissman a...@google.com wrote: I actually don't know. It seems like just simple state gathering but it might be more. The big concern is that it fits our model but no one else's. Everyone else is OK with the UI asking the renderer questions directly, and as that's more efficient than doing status updates that are going to be ignored 99.44% of the time, I'm not sure they have incentive. I'm not sure what you mean by this. What is everyone OK with? 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: Thoughts on copy/paste
Most platforms (meaning not Chrome) have the ability, when the user pulls down a menu, to adjust the states of the menu items within. For them, when the user selects the Edit menu, they're OK calling into WebCore and asking the Editor canCopy(), canPaste(), etc. We're pretty much the only ones decoupling the UI from WebCore to the extent that we disallow blocking. With that design, we're forced to have WebCore (or at least glue/) bubble up state changes. Compared to just asking WebCore at the time of need, having state change notifications is more inefficient. I think it's worth paying the price. But it might be a harder sell to upstream. Avi On Wed, Mar 11, 2009 at 1:21 PM, Brett Wilson bre...@chromium.org wrote: On Tue, Mar 10, 2009 at 7:44 AM, Avi Drissman a...@google.com wrote: I actually don't know. It seems like just simple state gathering but it might be more. The big concern is that it fits our model but no one else's. Everyone else is OK with the UI asking the renderer questions directly, and as that's more efficient than doing status updates that are going to be ignored 99.44% of the time, I'm not sure they have incentive. I'm not sure what you mean by this. What is everyone OK with? 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: Thoughts on copy/paste
On Wed, Mar 11, 2009 at 10:01 AM, Avi Drissman a...@google.com wrote: Most platforms (meaning not Chrome) have the ability, when the user pulls down a menu, to adjust the states of the menu items within. For them, when the user selects the Edit menu, they're OK calling into WebCore and asking the Editor canCopy(), canPaste(), etc. Do you mean when you click on the menu, blocking the browser until the renderer responds with whether the menus can be enabled? I would be opposed to that. We're pretty much the only ones decoupling the UI from WebCore to the extent that we disallow blocking. With that design, we're forced to have WebCore (or at least glue/) bubble up state changes. Compared to just asking WebCore at the time of need, having state change notifications is more inefficient. I think it's worth paying the price. But it might be a harder sell to upstream. State changes won't fix the problem either. There is no way in the browser to know about the current state of the renderer without one or the other one blocking. State change notifications don't address this problem. 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: Thoughts on copy/paste
On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org wrote: Do you mean when you click on the menu, blocking the browser until the renderer responds with whether the menus can be enabled? I would be opposed to that. So are we, but that's what WebKit currently assumes. That's why we've been trying to brainstorm a way around it. --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: Thoughts on copy/paste
On Wed, Mar 11, 2009 at 10:11 AM, Amanda Walker ama...@chromium.org wrote: On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org wrote: Do you mean when you click on the menu, blocking the browser until the renderer responds with whether the menus can be enabled? I would be opposed to that. So are we, but that's what WebKit currently assumes. That's why we've been trying to brainstorm a way around it. This seems like it is not worth worrying about until the mac browser is as good as the Windows one. We have this bug on Windows, and it's not held anything up so far. 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: Thoughts on copy/paste
On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org wrote: Do you mean when you click on the menu, blocking the browser until the renderer responds with whether the menus can be enabled? I would be opposed to that. Right, that would be bad for us. But for most users of WebCore, such a thing would be fine (since, without process separation, there's a million ways for the renderer to hose the browser, and this is the least of their concerns). State changes won't fix the problem either. There is no way in the browser to know about the current state of the renderer without one or the other one blocking. State change notifications don't address this problem. I fail to see your problem. The renderer sends notifications about its state, and the browser uses the last (cached) value to present its menus as correctly as it can to the user. 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 copy/paste
I'm not trying to turn this into a huge deal. I've already filed a bughttp://crbug.com/8662and am likely to move on for now. But for me it's just another issue that users are going to complain about that I'm going to need to fix someday. Avi /who bets the first complaint will be from a Mac user rather than a Windows one On Wed, Mar 11, 2009 at 2:12 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Mar 11, 2009 at 10:11 AM, Amanda Walker ama...@chromium.org wrote: On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson bre...@chromium.org wrote: Do you mean when you click on the menu, blocking the browser until the renderer responds with whether the menus can be enabled? I would be opposed to that. So are we, but that's what WebKit currently assumes. That's why we've been trying to brainstorm a way around it. This seems like it is not worth worrying about until the mac browser is as good as the Windows one. We have this bug on Windows, and it's not held anything up so far. 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: Thoughts on copy/paste
On Mon, Mar 9, 2009 at 10:12 AM, Avi Drissman a...@google.com wrote: On Mon, Mar 9, 2009 at 12:02 PM, Evan Martin e...@chromium.org wrote: Maybe a better option is to have the renderer send FYI, cut/copy/paste state is now x/y/z messages up to the UI whenever it changes? (I guess paste is out of webkit's hands, but I can imagine other booleans like whether select all should be enabled.) That would make sense, but right now WebCore is set up for the UI to poll rather than push updates. I suppose that glue could know when the state might change, poll WebCore, and push updates, but that's a bit ugly. (Still investigating...) Would changing this be a significant code change? WebKit folk might just be OK with changing it to be push-based. 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 copy/paste
Oh, that's curious. Where does the context menu come from? And how does it know? Avi On Mon, Mar 9, 2009 at 2:04 PM, Adam Barth aba...@google.com wrote: Thanks. I always use our context menu, which seems to be smarter about disabling cut/copy/paste. Adam On Mon, Mar 9, 2009 at 12:00 PM, Evan Martin e...@chromium.org wrote: On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth aba...@chromium.org wrote: On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman a...@google.com wrote: For those unfamiliar, the copy/paste menu items are always enabled, and send a message to TabContents. Do you have an example of how to reproduce this issue? On Windows, the Cut/Copy/Paste menu items are often disabled when they won't work. 1) Change your sound scheme to Windows default. 2) Make sure no text is selected in Chrome. 3) Page menu - copy. Beep! Also beeps if you hit ctl-c while typing. --~--~-~--~~~---~--~~ 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 copy/paste
I'll have to look at that; thanks. In the meanwhile I've come to the unpleasant discovery that ViewHostMsg_ClipboardIsFormatAvailable requires that Clipboard::FormatType be IPC serializable. Time to hack at the Clipboard class. Avi On Mon, Mar 9, 2009 at 3:29 PM, Adam Barth aba...@chromium.org wrote: The context menu does some kind of hit test on the renderer and gets back info about what's under the mouse. I think the IPC message that comes back from the renderer knows whether cut/copy/paste should be enabled. I guess that's evidence that round-tripping through the renderer to get this state might not be that bad for the page menu. Adam On Mon, Mar 9, 2009 at 1:14 PM, Avi Drissman a...@google.com wrote: Oh, that's curious. Where does the context menu come from? And how does it know? Avi On Mon, Mar 9, 2009 at 2:04 PM, Adam Barth aba...@google.com wrote: Thanks. I always use our context menu, which seems to be smarter about disabling cut/copy/paste. Adam On Mon, Mar 9, 2009 at 12:00 PM, Evan Martin e...@chromium.org wrote: On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth aba...@chromium.org wrote: On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman a...@google.com wrote: For those unfamiliar, the copy/paste menu items are always enabled, and send a message to TabContents. Do you have an example of how to reproduce this issue? On Windows, the Cut/Copy/Paste menu items are often disabled when they won't work. 1) Change your sound scheme to Windows default. 2) Make sure no text is selected in Chrome. 3) Page menu - copy. Beep! Also beeps if you hit ctl-c while typing. --~--~-~--~~~---~--~~ 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 copy/paste
1) the user right clicks on the page 2) the browser sends an IPC to the renderer with the click event 3) the renderer realizes that a context menu should show and sends an IPC back to the browser with information about which menu items should be enabled. In theory, this is the same as sending an IPC when we show the page menu, but the main differences is that the context menu ipcs are all async. You could imagine that we enable cut/copy/paste as we show the page menu, send an async request to see if the menu items should be enabled, and update the menu items async. This might flicker sometimes, but maybe that's ok? Alternately, we could delay showing the page menu until the page responds (like how context menus work). However, a hung/slow page would cause the menu to never appear, but maybe that's ok because all the menu items depend on the page anyway (if it hangs, we could replace the menu with a kill tab menu item). On Mon, 9 Mar 2009, Adam Barth wrote: The context menu does some kind of hit test on the renderer and gets back info about what's under the mouse. I think the IPC message that comes back from the renderer knows whether cut/copy/paste should be enabled. I guess that's evidence that round-tripping through the renderer to get this state might not be that bad for the page menu. Adam On Mon, Mar 9, 2009 at 1:14 PM, Avi Drissman a...@google.com wrote: Oh, that's curious. Where does the context menu come from? And how does it know? Avi On Mon, Mar 9, 2009 at 2:04 PM, Adam Barth aba...@google.com wrote: Thanks. I always use our context menu, which seems to be smarter about disabling cut/copy/paste. Adam On Mon, Mar 9, 2009 at 12:00 PM, Evan Martin e...@chromium.org wrote: On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth aba...@chromium.org wrote: On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman a...@google.com wrote: For those unfamiliar, the copy/paste menu items are always enabled, and send a message to TabContents. Do you have an example of how to reproduce this issue? On Windows, the Cut/Copy/Paste menu items are often disabled when they won't work. 1) Change your sound scheme to Windows default. 2) Make sure no text is selected in Chrome. 3) Page menu - copy. Beep! Also beeps if you hit ctl-c while typing. --~--~-~--~~~---~--~~ 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 copy/paste
Forgive my ignorance of Mac APIs, but why does the mouse click - display menu need to be synchronous? (In a way similar to how the right-click - context menu is async now.) Adam On Mon, Mar 9, 2009 at 2:39 PM, Avi Drissman a...@google.com wrote: An async menu might be an option for WinChromium but it isn't an option for the Mac version if we want to use system menus. (And no, that wasn't an opening for anyone to say that we shouldn't use the system menus on the Mac...) Avi On Mon, Mar 9, 2009 at 4:31 PM, Adam Barth aba...@chromium.org wrote: I think we should show the menu asynchronously after roundtripping the renderer to get the necessary state. We can solve the hung renderer problem with a timeout. I like the idea of a kill page menu if the page doesn't respond in time because the page menu is mostly useless if the page is hung. Adam On Mon, Mar 9, 2009 at 2:19 PM, t...@chromium.org wrote: 1) the user right clicks on the page 2) the browser sends an IPC to the renderer with the click event 3) the renderer realizes that a context menu should show and sends an IPC back to the browser with information about which menu items should be enabled. In theory, this is the same as sending an IPC when we show the page menu, but the main differences is that the context menu ipcs are all async. You could imagine that we enable cut/copy/paste as we show the page menu, send an async request to see if the menu items should be enabled, and update the menu items async. This might flicker sometimes, but maybe that's ok? Alternately, we could delay showing the page menu until the page responds (like how context menus work). However, a hung/slow page would cause the menu to never appear, but maybe that's ok because all the menu items depend on the page anyway (if it hangs, we could replace the menu with a kill tab menu item). On Mon, 9 Mar 2009, Adam Barth wrote: The context menu does some kind of hit test on the renderer and gets back info about what's under the mouse. I think the IPC message that comes back from the renderer knows whether cut/copy/paste should be enabled. I guess that's evidence that round-tripping through the renderer to get this state might not be that bad for the page menu. Adam On Mon, Mar 9, 2009 at 1:14 PM, Avi Drissman a...@google.com wrote: Oh, that's curious. Where does the context menu come from? And how does it know? Avi On Mon, Mar 9, 2009 at 2:04 PM, Adam Barth aba...@google.com wrote: Thanks. I always use our context menu, which seems to be smarter about disabling cut/copy/paste. Adam On Mon, Mar 9, 2009 at 12:00 PM, Evan Martin e...@chromium.org wrote: On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth aba...@chromium.org wrote: On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman a...@google.com wrote: For those unfamiliar, the copy/paste menu items are always enabled, and send a message to TabContents. Do you have an example of how to reproduce this issue? On Windows, the Cut/Copy/Paste menu items are often disabled when they won't work. 1) Change your sound scheme to Windows default. 2) Make sure no text is selected in Chrome. 3) Page menu - copy. Beep! Also beeps if you hit ctl-c while typing. --~--~-~--~~~---~--~~ 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 copy/paste
Because we don't see the mouse click for the main menu bar the same way we do for a context menu. Normally, we just get called back after a menu item has been selected. It's possible to update state while the menu is down, but that brings in the possibility of flashing/etc. as the menu changes state under the mouse, which is bad. If there's a way that the browser process can shadow the most recent clipboard state of the current renderer, that would be ideal. --Amanda On Mon, Mar 9, 2009 at 5:48 PM, Adam Barth aba...@chromium.org wrote: Forgive my ignorance of Mac APIs, but why does the mouse click - display menu need to be synchronous? (In a way similar to how the right-click - context menu is async now.) Adam On Mon, Mar 9, 2009 at 2:39 PM, Avi Drissman a...@google.com wrote: An async menu might be an option for WinChromium but it isn't an option for the Mac version if we want to use system menus. (And no, that wasn't an opening for anyone to say that we shouldn't use the system menus on the Mac...) Avi On Mon, Mar 9, 2009 at 4:31 PM, Adam Barth aba...@chromium.org wrote: I think we should show the menu asynchronously after roundtripping the renderer to get the necessary state. We can solve the hung renderer problem with a timeout. I like the idea of a kill page menu if the page doesn't respond in time because the page menu is mostly useless if the page is hung. Adam On Mon, Mar 9, 2009 at 2:19 PM, t...@chromium.org wrote: 1) the user right clicks on the page 2) the browser sends an IPC to the renderer with the click event 3) the renderer realizes that a context menu should show and sends an IPC back to the browser with information about which menu items should be enabled. In theory, this is the same as sending an IPC when we show the page menu, but the main differences is that the context menu ipcs are all async. You could imagine that we enable cut/copy/paste as we show the page menu, send an async request to see if the menu items should be enabled, and update the menu items async. This might flicker sometimes, but maybe that's ok? Alternately, we could delay showing the page menu until the page responds (like how context menus work). However, a hung/slow page would cause the menu to never appear, but maybe that's ok because all the menu items depend on the page anyway (if it hangs, we could replace the menu with a kill tab menu item). On Mon, 9 Mar 2009, Adam Barth wrote: The context menu does some kind of hit test on the renderer and gets back info about what's under the mouse. I think the IPC message that comes back from the renderer knows whether cut/copy/paste should be enabled. I guess that's evidence that round-tripping through the renderer to get this state might not be that bad for the page menu. Adam On Mon, Mar 9, 2009 at 1:14 PM, Avi Drissman a...@google.com wrote: Oh, that's curious. Where does the context menu come from? And how does it know? Avi On Mon, Mar 9, 2009 at 2:04 PM, Adam Barth aba...@google.com wrote: Thanks. I always use our context menu, which seems to be smarter about disabling cut/copy/paste. Adam On Mon, Mar 9, 2009 at 12:00 PM, Evan Martin e...@chromium.org wrote: On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth aba...@chromium.org wrote: On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman a...@google.com wrote: For those unfamiliar, the copy/paste menu items are always enabled, and send a message to TabContents. Do you have an example of how to reproduce this issue? On Windows, the Cut/Copy/Paste menu items are often disabled when they won't work. 1) Change your sound scheme to Windows default. 2) Make sure no text is selected in Chrome. 3) Page menu - copy. Beep! Also beeps if you hit ctl-c while typing. --~--~-~--~~~---~--~~ 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 copy/paste
Right. That involves some magic on the renderer side, probably polling WebCore for state after operations known to change it. Currently, WebCore isn't really set up for sending copy/paste state changes. Avi On Mon, Mar 9, 2009 at 4:55 PM, Amanda Walker ama...@chromium.org wrote: Because we don't see the mouse click for the main menu bar the same way we do for a context menu. Normally, we just get called back after a menu item has been selected. It's possible to update state while the menu is down, but that brings in the possibility of flashing/etc. as the menu changes state under the mouse, which is bad. If there's a way that the browser process can shadow the most recent clipboard state of the current renderer, that would be ideal. --Amanda On Mon, Mar 9, 2009 at 5:48 PM, Adam Barth aba...@chromium.org wrote: Forgive my ignorance of Mac APIs, but why does the mouse click - display menu need to be synchronous? (In a way similar to how the right-click - context menu is async now.) Adam On Mon, Mar 9, 2009 at 2:39 PM, Avi Drissman a...@google.com wrote: An async menu might be an option for WinChromium but it isn't an option for the Mac version if we want to use system menus. (And no, that wasn't an opening for anyone to say that we shouldn't use the system menus on the Mac...) Avi On Mon, Mar 9, 2009 at 4:31 PM, Adam Barth aba...@chromium.org wrote: I think we should show the menu asynchronously after roundtripping the renderer to get the necessary state. We can solve the hung renderer problem with a timeout. I like the idea of a kill page menu if the page doesn't respond in time because the page menu is mostly useless if the page is hung. Adam On Mon, Mar 9, 2009 at 2:19 PM, t...@chromium.org wrote: 1) the user right clicks on the page 2) the browser sends an IPC to the renderer with the click event 3) the renderer realizes that a context menu should show and sends an IPC back to the browser with information about which menu items should be enabled. In theory, this is the same as sending an IPC when we show the page menu, but the main differences is that the context menu ipcs are all async. You could imagine that we enable cut/copy/paste as we show the page menu, send an async request to see if the menu items should be enabled, and update the menu items async. This might flicker sometimes, but maybe that's ok? Alternately, we could delay showing the page menu until the page responds (like how context menus work). However, a hung/slow page would cause the menu to never appear, but maybe that's ok because all the menu items depend on the page anyway (if it hangs, we could replace the menu with a kill tab menu item). On Mon, 9 Mar 2009, Adam Barth wrote: The context menu does some kind of hit test on the renderer and gets back info about what's under the mouse. I think the IPC message that comes back from the renderer knows whether cut/copy/paste should be enabled. I guess that's evidence that round-tripping through the renderer to get this state might not be that bad for the page menu. Adam On Mon, Mar 9, 2009 at 1:14 PM, Avi Drissman a...@google.com wrote: Oh, that's curious. Where does the context menu come from? And how does it know? Avi On Mon, Mar 9, 2009 at 2:04 PM, Adam Barth aba...@google.com wrote: Thanks. I always use our context menu, which seems to be smarter about disabling cut/copy/paste. Adam On Mon, Mar 9, 2009 at 12:00 PM, Evan Martin e...@chromium.org wrote: On Mon, Mar 9, 2009 at 11:43 AM, Adam Barth aba...@chromium.org wrote: On Mon, Mar 9, 2009 at 9:53 AM, Avi Drissman a...@google.com wrote: For those unfamiliar, the copy/paste menu items are always enabled, and send a message to TabContents. Do you have an example of how to reproduce this issue? On Windows, the Cut/Copy/Paste menu items are often disabled when they won't work. 1) Change your sound scheme to Windows default. 2) Make sure no text is selected in Chrome. 3) Page menu - copy. Beep! Also beeps if you hit ctl-c while typing. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
