desktop-packages team mailing list archive

[Ehsan-mozilla <584632@xxxxxxxxxxxxxxxxxx>]

Sorry for the delay here, somehow I failed to note the needinfo flag!

As Aryeh said, the current try results look great!  And it seems like
fixing this is going to be much easier than I thought after all.  :-)
The next step is to ensure that the selection is put in the exact same
place through other means of moving to the end of a line.  For example,
one such scenario that you need to investigate is if the caret is in the
middle of the line, and you press End or Ctrl/Cmd+E.  Another example is
when you have multiple lines, and you place the caret at the end of a
longer line and use up/down to navigate to the end of a shorter line.
Same thing with using PageUp/PageDown in the same situation but with
more lines of text obviously.  Some of these code paths can end up going
through the same code and some may already do the right thing but you
need to test each one of them to make sure.  The main entry point for
all of these is nsFrameSelection::MoveCaret, where we end up calling
nsIFrame::PeekOffset <https://dxr.mozilla.org/mozilla-
central/source/layout/generic/nsSelection.cpp#969> which then gets us
through the same machinery as you've seen before.

Another thing that would be useful to test (but I'm pretty sure that it
would work correctly based on the code changes) is what happens in both
of these cases when you have several inline elements nested underneath
each other, such as:

<span><b><i><font>foo bar on the same line</font></i></b></span>

You should ensure that the selection is again put at the end of the text
frame in this case, so that when the user starts to type again, the new
text would have the correct styles imposed by all of those inline
elements.

Once you've verified and fixed all of these cases, the next step would
be to write a unit test as Aryeh mentioned that examines this behavior
and ensures that we don't end up regressing it in the future.  In
addition to simulating a mouse click, you'd need to use synthesizeKey,
for example, synthesizeKey("VK_UP") for simulating the "Up" key, and so
on.

And thanks again for working on this!

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