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, 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.
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.
I don't think any of this has to be in the scope of the current bug,
though.
--
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
