desktop-packages team mailing list archive

[Ehsan-mozilla <584632@xxxxxxxxxxxxxxxxxx>]

(In reply to Jorg K from comment #23)
> I could use some help to locate the code that translates the click into
> identifying the element. Somewhere in ns(HTML)EditorEventListener.cpp, I
> suppose.

nsFrame::HandlePress is called when you click on an element, and at
least part of the selection normalization should probably happen inside
there.

(In reply to Jorg K from comment #24)
> I am having second thoughts. If I understood correctly, the idea is to
> continue adding to the pre-existing element at the end of the line instead
> of adding a new element which will lose the style or font. Is this really
> the correct approach?

It's probably the easiest way to fix this bug.  There are probably other
implementation strategies as well, but I can't think of an easier one.

> I have three more questions in this context:
> 1) The paragraph is created when replying to an e-mail does have the correct
> style/font. It only gets lost after moving the caret around in the e-mail.
> How does Thunderbird communicate to the editor which style to use in the
> first place, in the case comment #23, the <tt>?

I don't know how Thunderbird works, but this information is usually
transferred to Gecko using document.execCommand calls.

> Why can't this method be
> used for any subsequently created text elements? 

I don't understand this question.

Note that the type-in state code is mostly used to handle sequences such
as calling document.execCommand("bold") and starting to type.  It
doesn't know how to handle anything more complicated (for example
remembering the styles to be used for an arbitrary element at an
arbitrary DOM position.)

> Currently further text
> elements are created with the "default" font, which is also configured in
> Thunderbird and must be communicated somehow to the editor.

Again, I don't know the Thunderbird specific parts here.

> 2) Over in bug 1100966 (spell checker losing red underlines) another node is
> also created when clicking at the end of the line. Upon backspace, this node
> becomes empty and is merged (badly) with the preceding one, which in turn
> loses the underlines. Why didn't we consider to continue the existing node
> instead of creating a new one? In this case the merge would not happen.

Because it's possible to fix that code more easily, and also we use the
same joining code for other purposes such as when two nodes really need
to be joined because the content in between them is being deleted.
Fixing this bug would make the steps to reproduce in that bug change,
but these are separate issues.

> 3) Another problem with losing the style/font can be observed after
> inserting an image, see comment #14. I think the proposed approach of
> reusing a pre-existing text element can't be used here, since the preceding
> element is an image. So wouldn't it be easier to make sure the chosen
> style/font is observed when creating another text element after the image?

I _think_ to fix that part you need to get Thunderbird tell Gecko about
how to format the new paragraph.  The fix suggested in comment 22 will
not fix all of the issues with the type-in style being lost.

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