desktop-packages team mailing list archive

[Ehsan-mozilla <584632@xxxxxxxxxxxxxxxxxx>]

(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 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