desktop-packages team mailing list archive

[Ehsan-mozilla <584632@xxxxxxxxxxxxxxxxxx>]

(In reply to Jorg K from comment #51)
> Sadly I don't understand some of what you wrote. Let me see what I
> understood.
> 
> You're saying you want to check how other rendering engines behave. I ran
> the test from comment #37 on Chrome and IE. Both continue text entry with
> the font present on the first line, so their behaviour is what I would
> expect.

That's not what I asked.  I want to know where they put the selection.
Attachment 8575104 kind of does that but I was hoping to get the offsets
as well, but with the results in comment 54, it's clear that the exiting
engines don't all agree on a single behavior, which means that my
original idea may turn out to be incompatible with the Web.  :/

What versions of these browsers did you test?  What about Safari?

Note that whether or not other engines have this bug is not relevant.

> Next you talk about "test cases" where you click and dump out the selection.
> In this case, we do a single click, so the selection will have one collapsed
> range. I don't know which property of the Selection or Range you want to
> inspect, maybe selRange.[start|end]Container.nodeName.

Yeah, startContainer and endContainer, plus startOffset and endOffset.

> I've stripped down the so-called Midas demo and added some information about
> the clicking when carrying out the text case from comment #37. Result:
> 
> FF: BODY, continues in the wrong font.
> Chrome: #text, continues with the correct font.
> IE: #text if you used <enter> between the lines, or BODY if you used
> <shift><enter>, continues with correct font in both cases.
> 
> Let me know what to do next. And please, clear instructions ;-)

The first step is to read and understand how
GetContentOffsetsFromPoint() works, specifically the call to
GetSelectionClosestFrame(), which is the function that decides what
frame is marked as selected ultimately when a given frame receives a
click event.

For example in attachment 8575104 if you click to the right of the first
line, we get to GetSelectionClosestFrameForLine() selecting the BRFrame
at the end of the first line.  Now, if we want to collapse the selection
to the text frame, it means that we need to skip the BRFrame.  So you
should modify that logic to ignore BRFrame's if there is anything else
on the same line before them (i.e., if there is something that we
haven't yet looked at through the line iterator.)  Then you should
verify that the change actually makes us collapse the selection at the
end of the text frame (so for example startContainer and endContainer
should both be the text node and startOffset/endOffset should both be 10
depending on the length of the text frame).  Then you should post the
change to the try server and see what existing tests fail, and debug
them to figure out why.  There will be two classes of test failures, one
for tests that are relying on the specific behavior we're changing here,
so you should adjust those tests accordingly.  Another set of test
failures will hopefully catch the edge cases that we have not thought
very carefully about yet.  We should probably discuss the test failures
once you get to that stage.

Beware that this will probably be a lengthy process and it requires a
lot of debugging skills and also being comfortable finding your way
across a large C++ code base.  Good luck!

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