(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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer changes font mid email
To manage notifications about this bug go to:
https://bugs.launchpad.net/thunderbird/+bug/584632/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
