Upstream report was closed "RESOLVED FIXED" on 2015-03-29
Unable to reproduce with Thunderbird 60.6 in Ubuntu 18.04
No comments here or upstream for 4 years so closing as fixed
** Changed in: thunderbird (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification
Release channel is at 31.5 as of this post.
Seems a long way to reach 39 assuming it moves +1 at a time
--
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
(In reply to maybe-the-one from comment #138)
Is there any way we can lobby for landing it in 38?
Please move that discussion to bug 1142879 or elsewhere. Thanks!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
OK I guess the delay for one version is about two months if it does not
get into v38?
--
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
No... if it doesn't get back-ported to 38, then it has to wait for
version 45 - another, what, 10 months?
--
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
The progress on squashing this bug is excellent. One thought is that
currently TB v39 is in DAILY channel (where this fix has now presumably
landed) and is due to move to EARLYBIRD week of March 31 which is
tomorrow. Presumably if users are on the Earlybird channel then they
will get the fix
Personally, I never understood why this problem involved browsers at all.
It happens when COMPOSING email in THUNDERBIRD
and manifests when reading email in THUNDERBIRD.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in
OK, thanks for explaining. I did not know that there was shared code.
And indeed, facts are facts even when one is ignorant of them.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://hg.mozilla.org/mozilla-central/rev/bf414f68291c
--
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
Is there any way we can lobby for landing it in 38?
--
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
(In reply to maybe-the-one from comment #135)
Personally, I never understood why this problem involved browsers at all.
That you don't understand the facts doesn't change them ;-)
Let me explain: Thunderbird is client software that sits on top of
Mozilla core software. The so-called editor
Ummm... ok, but... who are these 'Thunderbird people', and how do we
contact them?
--
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
** Changed in: thunderbird
Status: Confirmed = Fix Released
--
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
https://hg.mozilla.org/integration/mozilla-inbound/rev/bf414f68291c
--
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
For those who want to see this in Thunderbird 38 -- I suggest talking to
the Thunderbird people and asking them if they can cherry-pick the patch
for Thunderbird without affecting Firefox. If it's really a huge
improvement for them, maybe they'll be willing to accept it despite lack
of testing.
Created attachment 8584620
Here comes another manual test.
Here some HTML to run a test by hand.
If clicking behind any of the eight lines in this test, DIV will be
returned in the current version of FF.
With the new behaviour clicking behind lines 1-6 and 8, #text will be
returned, but for the
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment
#119)
(In reply to Jorg K from comment #118)
Changing the subject:
I'd like to see this landed one day very soon. I'd also request to land it
on mozilla38, so TB 38 can pick it up. I don't want to mention again that
Comment on attachment 8584639
Unified patch (code + test changes + four times revised new test)
Review of attachment 8584639:
-
Thanks, looks great!
--
You received this bug notification because you are a member of Desktop
(In reply to Jorg K from comment #115)
Created attachment 8584346
Unified patch (code + test changes + twice revised new test)
Thank you very much for the review and all the additional explanation.
I hope I could address your questions in additional comments in the test.
Sadly switching
Comment on attachment 8583354
Test case (revised)
Review of attachment 8583354:
-
Looks like a great start! Did you intend to test the rest of the cases
in a separate patch?
::: layout/generic/test/test_bug756984.html
@@ +13,5 @@
Created attachment 8584608
Unified patch (code + test changes + three times revised new test)
Here comes the updated test. This time with some additional inline
elements.
I'm not sure why the second test should be wrong, I'll add another
attachment in a second to convince you ;-)
--
You
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment
#125)
Charles, this patch affects more than Thunderbird. I'm not sure what the
usual practices are with regards to stuff that are regression prone in
Thunderbird, but in Firefox, we are usually very conservative,
(In reply to Charles from comment #128)
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from
comment #125)
Charles, this patch affects more than Thunderbird. I'm not sure what the
usual practices are with regards to stuff that are regression prone in
Thunderbird, but in
(In reply to Jorg K from comment #118)
Created attachment 8584620
Here comes another manual test.
Here some HTML to run a test by hand.
If clicking behind any of the eight lines in this test, DIV will be
returned in the current version of FF.
With the new behaviour clicking behind
Created attachment 8584639
Unified patch (code + test changes + four times revised new test)
This should be good to go then ;-)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
(In reply to Jorg K from comment #123)
(In reply to Charles from comment #121)
Are you seriously saying that this bugfix will NOT land in time for TB 38?
Meaning, we will have to another full YEAR to see it fixed?
Given that the version spacing is six weeks we get 6 * (45-38) = 42 weeks,
I'm really sad that this patch will not land in TB 38. But I want to
make a big thank to Jorg that is working on the correction of this long
standing bug. Also thanks to Ehsan that worked this in the past.
--
You received this bug notification because you are a member of Desktop
Packages, which
(In reply to Charles from comment #121)
Are you seriously saying that this bugfix will NOT land in time for TB 38?
Meaning, we will have to another full YEAR to see it fixed?
Given that the version spacing is six weeks we get 6 * (45-38) = 42 weeks,
that's 10 months ;-)
However, everyone is
Comment on attachment 8584608
Unified patch (code + test changes + three times revised new test)
Review of attachment 8584608:
-
Can you please revise the commit message to explain what the patch does?
Something like: Bug 756984 -
Charles, this patch affects more than Thunderbird. I'm not sure what
the usual practices are with regards to stuff that are regression prone
in Thunderbird, but in Firefox, we are usually very conservative, and
prefer to give things more time to bake.
--
You received this bug notification
Created attachment 8584346
Unified patch (code + test changes + twice revised new test)
Thank you very much for the review and all the additional explanation.
I hope I could address your questions in additional comments in the test.
Sadly switching from mousedown/up to click as you had suggested
(In reply to Charles from comment #124)
IMHO the problem is in the coupling between TB and FF. I think it's
quite reasonable that the FF people are more conservative. Who would
want to break a browser with a big market share.
TB on the other hand is client software. An nothing should stop client
Created attachment 8583259
Test case
Here is the test case. Forgive me if the JS is bad, I've never written any,
just copied bits and pieces around.
Two questions:
Where in the mochitest.ini do I put my new test? I put it right at the front
since I don't understand the syntax of skip-if. Does
(In reply to Jorg K from comment #110)
Where in the mochitest.ini do I put my new test? I put it right at the front
since I don't understand the syntax of skip-if. Does that skip the next
line? Perhaps you can suggest a line where it should go. Or say: After such
and such.
Just add a line
I'll revise the test and post a new one in a second.
--
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
Created attachment 8583354
Test case (revised)
If this is good to go, I'll submit another unified patch (code + all
tests), if necessary.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
(In reply to :Aryeh Gregor from comment #84)
A good try line to use by default for editor changes is:
try: -b do -p all -u all[x64] -t none
OK, but how do I send the patch to the try server? I have my level 1 access
rights and I believe SSH is set up correctly. I tried
hg push -f
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from
comment #87)
I realized that I forgot about another case that we need to test. br frames
are not the only reason for a line ending, we can also get line breaks at
block boundaries, for example: divblock 1brspannew line
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment
#88)
Nit: you don't need to mention bug numbers in comments. This information is
available through hg/git blame.
There are many bug numbers in the code (including some that you entered for bug
596506), so this
(In reply to Jorg K from comment #90)
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from
comment #88)
Nit: you don't need to mention bug numbers in comments. This information is
available through hg/git blame.
There are many bug numbers in the code (including some that
(In reply to Jorg K from comment #106)
Pushed to try server (thanks guys for the support!):
https://treeherder.mozilla.org/#/jobs?repo=tryrevision=9782fa678cd1
Treeherder isn't loading for me right now, but someone else who looked
said it seemed fine.
Just out of interest: Why build on all
Comment on attachment 8582633
Patch to fix all three problems: Click, end key, left arrow from start of
previous line (updated coding style)
Review of attachment 8582633:
-
This looks fine to me, and in fact I think it's ready for
Thanks, the mach mochitest-chrome worked, I will supply a fixed test
tomorrow (now after 12 AM here). I assume I can just push a unified
patch with the code and the updated tests to the try server.
--
You received this bug notification because you are a member of Desktop
Packages, which is
In .hg/hgrc (or ~/.hgrc) set up the path alias:
mc-try = ssh://mozi...@jorgk.com@hg.mozilla.org/try
Then
hg qgoto your-patch
hg qnew -m try: -b do -p all -u all[x64] -t none try
hg push -f -r tip mc-try hg qpop hg qdelete try
Or at least that what I do.
--
You received this bug
Created attachment 8582701
Easy fix for test due to new selection behaviour (richtext2)
Removed tests which now no longer fail due to changed selection
behaviour.
I'd appreciate some help with the stuff from comment #97:
How do I run test_selection_move_commands.xul separately and what do I make
Is it worth running it on other systems as well since I found some -
most likely unrelated - problems (see comment #97) when running it
locally on Windows 7? Or are these known problems that always fail?
--
You received this bug notification because you are a member of Desktop
Packages, which is
Created attachment 8582633
Patch to fix all three problems: Click, end key, left arrow from start of
previous line (updated coding style)
Here's the updated code according to the review.
I will review the test failures next.
--
You received this bug notification because you are a member of
Created attachment 8582931
Unified patch (code + test changes) ready for next push to try.
Pushed to try server (thanks guys for the support!):
https://treeherder.mozilla.org/#/jobs?repo=tryrevision=9782fa678cd1
Aryeh: Please help me review the results.
Actually, I followed what was suggested
Comment on attachment 8582701
Easy fix for test due to new selection behaviour (richtext2)
Review of attachment 8582701:
-
Fantastic! r=me.
--
You received this bug notification because you are a member of Desktop
Packages, which
Created attachment 8582686
Easy fix for test due to new selection behaviour (layout/generic)
--
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
These tests are a little mysterious. I wanted to look at
editor/libeditor/tests/test_selection_move_commands.xul first. Sadly
mach mochitest-plain editor/libeditor/tests/test_selection_move_commands.xul
doesn't work? I've run single tests before, but they weren't XUL files.
So I ran
mach
(In reply to Jorg K from comment #97)
These tests are a little mysterious. I wanted to look at
editor/libeditor/tests/test_selection_move_commands.xul first. Sadly
mach mochitest-plain editor/libeditor/tests/test_selection_move_commands.xul
doesn't work? I've run single tests before, but they
Try running the tests locally without your patches if you want to be
sure (hg qpop -a will get rid of them if you're using mq). If they fail
even without your patches, don't worry about it. In theory all tests
should work on all supported platforms and configurations, but in
practice some small
Comment on attachment 8582686
Easy fix for test due to new selection behaviour (layout/generic)
This fixes the failed test in layout/generic. More to come.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
(In reply to Jorg K from comment #92)
OK, but how do I send the patch to the try server? I have my level 1
access rights and I believe SSH is set up correctly. I tried
hg push -f ssh://mozi...@jorgk.com@hg.mozilla.org/try/ *before* coming
across the hg qnew command.
It returned: No changes
Created attachment 8582923
Easy fix for test due to new selection behaviour (move commands)
This is the last of the updated tests.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
I try not to do this very often anymore (useless comments in bugs),
but...
I just wanted to say THANK YOU to Jorg, Ehsan and Aryeh (and anyone else
involved) working on this bug!!
I must say, after the scare announcement from Mozilla about not directly
funding Thunderbird anymore, I was worried,
Comment on attachment 8582360
Patch to fix all three problems: Click, end key, left arrow from start of
previous line
Review of attachment 8582360:
-
Some feedback on your patch so far.
::: layout/generic/nsFrame.cpp
@@ +3555,3 @@
BTW, Jorg, since your fix at least improves the situation where someone
clicks at the end of the line, I'd be fine with landing it with a test
case in this bug if you prefer to move the rest of the investigation and
the fixes into another bug. Whichever way you prefer is fine. :-)
--
You
Looks like Aryeh answered your questions (thanks Aryeh!)
I realized that I forgot about another case that we need to test. br
frames are not the only reason for a line ending, we can also get line
breaks at block boundaries, for example: divblock 1brspannew line
here/spandivblock2/div/div We
A good try line to use by default for editor changes is:
try: -b do -p all -u all[x64] -t none
This will build on all platforms (to detect compile errors), and will run tests
only on 64-bit Linux (to avoid wasting resources). If there might be
platform-specific test failures, remove the
Thanks for the suggestions made in comment #78. I'm testing with
spanbifont face=Courier newfoo bar on the same
line/font/i/b/spanbr
spanbifont face=Arialfoo bar on the same
line/font/i/b/spanbr
strongfoo bar on the same line/strongbr
This is sstrikethrough/sbr
25 msup2/supbr
Created attachment 8582014
four line change to fix a 10 y/o problem ;-)
Here's a new patch. This fixes click beyond end of line *and* end key.
Still open: Left arrow at the start of the subsequent line.
--
You received this bug notification because you are a member of Desktop
Packages, which is
Cool, so yeah, a fix to those two additional cases + the unit tests is
probably all that we'd need here!
--
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
Okay, this caused some try failures. One of them is an unexpected pass in
richtext2, which is good! It means you just have to update the test so it
knows we're supposed to pass now. In the case of richtext2, you want to edit
the file
Created attachment 8582360
Patch to fix all three problems: Click, end key, left arrow from start of
previous line
Can you please push this to the try server for me and tell me the exact steps
to do it. I was reading
https://wiki.mozilla.org/ReleaseEngineering/TryServer#How_to_push_to_try and
(In reply to :Aryeh Gregor from comment #77)
For the record, from black-box testing of WebKit a few years ago, it looked
like it normalized the selection after every change. Even if you called
.addRange(), it copied the range and then stuck the selection endpoints
inside a nearby text node if
The failure in editor/libeditor/tests/test_selection_move_commands.xul
also needs looking at. Otherwise, looks good!
--
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:
For the record, from black-box testing of WebKit a few years ago, it
looked like it normalized the selection after every change. Even if you
called .addRange(), it copied the range and then stuck the selection
endpoints inside a nearby text node if available, etc. I think it's
taking things too
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
The try results look good to me, so you just need to include an
automated regression test (mochitest) and you can ask a reviewer to
approve it to be included in Firefox. You want to add a file patterned
off something like this: https://dxr.mozilla.org/mozilla-
@Aryeh: Yor comment really surprises me given the following:
In comment #68 Ehsan said:
Good start, but this is still *far* from being ready for review.
In comment #60 Ehsan said:
This affects more than just Thunderbird, and concerns behavior that is
visible to Web pages.
Web content can
Oops, I missed that part of comment #68 -- should have read more
carefully. I don't know what more there is to do, since it passed a try
run. But that's why Ehsan is in charge and not me. ;) In any event,
you will need a test at the end of the day, so you could still go ahead
and write it now.
When you have a minute, could you please look at the results or instruct
me, how to interpret them.
--
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
Comment on attachment 8576888
three line change to fix a 10 y/o problem ;-)
Review of attachment 8576888:
-
Good start, but this is still far from being ready for review. Did you
push this to the try server? Please include the
Sorry, you need to help me out here. Never done it before.
I will get the access rights as discussed on IRC.
--
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
(In reply to Archaeopteryx [:aryx] from comment #70)
Pushed to Try:
https://treeherder.mozilla.org/#/jobs?repo=tryrevision=bb676357b6c9
Canceled this as it misses the most important part of the tests,
mochitests. Repushed:
https://treeherder.mozilla.org/#/jobs?repo=tryrevision=8b34acaf40c3
Pushed to Try:
https://treeherder.mozilla.org/#/jobs?repo=tryrevision=bb676357b6c9
--
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
You are correct, I was in e10s mode and there was another process
plugin-container. Now I switched that off. I had noticed that my
debugging had become strange, but couldn't figure out why. So thank you!
Before considering changing the selection behaviour, I'd like to repeat
my question, but I
(In reply to Jorg K from comment #60)
The more conservative approach would be not to change the selection
behaviour but to maintain/re-establish the correct type in state after the
click. That is what IE does: The DIV is selected, but typing continues in
the correct font, see comment #54.
Created attachment 8576888
three line change to fix a 10 y/o problem ;-)
Skipping brFrames when determining the closest frame in a line. Can only
skip if the brFrame isn't the only selectable non-empty frame in the
line. Otherwise one couldn't click in that line at all.
Need to be careful since
Any idea why TypeInState::NotifySelectionChanged is never called when clicking
around in a div contenteditable?
http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/TypeInState.cpp#75
Is that not a listener to listen to the selection changing? Maybe that
has something to do with our
I don't think it's reasonable to start traversing the DOM tree every
time that we want to perform an editing operation to find the right
styles/properties to use. It's a lot of unnecessary work. It should be
a lot easier to normalize the selection in a sane way to prevent it from
going into
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
I've done a little debugging.
On every mouse move event we get this:
Entering PresShell::HandleEvent, frame=06EA9488
PresShell::HandleEvent calling nsLayoutUtils::GetEventCoordinatesRelativeTo
PresShell::HandleEvent calling FindFrameTargetedByInputEvent
PresShell::HandleEvent assigning frame =
(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
It's not going past static FrameTarget GetSelectionClosestFrameForLine ()
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#3540
... nor static FrameTarget GetSelectionClosestFrameForBlock nor static
FrameTarget GetSelectionClosestFrame.
Also, very little processing in
From someone who is 1% knowledgeable on this stuff...
since the problem is that the cursor is returned, after clicking outside on the
line being returned to, to a place outside the last (hidden) tag...which I have
always seen to be / font...could you not simply detect if that tag existed
and
Created attachment 8576320
A more comprehensive text
The more conservative approach would be not to change the selection
behaviour but to maintain/re-establish the correct type in state after
the click. That is what IE does: The DIV is selected, but typing
continues in the correct font, see
Created attachment 8576184
Alternate test, take 2, dumping out more info
Results:
FF: start=DIV(2) - end=DIV(2)
IE 10 and 11 (current): start=DIV(2) - end=DIV(2)
Chrome 41 (current): start=#text(10) - end=#text(10)
Opera 28 (current): start=#text(10) - end=#text(10)
Safari 5.1.7 (old):
(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
(In reply to Jorg K from comment #38)
Coming back to the suggestion from comment #25 and looking in
nsFrame::HandlePress.
I traced it down into ns[Text]Frame::GetChildFrameContainingOffset with a
call stack of:
nsFrame::GetChildFrameContainingOffset *or*
Created attachment 8574843
Stripped down Midas demo, also alerts on clicks and dumps out info
--
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
More results:
Safari (5.1.7, had it on some old machine): Same behaviour as Chrome.
Opera (27.0, fresh install): Same behaviour as Chrome.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
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
Created attachment 8575104
Alternate test, much simpler
Here is a much simplified test alternate.htm. Results:
FF: DIV, wrong font
IE: DIV, correct font
Chrome and Opera: #text, correct font.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed
CORRECTION TO PREVIOUS (dang we need an edit capability)
That's because there is a hidden / font tag at the end of the line
(but AFTER = to the right of, the spot where you are typing).
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
Jorg K - re Comment 36 (Just noticed: Not only the font gets lost, also
the font size can get lost. For example when replying to a message in a
small font, the size gets bigger when clicking at the end after
correcting something in the same line.)
When I'm typing and correct something, the font
maybe-the-one - re comments 47 48: thanks for the clarifying
explanation.
--
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
Maybe better to look further up in call stack, for example
PresShell::HandlePositionedEvent.
--
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
1 - 100 of 185 matches
Mail list logo
