desktop-packages team mailing list archive

[Mozilla-jorgk <584632@xxxxxxxxxxxxxxxxxx>]

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