You are correct, I was in "e10s" mode and there was another process "plugin-container". Now I switched that off. I had noticed that my debugging had become strange, but couldn't figure out why. So thank you!
Before considering changing the selection behaviour, I'd like to repeat my question, but I don't want to infuriate you ;-) The problem in this bug and in the other bug 1140617 is, that a line is continued with a new element. In this bug, someone clicks on a "DIV", since they click to the right of the text. The new text is inserted into a new element and loses the font. In the other bug, an image is inserted. After that the new text is inserted into a new element and loses the font. In both cases we could look in the inline frame and see whether there is a text element immediately before, whose attributes should be used. Is this an option? If we did that, we would *not* have to change the selection behaviour and wear all the possible consequences. Changing the selection will fix this bug but not the other bug 1140617. If this is not a viable solution, I can look further into changing the selection behaviour. My debugging works now: Debug when clicking on the text: >>> Entering nsFrame::HandlePress === in nsIFrame::GetContentOffsetsFromPoint === in GetSelectionClosestFrame === in nsFrame::GetSelectionClosestFrameForBlock >>> Entering nsFrameSelection::HandleClick === before BidiLevelFromClick >>> Endering nsTextFrame::GetChildFrameContainingOffset === nsTextFrame::GetChildFrameContainingOffset, offset=10 <<< Leaving nsTextFrame::GetChildFrameContainingOffset === after BidiLevelFromClick *** TypeInState::NotifySelectionChanged, container=05EF8900, offset=10 <-- the text of length 10 <<< Leaving nsFrameSelection::HandleClick after TakeFocus <<< Leaving nsFrame::HandlePress When clicking to the right of the text: >>> Entering nsFrame::HandlePress === in nsIFrame::GetContentOffsetsFromPoint === in GetSelectionClosestFrame === in nsFrame::GetSelectionClosestFrameForBlock === in nsFrame::GetSelectionClosestFrameForLine === in GetSelectionClosestFrame === in nsFrame::GetSelectionClosestFrameForBlock >>> Entering nsFrameSelection::HandleClick === before BidiLevelFromClick === after BidiLevelFromClick *** TypeInState::NotifySelectionChanged, container=066CF4C8, offset=2 <-- the DIV <<< Leaving nsFrameSelection::HandleClick after TakeFocus <<< Leaving nsFrame::HandlePress -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/584632 Title: composer changes font mid email Status in Mozilla Thunderbird Mail and News: Confirmed Status in thunderbird package in Ubuntu: Confirmed Bug description: Binary package hint: thunderbird As I'm typing my emails in Thunderbird, I can see what appears to be a font size change on screen, normally in the second line of text. The second line appear smaller than the first. It's barely perceptible, so half them time I think I am imagining it. Well, I've started Bccing to myself to check, and the emails I am receiving from myself are not only a different size, they're also a different font. Composer starts in some default serif, and by the second line is sans. I'd bee glad to email someone viz thunderbird, and also send along a screenshot of how it looks while I am typing. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/584632/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
