[webkit-dev] Calling all committers: The pending-commit list is overflowing
We have 43 patches that have been reviewed and are waiting to land: http://webblaze.org/pending-commit If you're a committer, you can help drive that number to zero. Here's what you can do: 1) If you have a patch on that list, please land it. 2) If you see a patch on the list that's ready to land (almost all of them), you can mark it commit-queue+ to have the commit bot land it. When you do this, please be sure to watch the tree for regressions, just like you would if you typed svn commit yourself. Thanks and happy WebKitting, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling all committers: The pending-commit list is overflowing
Mark correctly points out that I meant: http://webkit.org/pending-commit (webblaze.org is my server for running experiments.) Adam On Sun, Oct 18, 2009 at 11:34 PM, Adam Barth aba...@webkit.org wrote: We have 43 patches that have been reviewed and are waiting to land: http://webblaze.org/pending-commit If you're a committer, you can help drive that number to zero. Here's what you can do: 1) If you have a patch on that list, please land it. 2) If you see a patch on the list that's ready to land (almost all of them), you can mark it commit-queue+ to have the commit bot land it. When you do this, please be sure to watch the tree for regressions, just like you would if you typed svn commit yourself. Thanks and happy WebKitting, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling all committers: The pending-commit list isoverflowing
- Original Message - From: Adam Barth aba...@webkit.org To: webkit-dev@lists.webkit.org Sent: Monday, October 19, 2009 3:21 AM Subject: Re: [webkit-dev] Calling all committers: The pending-commit list isoverflowing If you're a committer, you can help drive that number to zero. Here's what you can do: 1) If you have a patch on that list, please land it. 2) If you see a patch on the list that's ready to land (almost all of them), you can mark it commit-queue+ to have the commit bot land it. When you do this, please be sure to watch the tree for regressions, just like you would if you typed svn commit yourself. I got this: You are not authorized to edit this patch. Thanks and happy WebKitting, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling all committers: The pending-commit list isoverflowing
I'm able to do it now. Thanks. -Yong - Original Message - From: Eric Seidel esei...@google.com To: Yong Li yong...@torchmobile.com Cc: Adam Barth aba...@webkit.org; webkit-dev@lists.webkit.org Sent: Monday, October 19, 2009 11:33 AM Subject: Re: [webkit-dev] Calling all committers: The pending-commit list isoverflowing yong...@torchmobile.com did not have Edit Bugs privileges in bugzilla's database. I've fixed that. You should be able to set flags now. On Mon, Oct 19, 2009 at 8:25 AM, Yong Li yong...@torchmobile.com wrote: - Original Message - From: Adam Barth aba...@webkit.org To: webkit-dev@lists.webkit.org Sent: Monday, October 19, 2009 3:21 AM Subject: Re: [webkit-dev] Calling all committers: The pending-commit list isoverflowing If you're a committer, you can help drive that number to zero. Here's what you can do: 1) If you have a patch on that list, please land it. 2) If you see a patch on the list that's ready to land (almost all of them), you can mark it commit-queue+ to have the commit bot land it. When you do this, please be sure to watch the tree for regressions, just like you would if you typed svn commit yourself. I got this: You are not authorized to edit this patch. Thanks and happy WebKitting, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling all committers: The pending-commit list is overflowing
On Sun, Oct 18, 2009 at 11:34 PM, Adam Barth aba...@webkit.org wrote: 2) If you see a patch on the list that's ready to land (almost all of them), you can mark it commit-queue+ to have the commit bot land it. When you do this, please be sure to watch the tree for regressions, just like you would if you typed svn commit yourself. FYI, if you're using commit-queue+, you should know about: http://webkit-commit-queue.appspot.com/ which gives you a little window into commit-queue's tiny brain. Eventually I hope to move that to http://commit.webkit.org/ or something easier to remember. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Oct 16, 2009, at 7:07 PM, Evan Martin wrote: When you select multiple lines of text in WebKit, the highlight paints over whitespace on the right margin. This is correct behavior for Mac, but not for Windows or Linux. I would suggest making it be controlled by a Setting rather than #ifdefs. I thought one existed already, but if it doesn't, we can add one. Another possibility might be using the theme to query for this info, although I know we would like to preserve the gap painting on Safari for Windows. Therefore a Setting is probably best. Keep in mind that eliminating the gaps will give you a pretty ugly irregular selection in a lot of places. Do what you want in Chrome, but make sure it's a setting and that you don't change Safari for Windows in the process. Thanks, dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
I agree. I would like to retain this mode of selection in Windows Chrome at least. I think it's only ragged in most apps because people don't take the time to make it look nice. -Ben On Mon, Oct 19, 2009 at 12:57 PM, David Hyatt hy...@apple.com wrote: On Oct 16, 2009, at 7:07 PM, Evan Martin wrote: When you select multiple lines of text in WebKit, the highlight paints over whitespace on the right margin. This is correct behavior for Mac, but not for Windows or Linux. I would suggest making it be controlled by a Setting rather than #ifdefs. I thought one existed already, but if it doesn't, we can add one. Another possibility might be using the theme to query for this info, although I know we would like to preserve the gap painting on Safari for Windows. Therefore a Setting is probably best. Keep in mind that eliminating the gaps will give you a pretty ugly irregular selection in a lot of places. Do what you want in Chrome, but make sure it's a setting and that you don't change Safari for Windows in the process. Thanks, dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
FYI, this was filed some time ago: http://code.google.com/p/chromium/issues/detail?id=3527 https://bugs.webkit.org/show_bug.cgi?id=21960 On Mon, Oct 19, 2009 at 1:03 PM, Ben Goodger b...@google.com wrote: I agree. I would like to retain this mode of selection in Windows Chrome at least. I think it's only ragged in most apps because people don't take the time to make it look nice. -Ben On Mon, Oct 19, 2009 at 12:57 PM, David Hyatt hy...@apple.com wrote: On Oct 16, 2009, at 7:07 PM, Evan Martin wrote: When you select multiple lines of text in WebKit, the highlight paints over whitespace on the right margin. This is correct behavior for Mac, but not for Windows or Linux. I would suggest making it be controlled by a Setting rather than #ifdefs. I thought one existed already, but if it doesn't, we can add one. Another possibility might be using the theme to query for this info, although I know we would like to preserve the gap painting on Safari for Windows. Therefore a Setting is probably best. Keep in mind that eliminating the gaps will give you a pretty ugly irregular selection in a lot of places. Do what you want in Chrome, but make sure it's a setting and that you don't change Safari for Windows in the process. Thanks, dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
To me, it looks ugly to have a ragged edge if you can avoid it. Dave did a great job making it look nice in WebKit. I don't have a strong feeling on Linux so if people feel strongly there whatever. But on Windows Chrome I want to retain the solid edge. Maybe there are ways the solid edge can be improved, folk should investigate that rather than just disabling it. -Ben On Mon, Oct 19, 2009 at 1:08 PM, Jeremy Orlow jor...@chromium.org wrote: FYI, this was filed some time ago: http://code.google.com/p/chromium/issues/detail?id=3527 https://bugs.webkit.org/show_bug.cgi?id=21960 On Mon, Oct 19, 2009 at 1:03 PM, Ben Goodger b...@google.com wrote: I agree. I would like to retain this mode of selection in Windows Chrome at least. I think it's only ragged in most apps because people don't take the time to make it look nice. -Ben On Mon, Oct 19, 2009 at 12:57 PM, David Hyatt hy...@apple.com wrote: On Oct 16, 2009, at 7:07 PM, Evan Martin wrote: When you select multiple lines of text in WebKit, the highlight paints over whitespace on the right margin. This is correct behavior for Mac, but not for Windows or Linux. I would suggest making it be controlled by a Setting rather than #ifdefs. I thought one existed already, but if it doesn't, we can add one. Another possibility might be using the theme to query for this info, although I know we would like to preserve the gap painting on Safari for Windows. Therefore a Setting is probably best. Keep in mind that eliminating the gaps will give you a pretty ugly irregular selection in a lot of places. Do what you want in Chrome, but make sure it's a setting and that you don't change Safari for Windows in the process. Thanks, dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:10 PM, David Hyatt hy...@apple.com wrote: I can get how editing in text fields you might feel a desire to match the platform (where ragged selection may be the convention), but once you get into rich text selection (images, floats, tables, columns, etc.), there really is no platform precedent. Other browsers just kind of lazily include a few more objects like images and call it a day. We tried to do better than that. I've actually been super frustrated with WebKit's selection behavior for a long time, precisely because it tries to let you select everything. In Firefox, in most cases* you just select the text out of a page, which is pretty much always what I want. In Chrome I find that I'm always managing to select an entire page or entire table or various other things when I'm just trying to get the text out of it. Darin (Fisher) has also complained to me about this in the past Combined with this frustration, not having the Windows-standard edge on text selection makes it hard for me to tell what I have selected. The net effect is that selecting things in Chrome has driven me insane for several years now. Therefore I'm strongly in favor of reducing what Chrome will actually let you select, as well as eliminating the gaps. *: Haven't tested the edge cases in a while PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:13 PM, Ben Goodger b...@google.com wrote: To me, it looks ugly to have a ragged edge if you can avoid it. Dave did a great job making it look nice in WebKit. I don't have a strong feeling on Linux so if people feel strongly there whatever. But on Windows Chrome I want to retain the solid edge. Maybe there are ways the solid edge can be improved, folk should investigate that rather than just disabling it. The main reason I brought it up was seeing complaints online about the behavior (I guess the bug in the Chrome BTS shows it's weird to at least someone) and it was also weird to me. On Windows, notepad, Visual Studio, Windows mail, and IE: do ragged-edge selection. I am not able to find an app that doesn't but I wasn't looking too hard. On Linux: Firefox and Qt apps seem to do ragged-edge, GTK apps do Mac-style. If we're consciously deciding to diverge from platform behavior, I'm ok with not changing anything. I guess my expectation was set by Firefox, but I don't feel too strongly about it. I will close the Chrome bug wontfix. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Oct 19, 2009, at 3:19 PM, Peter Kasting wrote: On Mon, Oct 19, 2009 at 1:10 PM, David Hyatt hy...@apple.com wrote: I can get how editing in text fields you might feel a desire to match the platform (where ragged selection may be the convention), but once you get into rich text selection (images, floats, tables, columns, etc.), there really is no platform precedent. Other browsers just kind of lazily include a few more objects like images and call it a day. We tried to do better than that. I've actually been super frustrated with WebKit's selection behavior for a long time, precisely because it tries to let you select everything. In Firefox, in most cases* you just select the text out of a page, which is pretty much always what I want. In Chrome I find that I'm always managing to select an entire page or entire table or various other things when I'm just trying to get the text out of it. Darin (Fisher) has also complained to me about this in the past I'm not quite sure what you mean. Do you just mean it looks visually confusing, but when you copy/paste you get the right text? Or are you saying that it's actually selecting the wrong things? The gaps are a purely visual phenomenon, and they don't affect what gets copied... if you're seeing the wrong stuff get copied, then that won't be fixed by a setting to stop painting gaps. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Oct 19, 2009, at 3:19 PM, Peter Kasting wrote: On Mon, Oct 19, 2009 at 1:10 PM, David Hyatt hy...@apple.com wrote: I can get how editing in text fields you might feel a desire to match the platform (where ragged selection may be the convention), but once you get into rich text selection (images, floats, tables, columns, etc.), there really is no platform precedent. Other browsers just kind of lazily include a few more objects like images and call it a day. We tried to do better than that. I've actually been super frustrated with WebKit's selection behavior for a long time, precisely because it tries to let you select everything. In Firefox, in most cases* you just select the text out of a page, which is pretty much always what I want. In Chrome I find that I'm always managing to select an entire page or entire table or various other things when I'm just trying to get the text out of it. Darin (Fisher) has also complained to me about this in the past Concrete examples of where something weird happens would be helpful. The gap code is obviously not perfect and so there's plenty of room for improving it, which will help out Chrome on Mac users even if Chrome on Windows goes to a different style of behavior. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:21 PM, David Hyatt hy...@apple.com wrote: On Oct 19, 2009, at 3:19 PM, Peter Kasting wrote: I'm not quite sure what you mean. Do you just mean it looks visually confusing, but when you copy/paste you get the right text? Or are you saying that it's actually selecting the wrong things? There are two different effects that interrelate: * WebKit allows you to select anything on a page. Repro: Go to any page, start at top, drag down, note that you select everything. Desired behavior: Only select the text from the page. * Lack of gaps on text selection. This is only a visual artifact, but it can make it trickier to tell that you've just selected text, as opposed to a containing object. Increases the frustration of the above bullet point. Fixing point 2 alone would make it easier to tell when point 1 is tripping things up, because it would make it easier in general to determine what is selected. It would also feel far less strange given that, as Evan said, this is how selection works on Windows. This has long been one of the things that makes Chrome feel to me like a badly-ported Mac app w.r.t. text handling. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Oct 19, 2009, at 3:27 PM, Peter Kasting wrote: On Mon, Oct 19, 2009 at 1:21 PM, David Hyatt hy...@apple.com wrote: On Oct 19, 2009, at 3:19 PM, Peter Kasting wrote: I'm not quite sure what you mean. Do you just mean it looks visually confusing, but when you copy/paste you get the right text? Or are you saying that it's actually selecting the wrong things? There are two different effects that interrelate: * WebKit allows you to select anything on a page. Repro: Go to any page, start at top, drag down, note that you select everything. Desired behavior: Only select the text from the page. You aren't only selecting text on a page though. For example, copying can be of all the HTML content. This includes tables, images, plugins, etc. If you don't highlight that content, then you're lying about what gets copied. The fact that it doesn't show up when you happen to paste into a plaintext app does not change the fact that the non-textual content really does get copied if you paste into an app that supports HTM. On Mac that's practically everything, so maybe that's the difference in perception on your part is that on Windows you don't commonly copy/ paste into apps that support HTML? Copy/paste within the same app while doing rich text editing in Chrome, and you'll see why including elements other than text in the selection makes sense. Gaps are distinct from the question of whether or not you're selecting just text though. However, excluding gaps once you start extending the selection to cover other types of content leads to a pretty ugly selection (as can be the case in Firefox). dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:31 PM, David Hyatt hy...@apple.com wrote: You aren't only selecting text on a page though. For example, copying can be of all the HTML content. This includes tables, images, plugins, etc. If you don't highlight that content, then you're lying about what gets copied. No, you're misunderstanding me. The bug is that that stuff is copied. The desired behavior is that it not be copied when it is part of a non-editable area on the page. The only time non-text should be copied is when it is part of a rich text area. In that case copying rich content makes sense. maybe that's the difference in perception on your part is that on Windows you don't commonly copy/paste into apps that support HTML? No, I have the opposite problem. Nearly everything I paste into supports HTML, or this wouldn't be so infuriating. Copy/paste within the same app while doing rich text editing in Chrome, and you'll see why including elements other than text in the selection makes sense. See my noted exception above. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:37 PM, Peter Kasting pkast...@google.com wrote: On Mon, Oct 19, 2009 at 1:31 PM, David Hyatt hy...@apple.com wrote: You aren't only selecting text on a page though. For example, copying can be of all the HTML content. This includes tables, images, plugins, etc. If you don't highlight that content, then you're lying about what gets copied. No, you're misunderstanding me. The bug is that that stuff is copied. The desired behavior is that it not be copied when it is part of a non-editable area on the page. The only time non-text should be copied is when it is part of a rich text area. In that case copying rich content makes sense. I think there is a good use case for copying a selection of HTML from any web page and pasting that into the rich text editor of a web mail program. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:40 PM, Darin Fisher da...@chromium.org wrote: I think there is a good use case for copying a selection of HTML from any web page and pasting that into the rich text editor of a web mail program. I agree, but that case does not degrade badly when you only copy the text, whereas if there is any case where you _don't_ want to copy the images etc., the current behavior makes those use cases impossible. Note that within Chrome we put in ctrl-shift-v to paste as plain text precisely because of issues like this. Most other programs don't have that option though (and even in Chrome it's hard to discover). PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:43 PM, Peter Kasting pkast...@google.com wrote: On Mon, Oct 19, 2009 at 1:40 PM, Darin Fisher da...@chromium.org wrote: I think there is a good use case for copying a selection of HTML from any web page and pasting that into the rich text editor of a web mail program. I agree, but that case does not degrade badly when you only copy the text, whereas if there is any case where you _don't_ want to copy the images etc., the current behavior makes those use cases impossible. Note that within Chrome we put in ctrl-shift-v to paste as plain text precisely because of issues like this. Most other programs don't have that option though (and even in Chrome it's hard to discover). Yeah, I frequently see the Code Definition window in Visual Studio ;-) -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:45 PM, David Hyatt hy...@apple.com wrote: On Oct 19, 2009, at 3:37 PM, Peter Kasting wrote: The only time non-text should be copied is when it is part of a rich text area. In that case copying rich content makes sense. Ok, well we fundamentally disagree on this point, so there's not much more to say. Note that I completely agree that this should be controlled by a Setting so you can avoid changing Safari's behavior. I'm trying to describe what I want for Chrome, not something that must be forced on all WebKit apps. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Oct 19, 2009, at 1:43 PM, Peter Kasting wrote: Note that within Chrome we put in ctrl-shift-v to paste as plain text precisely because of issues like this. Most other programs don't have that option though (and even in Chrome it's hard to discover). On Mac we call this Paste and Match Style and it is common is many Mac apps, including Safari. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Oct 19, 2009, at 1:43 PM, Peter Kasting wrote: Note that within Chrome we put in ctrl-shift-v to paste as plain text precisely because of issues like this. Most other programs don't have that option though (and even in Chrome it's hard to discover). I guess it isn't exactly what you describe, since images and other rich content are still pasted. Just not text styles. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:43 PM, Peter Kasting pkast...@google.com wrote: On Mon, Oct 19, 2009 at 1:40 PM, Darin Fisher da...@chromium.org wrote: I think there is a good use case for copying a selection of HTML from any web page and pasting that into the rich text editor of a web mail program. I agree, but that case does not degrade badly when you only copy the text, whereas if there is any case where you _don't_ want to copy the images etc., the current behavior makes those use cases impossible. I don't follow this argument. If I want the text, tables, images, etc., then if copy only grabs the text, what I want is impossible. If I only want the text, at least I can remove the other stuff after pasting: inconvenient, but possible. I must not understand what you're describing. - Pam Note that within Chrome we put in ctrl-shift-v to paste as plain text precisely because of issues like this. Most other programs don't have that option though (and even in Chrome it's hard to discover). PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:55 PM, Pam Greene p...@chromium.org wrote: On Mon, Oct 19, 2009 at 1:43 PM, Peter Kasting pkast...@google.comwrote: On Mon, Oct 19, 2009 at 1:40 PM, Darin Fisher da...@chromium.org wrote: I think there is a good use case for copying a selection of HTML from any web page and pasting that into the rich text editor of a web mail program. I agree, but that case does not degrade badly when you only copy the text, whereas if there is any case where you _don't_ want to copy the images etc., the current behavior makes those use cases impossible. I don't follow this argument. If I want the text, tables, images, etc., then if copy only grabs the text, what I want is impossible. If I only want the text, at least I can remove the other stuff after pasting: inconvenient, but possible. I must not understand what you're describing. No, you understand things OK. My prescription is based on not having a use case for copying the complete rich contents of non-editable areas. If you in fact need to do that, then you need our current behavior. It just makes the opposite use case extraordinarily inconvenient, and my claim is that the opposite use case is the one that actually comes up frequently. (For example, I copy text in a web page to send to people or paste into other documents all the time, but I can't recall the last time I wanted to copy the web page as a web page into my clipboard -- the few times I've wanted the complete content, I've wanted to Save As Web Page, Complete.) PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection highlight painting (gaps?)
On Mon, Oct 19, 2009 at 1:58 PM, Joe Mason j...@notcharles.ca wrote: Perhaps the browser should have Copy text and Copy all objects options (in which case either WebKit needs to support both modes, or the browser would need to filter the copied data). Yes, that could help. Filed crbug.com/25239. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling all committers: The pending-commit list is overflowing
We're back down to 25 after Yong's epic cq+ing this morning. The queue had a record 13 patch backlog for a while. Thank you Yong for cleaning the pending-commit list! Still 25 to go. All of which require manual attention from committers. -eric On Mon, Oct 19, 2009 at 11:52 AM, Eric Seidel e...@webkit.org wrote: On Sun, Oct 18, 2009 at 11:34 PM, Adam Barth aba...@webkit.org wrote: 2) If you see a patch on the list that's ready to land (almost all of them), you can mark it commit-queue+ to have the commit bot land it. When you do this, please be sure to watch the tree for regressions, just like you would if you typed svn commit yourself. FYI, if you're using commit-queue+, you should know about: http://webkit-commit-queue.appspot.com/ which gives you a little window into commit-queue's tiny brain. Eventually I hope to move that to http://commit.webkit.org/ or something easier to remember. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Keypress event for ctrl+key and/or ⌘+key?
On Mon, Oct 19, 2009 at 6:03 PM, Oliver Hunt oli...@apple.com wrote: The real issue is whether application shortcuts get precedence over DOM event handlers, currently on mac the DOM event handlers get precedence (and thus the ability to override/prevent application shortcuts) and on windows they don't. This is entirely a byproduct of implementation and the difference really isn't something we want. In Chromium, DOM event handlers get precedence (important for pages which want to provide a custom find-in-page impl, or override ctrl-b [toggle bookmark bar] to mean bold text), except for a small set of accelerators relating to opening/closing/changing tabs/windows, which we don't send to the renderer so that slow/hung renderers (or malicious pages, I suppose) can't cause the user to be unable to instantly close the tab or switch to another one. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling all committers: The pending-commit list is overflowing
WebKit, you are awesome. We're down to our usual 17 now. Thanks everyone! Adam On Mon, Oct 19, 2009 at 3:27 PM, Eric Seidel e...@webkit.org wrote: We're back down to 25 after Yong's epic cq+ing this morning. The queue had a record 13 patch backlog for a while. Thank you Yong for cleaning the pending-commit list! Still 25 to go. All of which require manual attention from committers. -eric On Mon, Oct 19, 2009 at 11:52 AM, Eric Seidel e...@webkit.org wrote: On Sun, Oct 18, 2009 at 11:34 PM, Adam Barth aba...@webkit.org wrote: 2) If you see a patch on the list that's ready to land (almost all of them), you can mark it commit-queue+ to have the commit bot land it. When you do this, please be sure to watch the tree for regressions, just like you would if you typed svn commit yourself. FYI, if you're using commit-queue+, you should know about: http://webkit-commit-queue.appspot.com/ which gives you a little window into commit-queue's tiny brain. Eventually I hope to move that to http://commit.webkit.org/ or something easier to remember. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Keypress event for ctrl+key and/or ⌘+key?
On Mon, Oct 19, 2009 at 18:03, Oliver Hunt oli...@apple.com wrote: On Oct 19, 2009, at 5:18 PM, Erik Arvidsson wrote: I'm trying to clean up some inconsistencies with when keypress events are dispatched. WebKit's key event model is modeled to be compatible with Internet Explorer and Internet Explorer does not fire keypress for Ctrl+key [1] The key event model was designed to be as compatible as possible with both IE and firefox, so it would be helpful to know the firefox behaviour. Firefox fires keypress events for everything. Safari Win does not fire any keypress events when ctrl is held down Safari Mac fires keypress events when command is held down Safari Mac fires keypress events when ctrl is held down Chromium Win fires keypress events for some keys when ctrl is held down Chromium Linux fires keypress events for some keys when ctrl is held down (matches chromium windows) Chromium Mac does not fire keypress events when command is held down Chromium Mac does not fire keypress events when ctrl is held down There are two possible solutions to this problem. 1. Always fire keypress events no matter what modifiers are held down 2. Do not fire keypress events unless content would be generated Expected behaviour is for key events to be sent regardless of ctrl/command pressed. The real issue is whether application shortcuts get precedence over DOM event handlers, currently on mac the DOM event handlers get precedence (and thus the ability to override/prevent application shortcuts) and on windows they don't. This is entirely a byproduct of implementation and the difference really isn't something we want. --Oliver I think we should try to enable firing keypress events on Windows again and see if it leads to any troubles. -- erik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling all committers: The pending-commit list is overflowing
Why are there 17 patches with review+ that never get landed? This has bothered me in the past, but I wasn't sure if it was the same group of patches or not. Dave On Mon, October 19, 2009 at 7:08:50 PM, Adam Barth wrote: WebKit, you are awesome. We're down to our usual 17 now. Thanks everyone! Adam On Mon, Oct 19, 2009 at 3:27 PM, Eric Seidel wrote: We're back down to 25 after Yong's epic cq+ing this morning. The queue had a record 13 patch backlog for a while. Thank you Yong for cleaning the pending-commit list! Still 25 to go. All of which require manual attention from committers. -eric On Mon, Oct 19, 2009 at 11:52 AM, Eric Seidel wrote: On Sun, Oct 18, 2009 at 11:34 PM, Adam Barth wrote: 2) If you see a patch on the list that's ready to land (almost all of them), you can mark it commit-queue+ to have the commit bot land it. When you do this, please be sure to watch the tree for regressions, just like you would if you typed svn commit yourself. FYI, if you're using commit-queue+, you should know about: http://webkit-commit-queue.appspot.com/ which gives you a little window into commit-queue's tiny brain. Eventually I hope to move that to http://commit.webkit.org/ or something easier to remember. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling all committers: The pending-commit list is overflowing
On Mon, Oct 19, 2009 at 8:54 PM, Adam Barth aba...@webkit.org wrote: On Mon, Oct 19, 2009 at 8:39 PM, David Kilzer ddkil...@webkit.org wrote: Why are there 17 patches with review+ that never get landed? This has bothered me in the past, but I wasn't sure if it was the same group of patches or not. It's not the same group of patches. Sometimes there are patches with review+ but with comments that need to be addressed by the contributor. Other times, there are dependent patches that haven't been landed. We could be more agressive in clearing out the pending-commit list, but it only seems problematic when it piles up. As an experiment, I went through this list in detail and brought it down to 11 patches. The rest fall into the following categories: 1) Epic uber bugs that are incomprehensible. For example: https://bugs.webkit.org/show_bug.cgi?id=27651 https://bugs.webkit.org/show_bug.cgi?id=16768 https://bugs.webkit.org/show_bug.cgi?id=3749 2) Apple contributors who have explicitly asked not to have their patches landed for them, for whatever reason. For example: https://bugs.webkit.org/show_bug.cgi?id=29905 https://bugs.webkit.org/show_bug.cgi?id=30421 3) Patches where the patch has been review+ but the contributor has been asked to consider non-trivial (meaning I can't do it for them) changes. For example: https://bugs.webkit.org/show_bug.cgi?id=30083 I don't see a big need to drive this list all the way to zero. If we could get the review queue down to 11 patches, I'd be a really happy man. :) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
