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 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: :HandlePress :GetContentOffs etsFromPoint sestFrame :GetSelectionCl osestFrameForBl ock n::HandleClick :GetChildFrameC ontainingOffset :GetChildFrameC ontainingOffset , offset=10 :GetChildFrameC ontainingOffset :NotifySelectio nChanged, container=05EF8900, offset=10 <-- the text of length 10 n::HandleClick after TakeFocus :HandlePress
>>> Entering nsFrame:
=== in nsIFrame:
=== in GetSelectionClo
=== in nsFrame:
>>> Entering nsFrameSelectio
=== before BidiLevelFromClick
>>> Endering nsTextFrame:
=== nsTextFrame:
<<< Leaving nsTextFrame:
=== after BidiLevelFromClick
*** TypeInState:
<<< Leaving nsFrameSelectio
<<< Leaving nsFrame:
When clicking to the right of the text: :HandlePress :GetContentOffs etsFromPoint sestFrame :GetSelectionCl osestFrameForBl ock :GetSelectionCl osestFrameForLi ne sestFrame :GetSelectionCl osestFrameForBl ock n::HandleClick :NotifySelectio nChanged, container=066CF4C8, offset=2 <-- the DIV n::HandleClick after TakeFocus :HandlePress
>>> Entering nsFrame:
=== in nsIFrame:
=== in GetSelectionClo
=== in nsFrame:
=== in nsFrame:
=== in GetSelectionClo
=== in nsFrame:
>>> Entering nsFrameSelectio
=== before BidiLevelFromClick
=== after BidiLevelFromClick
*** TypeInState:
<<< Leaving nsFrameSelectio
<<< Leaving nsFrame: