(In reply to Jorg K from comment #38) > Coming back to the suggestion from comment #25 and looking in > nsFrame::HandlePress. > > I traced it down into ns[Text]Frame::GetChildFrameContainingOffset with a > call stack of: > > nsFrame::GetChildFrameContainingOffset *or* > nsTextFrame::GetChildFrameContainingOffset > nsFrameSelection::GetFrameForNodeOffset > nsFrameSelection::BidiLevelFromClick > nsFrameSelection::HandleClick > nsFrame::HandlePress > > It varies whether nsFrame::GetChildFrameContainingOffset or > nsTextFrame::GetChildFrameContainingOffset is being called depending on > whether you click on the text, but almost to the left of the text, or > completely to the left of the text. > > When the nsTextFrame::GetChildFrameContainingOffsetAny version is called, it > offset is calculated correctly and the font is right. When the > nsFrame::GetChildFrameContainingOffset is called, the font is wrong. In the > latter case the caret still appears behind the text.
Yes, this is what I was explaining in comment 22. The frame on which this function is called depends on the frame receiving the click event; if you click on the text it's going to be a textframe, otherwise it's going to be the parent frame (in the normal case as in the test case you describe above) or anything else that is under the mouse cursor. > Try it with a wide letter, like "m"! > > So in case a "Frame" being hit instead of a "TextFrame", perhaps the program > should look whether there is a text right before the caret once placed. No, we shouldn't change the way that we hit-test to find out which frame was clicked. As I said in comment 22, we should probably look into normalizing the selection, so that if the line ends in an inline frame containing a text frame, we should put the selection at the end of the text frame as opposed to at the end of the inline frame terminating the line. But before we can do that, we need to investigate the behavior of other engines in this situation (as in, we should see where they put the selection.) You need to create a test case which lets you click somewhere and have it dump out the place of the selection (which you can get through window.getSelection()). The simplest way to create such a test case is to set it up to print the selection after 10 seconds or so. Then you should document the behavior of IE/Chrome/Opera/Safari on that test case. If they all agree on putting the selection where I described above (IIRC some of the engines did that the last time I tested this years ago) then we can look into changing our code. Beware that it will probably take a significant amount of work adjusting everywhere in our code where we depend on the existing behavior, same in our existing tests. -- 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
