← Back to team overview

desktop-packages team mailing list archive

[Bug 584632]

 

(In reply to Jorg K from comment #57)
> Please confirm that you are happy to change FF's behaviour to be like
> Chrome, Opera and Safari.
> 
> I read the last section of your comment (quote: "... Good luck!") as a
> confirmation, but before you were rather careful saying (1):
> > If they all agree on putting the selection where I described above (...)
> > then we can look into changing our code
> and (2)
> > 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.  :/

I cannot predict how this change will pan out in the wild before we try
it.  It may very well be that we try this approach and it turns out that
it breaks existing Web pages in a way that would cause us to revert the
fix.  It is only by trying this out that we can know for sure.

> Regarding the first statement: They don't all agree, FF and IE differ, but
> if FF moved into the Chrome camp, only IE would be left. And who knows what
> the new "Spartan" browser will do.

Well, what I meant was that the browsers do not have a consistent
behavior here, so it could be that some websites are relying on Gecko's
exact behavior here somehow.  But like I said it's impossible to
predict.

> Regarding the second statement: I thought the original idea from comment #22
> was to move the selection into the text:
> > My suspicion is that place is outside of the element that has the respective style
> > for the font set.  We should probably look into normalizing the selection in 
> > those cases to be inside the said element
> Also in comment #50 you said:
> > 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.
> 
> I'm not sure how that would be (quote) "incompatible with the Web".
> 
> Once I have your confirmation I will go ahead.
> 
> For me, this is the single most annoying bug in Thunderbird which after 10
> years should finally be resolved.

This affects more than just Thunderbird, and concerns behavior that is
visible to Web pages.  Web content can rely on the behavior of the
engine in a lot of ways, for example by expecting that Firefox puts the
selection somewhere specific when you go to the end of line.  This is
one of the reasons why fixing this bug is very difficult.

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