Selection highlight painting ("gaps"?)

[Evan Martin-4]

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.

Epiphany (using WebKitGtk) does it Linux style, but my best efforts to
trace through the code have found no ifdefs related to platforms that
might make this happen.  I asked on various IRC channels and nobody
knew how it worked.

It seems these extra margins in the code are called "gaps" -- if I
make RenderBlock::getHorizontalSelectionGapInfo always return false,
the selections sorta behave as they do in Epiphany.  But none of this
code seems to be controlled by flags.  Does anyone know how it works?
I'm surely just missing a setting somewhere, but I have no idea how to
find it...
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[David Hyatt]

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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Ben Goodger-2]

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 <hyatt@...> 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@...
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Jeremy Orlow-2]

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 <beng@...> 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 <hyatt@...> 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@...
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[David Hyatt]

On Oct 19, 2009, at 3:03 PM, Ben Goodger 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

Yeah, when it comes to complex Web page selection, I don't think there  
really is a platform precedent.  It really comes down to "How much  
effort did the browser put into their selection code?" and typically  
the answer is "Not that much."

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.

dave
(hyatt@...)

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Ben Goodger-2]

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 <jorlow@...> 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 <beng@...> 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 <hyatt@...> 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@...
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@...
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Peter Kasting]

On Mon, Oct 19, 2009 at 1:10 PM, David Hyatt <hyatt@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Evan Martin-4]

On Mon, Oct 19, 2009 at 1:13 PM, Ben Goodger <beng@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[David Hyatt]

On Oct 19, 2009, at 3:19 PM, Peter Kasting wrote:

On Mon, Oct 19, 2009 at 1:10 PM, David Hyatt <hyatt@...> 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

(hyatt@...)

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[David Hyatt]

On Oct 19, 2009, at 3:19 PM, Peter Kasting wrote:

On Mon, Oct 19, 2009 at 1:10 PM, David Hyatt <hyatt@...> 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

(hyatt@...)

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Peter Kasting]

On Mon, Oct 19, 2009 at 1:21 PM, David Hyatt <hyatt@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[David Hyatt]

On Oct 19, 2009, at 3:27 PM, Peter Kasting wrote:

On Mon, Oct 19, 2009 at 1:21 PM, David Hyatt <hyatt@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Peter Kasting]

On Mon, Oct 19, 2009 at 1:31 PM, David Hyatt <hyatt@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Darin Fisher-3]

On Mon, Oct 19, 2009 at 1:37 PM, Peter Kasting <pkasting@...> wrote:

On Mon, Oct 19, 2009 at 1:31 PM, David Hyatt <hyatt@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Peter Kasting]

On Mon, Oct 19, 2009 at 1:40 PM, Darin Fisher <darin@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[David Hyatt]

On Oct 19, 2009, at 3:37 PM, Peter Kasting wrote:

On Mon, Oct 19, 2009 at 1:31 PM, David Hyatt <hyatt@...> 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.

Ok, well we fundamentally disagree on this point, so there's not much more to say.

dave

(hyatt@...)

_______________________________________________
webkit-dev mailing list
webkit-dev@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Darin Fisher-3]

On Mon, Oct 19, 2009 at 1:43 PM, Peter Kasting <pkasting@...> wrote:

On Mon, Oct 19, 2009 at 1:40 PM, Darin Fisher <darin@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Peter Kasting]

On Mon, Oct 19, 2009 at 1:45 PM, David Hyatt <hyatt@...> 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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Timothy Hatcher]

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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[Timothy Hatcher]

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@...
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev