(In reply to :Aryeh Gregor from comment #77)
> For the record, from black-box testing of WebKit a few years ago, it looked
> like it normalized the selection after every change. Even if you called
> .addRange(), it copied the range and then stuck the selection endpoints
> inside a nearby text node if available, etc. I think it's taking things too
> far to change script-specified selections
Yeah, I think that's a bit too aggressive, and probably would cause
authors to have to do insane hacks if they actually want to put the
selection where the engine doesn't think is appropriate.
> but the right way to do this is
> probably to have some sort of helper method in Selection like
> NormalizePoint(nsINode*, int32_t) and call it before every user-initiated
> selection change. We might want to disallow other types of user-created
> selections from occurring in the future, although my brain is too rusty to
> supply any.
Well, most of the code handling selection changes actually lives outside
Selection. ;-) Depending on where we need to modify the behavior,
having this kind of helper may or may not help... See Jorg's patch for
example, I think the way he modifies the existing logic is cleaner than
going with the current logic and then fixing it up elsewhere.
> Do we want to allow a selection like <b>foo</b>{}<i>bar</i>, with the
> selection collapsed in between the <b> and <i>? IIRC, WebKit in my testing
> forced this to be <b>foo[]</b><i>bar</i> (always making it on the previous
> text node). A ten-second test in WordPad suggests this is the right thing
> to do.
Yes, that makes sense to me. Follow-up bug perhaps?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer changes font mid email
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/584632/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
