composer changes font mid email
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Thunderbird |
Fix Released
|
High
|
|||
thunderbird (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
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.
In Mozilla Bugzilla #203810, Esther (esther) wrote : | #5 |
nomintaing because this is a new feature and mistakenly backspacing in a reply
can look as though this feature doesn't work all the time.
In Mozilla Bugzilla #203810, Esther (esther) wrote : | #6 |
Also happens when Forwarding Inline, the prepopulated hearder of the forwarded
message has the same affect at the prepopulated text in a reply.
In Mozilla Bugzilla #203810, Sspitzer (sspitzer) wrote : | #7 |
over to shuehan
In Mozilla Bugzilla #203810, Samir-bugzilla (samir-bugzilla) wrote : | #8 |
adt: nsbeta1-
In Mozilla Bugzilla #203810, Mcow (mcow) wrote : | #9 |
*** Bug 251364 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #203810, Mcow (mcow) wrote : | #10 |
*** Bug 245581 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #203810, Mcow (mcow) wrote : | #11 |
See (from the dupe) bug 245581 comment 1.
In Mozilla Bugzilla #203810, Mcow (mcow) wrote : | #12 |
*** Bug 273622 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #203810, Mcow (mcow) wrote : | #13 |
*** Bug 287013 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #203810, Mcow (mcow) wrote : | #14 |
*** Bug 353424 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #203810, Mcow (mcow) wrote : | #15 |
*** Bug 373904 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #203810, Rob Hasselbaum (rhasselbaum) wrote : | #16 |
Created attachment 260245
Use HTML font preference for reply and forward headers
With this patch, Thunderbird uses the user's preferred HTML font face/size for reply and forward header text. I added logic in nsMsgCompose and the MIME routines to wrap header text in font markup if we are in HTML composition mode and a non-default font face or size was chosen in preferences.
In Mozilla Bugzilla #203810, Rob Hasselbaum (rhasselbaum) wrote : | #17 |
Created attachment 260269
Updated patch that addresses TT special case
Upon further testing, I discovered that the "Fixed Width" meta-font requires use of the TT tag instead of FONT. Updated the patch to address this special case.
In Mozilla Bugzilla #203810, Mscott-mozilla (mscott-mozilla) wrote : | #18 |
Comment on attachment 260269
Updated patch that addresses TT special case
some minor nits:
+ nsXPIDLString font_face;
font_face should be a nsString
This:
+ if(NS_LITERAL_
should be
font_face.
and does it need to be a case insensitive compare?
Can this:
aText.Append(
be aText.AppendLit
Use a nsString here:
+ nsXPIDLString font_size;
could this be a simple switch statement?
+ if(NS_LITERAL_
+ font_size.
+ else if(NS_LITERAL_
+ font_size.
+ else if(NS_LITERAL_
+ font_size.
+ else if(NS_LITERAL_
+ font_size.
+ else if(NS_LITERAL_
+ font_size.
+ else
+ font_size.
if not, the comparison statements should be of the form:
if (font_size.
* NS_GetLocalized
why don't we just read the pref directly from the pref service instead of using this localized unichar preference routine. I don't think this pref is a localized pref.
I haven't looked at the mime part yet, I'll try to get to that soon! thanks for taking a look at this.
In Mozilla Bugzilla #203810, Notagain (notagain) wrote : | #19 |
this still happens with tb 3.0b2pre nightlies. both the reply and forward header cases. any work done? will this be solved anytime soon (3.0 final perhaps)?
In Mozilla Bugzilla #203810, Mozilla-mawer (mozilla-mawer) wrote : | #20 |
This would be a welcome fix in Thunderbird 3 -- using a sans serif font (eg. Arial) in Thunderbird at the moment looks very unprofessional, as whenever you reply you end up with a serif font for the "XYZ wrote" text...
In Mozilla Bugzilla #203810, Gjunk (gjunk) wrote : | #21 |
I have same problem using 3.0b2 nightly as of 20090513.
Also - the font size selector is too coarse - medium or large - we really need to be able pick the font size we use.
thanks.
In Mozilla Bugzilla #203810, Rick (rick2910) wrote : | #22 |
Agree fully with comment #17: please create a dropdown with font sizes to choose from instead of 'larger' and 'smaller' buttons.
In Mozilla Bugzilla #203810, Gjunk (gjunk) wrote : | #23 |
Bug is still there with build as of 20090528 .. both bugs - the font not suddenly switching away from user specified default to something else and also the inability to choose a font size.
In Mozilla Bugzilla #203810, Gary-rumblingedge (gary-rumblingedge) wrote : | #24 |
Comment on attachment 260269
Updated patch that addresses TT special case
Obsoleting due to rejected review.
In Mozilla Bugzilla #203810, Gjunk (gjunk) wrote : | #25 |
I dont understand comment #20 at all.
I think the bug is this:
Hit reply - start typing - your preference font/size is chosen - in mid type is switches to something else - different font different size.
My default is sans-serif/large - it usually switches to variable/medium.
End resault is reply contains new text 1/2 in preference compose font and 1/2 in thunderbird default font.
WHy is this not a bug - this happens with this build:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090617 Lightning/1.0pre Shredder/3.0b3pre ID:20090617031506
Which is hardly an obsoleted build.
In Mozilla Bugzilla #203810, Bugzilla-standard8 (bugzilla-standard8) wrote : | #26 |
(In reply to comment #21)
> I dont understand comment #20 at all.
...
> Which is hardly an obsoleted build.
The comment didn't say the bug was obsolete, it said the *patch* was obsolete.
In Mozilla Bugzilla #203810, Gjunk (gjunk) wrote : | #27 |
Ooooohhhh silly me ..
sorry
:-|
In Mozilla Bugzilla #203810, Ulysse (ulysse) wrote : | #28 |
*** Bug 480815 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #203810, Josh Kinnison (kinnison-josh) wrote : | #29 |
This bug occurs even if you just click an area with a non-default font. It is amazingly frustrating. It feels like playing Minesweeper when all I want to do is write an email.
ricardisimo (ricardisimo) wrote : | #1 |
Not one bite in over a month? Would no one even like to see an email from me?
bmaupin (bmaupin) wrote : | #2 |
I had this same problem and it drove me nuts. My problem is that when I reply to an existing email, the font will be "Helvetica, Arial". This is what's listed when I go to Edit --> Preferences --> Composition --> General --> HTML --> Font. But if I click away from the body of the email, even if I click to another part of the composition window such as the subject box, as soon as I click back to the body, the font will change to some kind of serif font. It says "Variable Width" in the font box. I think it's whatever font is listed in Edit --> Preferences --> Display --> Formatting --> Fonts --> Default font. My configuration says the default font is "serif."
If I type a completely new message, I don't seem to have the problem as much.
My solution was to simply set the font settings in the locations I mentioned above to the same font. So I went to Edit --> Preferences --> Display --> Formatting --> Fonts --> Default font, set it to Arial, and it hasn't happened again, yet--it wasn't that long ago that I made the change, so we'll see how well it works.
In Mozilla Bugzilla #203810, Mike001 (mike001) wrote : | #30 |
*** Bug 536613 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #203810, Mike001 (mike001) wrote : | #31 |
Bug 533613 was DUP'd to this bug because the reporter of Bug 533613 agreed that the symptoms and STR described in Bug 273622 matched what he was trying to report. It is not clear to me that this bug report (203810) actually describes those same symptoms, nor that the proposed fix will fix the problem noted in the Description in Bug 273622. Therefore, if the patch for this bug WILL NOT address the problem noted in Bug 273622, I respectfully request that the assignee of this bug:
a) Reopen Bug 273622; and,
b) Mark Bug 533613 as a duplicate of Bug 273622.
Doing so will ensure that the problem noted in Bug 273622 DOES get fixed.
In Mozilla Bugzilla #203810, N-hillyer (n-hillyer) wrote : | #32 |
Can we assume that this is an HTML problem only? If so I have failed to find where it is clearly stated.
I am not sure if my remarks below will be of any help to those working on this bug or users who end up here.
I seldom compose with HTML and don't see this bug with TB 3.1.2 on a G4 with OS X 10.5.8.
However, I did have a difficult to track down font issue with an identical G4. I eventually discovered that most of the considerable fonts in
/Applications/
In Mozilla Bugzilla #203810, Sgtfool (sgtfool) wrote : | #33 |
A variation on this is that it also loses the default font when I click on the subject line and then click back to my text.
Although I love thunderbird, about once a month I search for ways to get outlook to replicate my most beloved add-on's because it is so frustrating to use an e-mail program that will not let me control my font style (and size).
In Mozilla Bugzilla #203810, Gjunk (gjunk) wrote : | #34 |
Bug is still here in 3.1.7 nightly as of last night ...
amazing this bug is over 7 years old ...
do the experts know what to fix is yet ?
font flipping makes for ugly emails ;-( ...
bmaupin (bmaupin) wrote : | #3 |
Wow, looks like this bug just might be 8 years old. Guess I'd better get used to it...
Changed in thunderbird: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #35 |
Truly astounding as this bug comes up to almost 8 years old - I am using 3.1.10pre and this bug is still present - it bites me pretty much every week - sometimes on the next line when composing and sometime in the middle of a line and yes with html email.....
Surely someone could give this bug a little love and sort it out once and for all?
In Mozilla Bugzilla #203810, Gjunk (gjunk) wrote : | #36 |
also bug is still in todays Miramar 3.3a4 pre ... bit sad really .. :-(
Bug is assigned to nobody presently ... there were some suggestions on how to fix this in 2007 ... may not help tho ..
McFly81 (christian-lange-81) wrote : | #37 |
Still present TB 3.1.9 (Ubuntu 12.04 LTS). When I compose a Mail. the font-size and font-type keeps changig. Every few lines I have to manually mark my text and change font-size/type myself. Very annoying.
Additionally, when I copy-paste some text (e.g. a URL from my browser address bar) this text gets some formatting. Mosty some ugly one not in line with the remainder of the mail.
McFly81 (christian-lange-81) wrote : | #38 |
Sgtfool wrote: "A variation on this is that it also loses the default font when I click on the subject line and then click back to my text."
I can confirm that.
In Mozilla Bugzilla #203810, N-hillyer (n-hillyer) wrote : | #39 |
I doubt that this 8 year old bug will ever be fixed.
Perhaps users should use text rather than HTML.
Changed in thunderbird (Ubuntu): | |
status: | New → Confirmed |
In Mozilla Bugzilla #756984, Standard8 (standard8) wrote : | #86 |
STR:
1) Open midas demo
2) Type three lines of text
3) Select a different font for the middle line
4) go to end of first line, type some text
=> Font is the same as the first line, because it is default font.
5) go to end of second line, type some text
=> Font is the original (default) font, not the font selected in step 3.
Alternate STR:
a) Open midas demo
b) Type a word
c) select a different font, type a different word
d) click somewhere after the end of line (e.g. not changing cursor position)
e) type some more text
=> Font is now back to the original/default font.
In Mozilla Bugzilla #756984, Fm-mozbugs (fm-mozbugs) wrote : | #87 |
This is happening because moving the cursor ANYWHERE, then clicking back at the end of the typing line moves the input point past the hidden [/ font ] tag at the end of that line. Thus the font reverts to default.
Alternate steps to repeat:
1. be typing
2. move cursor somewhere above the typing point (e.g. to insert text within previous words)
3. move cursor back to end of last line
4. Result: font changes to variable width because the replacement of cursor at the end of the line has moved it outside the [/ font ] tag.
In Mozilla Bugzilla #756984, Jsabash (jsabash) wrote : | #88 |
Testing with Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/15.0 Thunderbird/15.0a1 20120521030204
It seems this issue is much improved since the landing of bug 750569
I have not been able to reproduce the loss of font by moving the cursor around with left-click mouse.
I did however see some anomalies with extra br tags being applied, and one case of a missing ending font tag.
But these are a small price to pay for the basic fix.
I'll test extensively with various fonts and html tag insertions over the coming days. But so far, it looks very encouraging.
In Mozilla Bugzilla #756984, Jsabash (jsabash) wrote : | #89 |
It seems this issue is much improved since the landing of bug 750569
s/b bug 590640 sorry about that.
(some of these results probably should go into bug 590640) but as they pertain to this bug, the issue where the cursor was positioned outside of the font tag has been fixed somewhere between the ESR and our current Beta TB13 (bug number?)
Testing steps
Type in:The quick brown fox
Go back to "brown" and correct it to "red"
reposition the cursor (with mouse) just after "fox"
Type in:" jumped."
Here is the resulting code generated:
ESR:
<font face="Arial">The quick red fox</font> jumped.
beta tb13
<font face="Arial">The quick red fox jumped.<br>
</font>
current trunk
<font face="Arial">The quick <font face="Arial"
jumped.<br>
</font>
The ESR behavior is obviously wrong
TB13 is correct
Current trunk displays the correct font, but adds extra font tags in the process
I suppose this is a result of the fix in bug 590640 "remembering" the type in state.
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #90 |
(In reply to Mark Banner (:standard8) from comment #0)
> STR:
>
> 1) Open midas demo
> 2) Type three lines of text
> 3) Select a different font for the middle line
> 4) go to end of first line, type some text
>
> => Font is the same as the first line, because it is default font.
>
> 5) go to end of second line, type some text
>
> => Font is the original (default) font, not the font selected in step 3.
WFM on nightly 15.0a1 (2012-05-21).
> Alternate STR:
>
> a) Open midas demo
> b) Type a word
> c) select a different font, type a different word
> d) click somewhere after the end of line (e.g. not changing cursor position)
> e) type some more text
>
> => Font is now back to the original/default font.
Also WFM.
(In reply to maybe-the-one from comment #1)
> Alternate steps to repeat:
>
> 1. be typing
> 2. move cursor somewhere above the typing point (e.g. to insert text within
> previous words)
> 3. move cursor back to end of last line
> 4. Result: font changes to variable width because the replacement of cursor
> at the end of the line has moved it outside the [/ font ] tag.
Also WFM.
(In reply to Joe Sabash from comment #3)
> Testing steps
> Type in:The quick brown fox
> Go back to "brown" and correct it to "red"
> reposition the cursor (with mouse) just after "fox"
> Type in:" jumped."
>
> . . .
>
> current trunk
> <font face="Arial">The quick <font face="Arial"
> jumped.<br>
> </font>
Filed as bug 757371. Thanks! I'll work on fixing that right away. Is there anything else here that needs to be fixed, or should we close this as a duplicate of bug 590640?
In Mozilla Bugzilla #756984, Charles (tanstaafl-libertytrek) wrote : | #91 |
I know I'm probably going to get a lot of push back on this, but I really, really think that these editor fixes should be back-ported to the ESR release, not require ESR users to wait almost a full YEAR before seeing them...
Enterprises will benefit MUCH more than home users with these fixes, as they are very frustrating for users who use HTML email, and most enterprise users do want to use HTML, like it or not...
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #92 |
According to <https:/
Not my decision, though, so feel free to request it if you want to argue with the people whose decision it is.
In Mozilla Bugzilla #756984, Standard8 (standard8) wrote : | #93 |
I can still reproduce this, but I think my STR weren't complete.
The single line case I can sometimes reproduce by clicking at the end of the line (rather than using the keyboard). It seems to be more reproducible if there are spaces in the line.
More test cases as well, being a bit more explicit about my actions and using 2012-05-21 nightly on Mac:
1) Open midas demo
2) Type three lines of one-word text, e.g.
three
lines
text
3) double-click the middle line to highlight
4) select a different font
5) press right-arrow to unselect and go to end of line.
6) Start typing
=> Incorrect font used.
Slightly different case:
1) Open midas demo
2) Type three lines of one-word text, e.g.
three
lines
text
3) double-click the middle line to highlight
4) select a different font
5) Click at the end of the last line
6) Use the left-arrow five times to go past the "text" and onto the end of the second line.
7) Type some more text
=> Incorrect font used.
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #94 |
(In reply to Mark Banner (:standard8) from comment #7)
> I can still reproduce this, but I think my STR weren't complete.
>
> The single line case I can sometimes reproduce by clicking at the end of the
> line (rather than using the keyboard). It seems to be more reproducible if
> there are spaces in the line.
>
> More test cases as well, being a bit more explicit about my actions and
> using 2012-05-21 nightly on Mac:
Thanks!
> 1) Open midas demo
> 2) Type three lines of one-word text, e.g.
>
> three
> lines
> text
>
> 3) double-click the middle line to highlight
> 4) select a different font
> 5) press right-arrow to unselect and go to end of line.
> 6) Start typing
>
> => Incorrect font used.
This doesn't quite work for me (15.0a1 (2012-05-21) on Ubuntu 11.10). When I press right-arrow in step 5, it goes to the next line, not the end of the line. But if I press right-arrow then left-arrow, I can reproduce. So confirmed.
> Slightly different case:
>
> 1) Open midas demo
> 2) Type three lines of one-word text, e.g.
>
> three
> lines
> text
>
> 3) double-click the middle line to highlight
> 4) select a different font
> 5) Click at the end of the last line
> 6) Use the left-arrow five times to go past the "text" and onto the end of
> the second line.
> 7) Type some more text
>
> => Incorrect font used.
Confirmed. Thanks! We need to normalize the selection better here.
In Mozilla Bugzilla #756984, Mike-cloaked (mike-cloaked) wrote : | #95 |
I am not sure if the patches for this bug apply currently to 16a2 but for yesterday's 16a2 I still have a problem with the following test:
1) Compose a new mail and type several lines of text into the main body of the mail.
2) Highlight all of the new text in the compose window.
3) Select Format->Size and increase the size to extra large.
4) Now (realising you want to add some more text) click in the middle of the text area and type in new text, and edit some of the text already there.
5) Nothing seems wrong at this stage but if the mail is sent then sometimes it seems to be fine in the copy that is actually sent, as confirmed by what appears in the copy in the Sent folder, but sometimes the font size is broken into sections of different sizes despite it all looking uniform at the point the Send button is about to be clicked. This seems to have been the case for some time.
If that pertains to a different bug please refer to the relevant bug number - thanks.
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #96 |
As a general rule, filing new bugs is better than posting in an existing bug if you're unsure whether it's the same bug. If two bugs are duplicates, they can be marked as such, but a single bug can't be easily split into two. So please file a new bug. Thanks.
In Mozilla Bugzilla #756984, Mike-cloaked (mike-cloaked) wrote : | #97 |
OK will do - though recent testing with Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20120813 Thunderbird/16.0a2 ID:20120813042011 gave no further recurrence - if I see a recurrence I will post a new bug report for the later version with full details.
In Mozilla Bugzilla #203810, 5u-mozilla (5u-mozilla) wrote : | #40 |
I have come to the edge of abandoning Thunderbird due to this 9 1/2 year old bug. People reply to my replies and I see that the format of what I sent them makes it look like it was written by a 7-year old with crayons. It's a hodgepodge of two different fonts/sizes -- embarrassing and unprofessional.
Is there a work-around or a fix? (People working with TB 3 in 2010 had some success with setups involving the add-ons Quote & Reply and QuoteandCompose
In Mozilla Bugzilla #203810, Cursus-publicus (cursus-publicus) wrote : | #41 |
A while ago I switched my PPC to SeaMonkey 2.13 which overcame a whole raft of bugs although I am not sure about this particular bug.
Details at: http://
In Mozilla Bugzilla #203810, 5u-mozilla (5u-mozilla) wrote : | #42 |
At seamonkey-
So unless they forked development of the email client code, a first guess would be that you share this bug.
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #43 |
Yes having this formatting bug is very tiresome indeed as a long time user of Thunderbird and it is still very much a bug in version 18a2!
In Mozilla Bugzilla #203810, Cursus-publicus (cursus-publicus) wrote : | #44 |
I have not been able to replicate the originally described bug with the latest SeaMonkey. Is it accurately described? Should instruction '1' read 'below' rather than 'above'?
I can say that clicking elsewhere such as in the subject line picks up the default font but this was not the originally described bug.
In Mozilla Bugzilla #203810, 5u-mozilla (5u-mozilla) wrote : | #45 |
It's true -- I would say that various comments round out the description of the various manifestations. The original bug report captured fewer of those, but as far as I know it's accurate as far as it goes.
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #46 |
https:/
is relevant/related to this bug too.
In Mozilla Bugzilla #203810, Cursus-publicus (cursus-publicus) wrote : | #47 |
(In reply to John Hupp from comment #39)
I prefer to be able to test a single accurately described bug. As I said, I am unable to replicate the original bug with the latest SeaMonkey - perhaps it has been fixed.
In Mozilla Bugzilla #203810, 5u-mozilla (5u-mozilla) wrote : | #48 |
(In reply to Mike Cloaked from comment #40)
> https:/
>
> is relevant/related to this bug too.
I see that that bug is not assigned to anyone either. Perhaps if a developer ever digs into it, a single cause will be found for the similar bad behaviors.
In Mozilla Bugzilla #203810, lengo (pcunger) wrote : | #49 |
(In reply to Neville Hillyer from [url=https:/
I don't know SeaMonkey, but I can confirm this is still an issue in Thunderbird 16.0.2 (latest version on the 'release update channel'). And I don't know how recent a build TB 18a2 is, but Mike Cloaked reports (in [url=https:/
As for a "single accurately described bug" I think this has enough related manifestations (e.g., Mike Cloaked comment #40) to make that a difficult precondition.
My 'workaround' used to be to type a word (usually the person's name to whom I was writing), hit Enter, type my name on a new line(i.e., the last thing in the message) and then move up to the end of the first line, hit Enter again, and type (and edit) the body of my message. This workaround worked (i.e., preserved formatting) until v. 15 (I think... It is sometimes difficult to tell when something like this manifests, because, from all appearances, the message looks OK [I confess, I don't often check the formatting of the messages in my Sent folder]. I only began noticing it in certain replies from others that had included my message in the reply).
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #50 |
OK I did a test which seems to throw up the inconsistent font issue is a totally reproducible way - and the test is very simple indeed. I am using version 18a2 linux 64 bit version from 4th November but this test can be applied to any version that other testers following this bug can also try.
The test is as follows:
1) Click "Write" to begin composing a new mail. My default font is set as medium, and sans-serif.
2) Now type direct into the main text box "This is a test " -
3) Now highlight the text you have just entered with the mouse and right click and copy.
4) With the cursor set at just after the last space in the text entered now right click and select "Paste without Formatting"
The result is that the two phrases which should be identical are now of different font size.
I will attach a screenshot in a sec showing the two different fonts in this text as highlighted.
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #51 |
Created attachment 681414
image showing the result of the font inconsistency
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #52 |
By the way I use a simple html signature file - but I don't know if that makes any difference. Also the box showing the font changes from sans-serif to "mixed" as soon as I highlight the combined text in the test from comment #44
In Mozilla Bugzilla #203810, Cursus-publicus (cursus-publicus) wrote : | #53 |
(In reply to paul from comment #43)
Send it to yourself and post the received HTML source here so that we can see what happened.
In Mozilla Bugzilla #203810, Fm-mozbugs (fm-mozbugs) wrote : | #54 |
Folks, the reason most or all of these manifestations(
when you first type "This is a test " or what ever at the top of the entry area, what is really there is
"This is a test " {/font}
with [] instead of {} of course.
Now, if at that point, you move the cursor ANYWHERE, for any reason, and then click it back at the end of the line, or if you insert text, you are now typing to the right (after) the {/font} tag, and being outside the end-font tag, will now be using the default font.
In Mozilla Bugzilla #203810, Gjunk (gjunk) wrote : | #55 |
Sort of - I have changed the default font to large sans-serif (LSF) via preferences-
What I find is that in spite of my internal font being LSF tb will switch back to TIF - that is most certainly a bug. I should only get my LSF.
The bug for me is that my [changed] default font is sometimes respected and sometimes not ...
In Mozilla Bugzilla #203810, Cursus-publicus (cursus-publicus) wrote : | #56 |
Too many different issues are getting confused here. The only common thread I can see is dissatisfaction with TH's less than perfect WYSIWYG editor.
I have spent the last 15 years manually editing HTML so I can see some of the compromises TB's designers have made.
It would be useful if all contributors tried to understand the HTML used which is why I have tried to get people to post to themselves and then examine the incoming HTML.
In Mozilla Bugzilla #203810, lengo (pcunger) wrote : | #57 |
(In reply to Neville Hillyer from comment #47)
> (In reply to paul from comment #43)
>
> Send it to yourself and post the received HTML source here so that we can
> see what happened.
I'm not smart enough to be able to recreate the problem, but here's a bit of HTML source from a message where this did go wrong:
<br>
<meta content="text/html; charset=UTF-8" http-equiv=
<font face="Tahoma">Some text here.</font> Followed by more text here.<br>
<br>
Paul<br>
Everything after </font> is smaller than that which is before it. Let me know if you need more of the HTML source stuff and I'll work at removing 'particulars' (i.e., addresses, etc.)
In Mozilla Bugzilla #203810, Fm-mozbugs (fm-mozbugs) wrote : | #58 |
(In reply to paul from comment #51)
> (In reply to Neville Hillyer from comment #47)
> > (In reply to paul from comment #43)
> >
> > Send it to yourself and post the received HTML source here so that we can
> > see what happened.
>
> I'm not smart enough to be able to recreate the problem, but here's a bit of
> HTML source from a message where this did go wrong:
>
> <br>
> <meta content="text/html; charset=UTF-8" http-equiv=
> <font face="Tahoma">Some text here.</font> Followed by more text
> here.<br>
> <br>
> Paul<br>
>
> Everything after </font> is smaller than that which is before it. Let me
> know if you need more of the HTML source stuff and I'll work at removing
> 'particulars' (i.e., addresses, etc.)
That is exactly what I described in my post previously. I looks strongly as if you moved the cursor after typing 'Some text here' (click back to correct a spelling, insert some text, or something like that). Note that the 'Followed by more text here' is AFTER the [ /font ] tag, which ended your selected font at that point.
In Mozilla Bugzilla #203810, Gjunk (gjunk) wrote : | #59 |
Exactly - so why does it not continue using the font the user defined as their default font? When the user has defined a default font it should be used whether or not they moved their cursor.
Remember the bug here is having a user preference set for their default font - and finding this is not properly honored in above situation(s).
In Mozilla Bugzilla #203810, 5u-mozilla (5u-mozilla) wrote : | #60 |
OK, so now we see how the bad behavior is being executed in HTML.
Maybe I'm misreading some of the comments, but is anyone here implying that this is not a bug? That a user-set default Composition font should not be respected as the default in cases 1 through N? Gene C gets right back to the main point: This is a bug.
And as I posted earlier, it's a bug that has me sending out unprofessional, embarrassing emails. If I can't find a solution, I expect that I'll abandon Thunderbird. A shame, since I'm an open source devotee, but it's more important to me that it works right.
But first, on the topic of finding a solution: I observed today the "VOTE" feature in the header of this bug report. I clicked on that, then the Change Your Vote check-box, then Save Changes. Each of us who is registered here and logged in apparently gets 1000 votes, presumably to highlight which bugs we think are most important. My vote just bumped the count up to 21, but that still places it in the Normal Importance category. LET'S ALL VOTE.
In Mozilla Bugzilla #203810, Fm-mozbugs (fm-mozbugs) wrote : | #61 |
No, no one is saying it is not a bug. I was just showing what was happening that was causing (at least this particular manifestation) to happen.
You are at risk of invoking the bug if you do anything other than straight, continuous typing. Hitting Enter does not invoke the bug.
A trick to help solve it is to hit Enter several times as the FIRST thing you type. This moves the hidden [ /font ] tag down the page a bit. So, if you move the cursor, then move it back at the end of your actual typing, it is still above the tag.
And yes, do VOTE for this.
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #62 |
Let's face it very few people will type a straight uninterrupted email and hit send - and the longer the text the more likely it is that one will go back and change sentences and add or remove parts of what had been typed - hence any reasonable compose facility should accommodate that so that the best experience can be enjoyed by the user rather than ending up that the user is irritated and frustrated by the experience. So basically is is poor design and not showing proper considerable of normal user experience. So yes it should be fixed and yes everyone seeing this report should vote for it to get sorted out!
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #63 |
It might also be nice if users voted on the related bug at https:/
In Mozilla Bugzilla #203810, 5u-mozilla (5u-mozilla) wrote : | #64 |
Yes, I agree that your observation can help users work around the bug in many cases.
But there seemed to be an implication in some comments that "default font" had a rather limited meaning, and that the program was therefore working per design.
I'll grant that I may have misinterpreted to arrive at that, but since the bug is 9 1/2 years old, one has to wonder if the development team isn't aware that this is not only maddening but an actual show-stopper for a number of users, or if they are aware and simply disagree with that assessment.
In any case, voting to bump up the Importance to something above Normal is one of the things non-developers can do to try to get some qualified attention directed at this.
In Mozilla Bugzilla #203810, 5u-mozilla (5u-mozilla) wrote : | #65 |
My Comment 58 was in reply to maybe-the-one's Comment 55.
And regarding Mike Cloaked in Comment 57: Done!
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #66 |
(In reply to maybe-the-one from comment #55)
> A trick to help solve it is to hit Enter several times as the FIRST thing
> you type. This moves the hidden [ /font ] tag down the page a bit. So, if
> you move the cursor, then move it back at the end of your actual typing, it
> is still above the tag.
The way that the composer should work is that it "automatically" moves the [/font] tag to immediately before the signature or if no signature then keep it at the end - and then any changes to the fonts "initiated" by the user whilst composing should have their own [font] and [/font] embedded around any text with a different font to the default font.
Also another work around is to simply enter all the text and corrections/
In Mozilla Bugzilla #203810, Fm-mozbugs (fm-mozbugs) wrote : | #67 |
Of course it should work in the first place.
I don't understand all these comments saying that. That is what the whole thread is about!
People post some method to make life easier, and immediately the response is "but it should work without that." Duh, of course. That doesn't make the suggestions useless, such as the Enters before typing, or highlight and set the font after typing, both of which are tools for living with the bug UNTIL IT IS FIXED (if ever).
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #68 |
Just an aside comment - but the gmail compose window in the new google webmail interface works perfectly well for html mail and does not have the problems we have in Thunderbird - OK that is a web interface but it does mean that it is possible to have a compose window that handles html mail perfectly well!
In Mozilla Bugzilla #203810, Cursus-publicus (cursus-publicus) wrote : | #69 |
I would rather see a simpler totally different approach adopted by the designers:
Always use the defined font style (this would be the default font style until changed by the tool-bar) irrespective of cursor position or history.
I think most editors do this.
It would have the disadvantage that any text added to the middle of a paragraph would use the current font style rather than that of the paragraph but it would be immediately visible and easy to correct especially if a 'change current style to that of highlighted text' control were provided.
Some thought would have to be given to copy/pasted styled text - perhaps provide a user option to use current style or retail original style.
In Mozilla Bugzilla #203810, Cursus-publicus (cursus-publicus) wrote : | #70 |
(In reply to Neville Hillyer from comment #63)
Sorry about the silly typo in my last message: please read 'retain' for 'retail' near end.
In Mozilla Bugzilla #203810, Mcow (mcow) wrote : | #71 |
Mike Cloaked, nothing in the problem you're discussing has anything to do with "font style in prepopulated text," which is the main stated condition of this bug in the title. Not to defend the HTML editor, but your report does belong elsewhere.
It should be immediately obvious that the text "xyz wrote..." in an HTML reply does not follow the composition preferences. That wasn't part of the initial bug report here, however, and it's my fault for poorly re-summarizing this bug in 2007. The lack of preferred formatting on the attribution line should be a separate bug (and maybe it already is).
In comment 7, I referred to bug 245581 comment 1, which describes the underlying problem for that bug and the primary symptom of this bug: text that I'm typing not following my font preferences.
The original steps in comment 0 do not reproduce in TB 16.0.2 (Win7/64). However, the reported symptom is still easy to observe. Here are the STR, from comment 0, with only the fourth step modified slightly:
1. Launch app - set to reply above quoted text (default for commercial builds)
2. Change your mailnews preference for composition to another font style.
3. Click Reply to a message someone sent preferably with the default font style.
4. Start typing (note you will see your default style), backspace all the way
to the left margin; press the Down arrow, followed by the Up arrow, and start typing again.
Actually, the initial typing followed by backspace is not required. What is required is moving the cursor away from its initial position with an empty user-typed text body -- which is only achievable if there is some prepopulated text.
In Mozilla Bugzilla #203810, Cursus-publicus (cursus-publicus) wrote : | #72 |
(In reply to Mike Cowperthwaite from comment #65)
Your STR with up/down arrow is totally different to the original report. I can probably replicate your STR with the latest SeaMonkey whereas I could not replicate the original STR with SeaMonkey. With what authority do you presume to alter the original STR? If the original STR cannot be replicated it might be best to close this bug report and start another one.
In Mozilla Bugzilla #203810, Mcow (mcow) wrote : | #73 |
(In reply to Neville Hillyer from comment #66)
> (In reply to Mike Cowperthwaite from comment #65)
> Your STR with up/down arrow is totally different to the original report.
I don't agree. The essential difference is that hitting backspace in an "empty" message body (no user typing from beginning of the message) no longer "moves" the cursor away from the insertion point, where it used to. The loss of user-preference formatting is predicated on that movement.
Try following the dupes and seeing what they have to say about. Some of those dupes might be mistaken -- and, as I said, the summary of this bug isn't really to the point.
> With what authority do you
> presume to alter the original STR? If the original STR cannot be replicated
> it might be best to close this bug report and start another one.
I was granted bug-editing privileges in 2003. I remember when Esther was active in Bugzilla. I put several boatloads of work into bug triage from 2003 to 2007.
You?
I don't mind at all if one or more new bugs are started to sort this one out. Given the state of this bug, that probably *would* be best.
In Mozilla Bugzilla #203810, Cursus-publicus (cursus-publicus) wrote : | #74 |
(In reply to Mike Cowperthwaite from comment #67)
I would like to see a new bug report started. Although I have followed this bug with interest I am not the best person to write it as I only switch on HTML to test this bug. I normally send text only. I do however have many years experience of hand crafting HTML for web pages so probably have an understanding of the underlying issues.
Unlike so many of these reports any new bug report should have an STR saying that HTML should be activated in account settings to make it clear that the issue only affects HTML emails and not text emails.
In Mozilla Bugzilla #203810, Mike-cloaked (mike-cloaked) wrote : | #75 |
I started what is perhaps a more relevant new report a few months ago at https:/
In Mozilla Bugzilla #203810, Killjay (killjay) wrote : | #76 |
The basic issue reported in comment #0 involves the attribution line being a different font face than the User configured body composition font.
"If the user backspaces in the first line all the way to the left, the newly typed text picks up the font style of this pre populated text." I quote this for two reasons. Esther is referring to the attribution line as "pre populated text". Then the back space action and resulting font change is a bug occurring because of a whitespace/
IIRC, it was TB12 had a sudden appearance of a bug that was being masked by the Editor whitespace bug. The essence of the bug was EOL was incorrectly handled as whitespace in some cases. With Editor patched, TB Devs patched their TB bug.
We still have font face changing issues with TB and there are current bugs open.
The different font face of the attribution is a bug itself and independent of this bug report.
Speaking as a TB bug triage team member, I think this bug should be closed since the bug in Editor that was fixed has altered the code-base so the original conditions are changed.
In Mozilla Bugzilla #203810, Cursus-publicus (cursus-publicus) wrote : | #77 |
(In reply to Ronald Killmer from comment #70)
I agree will all you say and would prefer it to be closed. It appears to wonder over a range of issues unrelated to the original STR.
In Mozilla Bugzilla #203810, Killjay (killjay) wrote : | #78 |
Added white-board note to close 1/1/2013
In Mozilla Bugzilla #203810, lengo (pcunger) wrote : | #79 |
(In reply to Ronald Killmer from comment #70)
>
> We still have font face changing issues with TB and there are current bugs
> open.
I'm fine with closing this bug if it is fixed. But it would be wonderful to be pointed to the relevant bug(s) that are open on 'font face changing' issues. I'd be pleased to add my vote to them.
In Mozilla Bugzilla #203810, 5u-mozilla (5u-mozilla) wrote : | #80 |
I too would very much like to be pointed to the relevant font changing bugs so that I could vote up their importance.
In Mozilla Bugzilla #203810, Fm-mozbugs (fm-mozbugs) wrote : | #81 |
(In reply to John Hupp from comment #74)
> I too would very much like to be pointed to the relevant font changing bugs
> so that I could vote up their importance.
INDEED...a list of all bugs having to do with font changing when it should not would definitely be helpful.
In Mozilla Bugzilla #203810, lengo (pcunger) wrote : | #82 |
I found #782215 "Font size change causes inconsistent size changes to occur" (https:/
In Mozilla Bugzilla #203810, lengo (pcunger) wrote : | #83 |
Arrrg! I meant to point to this one: #756984 "Changing location in editor doesn't preserve the font when returning to end of text/line" (https:/
In Mozilla Bugzilla #203810, Pppx (pppx) wrote : | #84 |
Resolved per whiteboard, Comment 70 and following comments
Changed in thunderbird: | |
status: | Confirmed → Invalid |
B Bobo (yout-bobo123) wrote : | #85 |
sorry, that was a mistake - can't stand launchpad's intolerable user-interface.
affects: | thunderbird → seamonkey |
affects: | seamonkey → thunderbird |
Changed in thunderbird: | |
importance: | Medium → Unknown |
status: | Invalid → Unknown |
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #98 |
This bug is still current at version 31.2.0 and 33 beta.
Given that it's been carried over from bug 250539 created in 2004, it might be a good idea to one day do something about it ;-)
Changed in thunderbird: | |
importance: | Unknown → High |
status: | Unknown → Confirmed |
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #99 |
Created attachment 8515199
Two videos showing the problem.
Here are two cases to reproduce the problem.
CASE 1:
=======
Step 1:
Set the following options:
Options: Display, Formatting, Default Font: Script
Options: Composition, HTMl, Font: Batang
Step 2:
Reply to an e-mail written in Arial. Start typing in Batang.
Click into the quoted text. Font changes to Arial.
Step 3:
Click after the text written in Batang. Font says Arial but we write in Script (default font).
Result:
After returning to the end of the line, the font is lost, the composition continues in the default font and the in the HTML the text is outside the <font></font> tags. The UI shows incorrect information.
Message saved/sent has this HTML:
<blockquote cite="mid:<email address hidden>" type="cite"><font
<font face="Batang">This is batang. </font>This is script<br>
See video 1 enclosed.
CASE 2:
=======
Step 1:
Set the following options:
Options: Display, Formatting, Default Font: Batang
Options: Composition, HTMl, Font: Batang
Step 2:
Reply to an e-mail written in Arial. Start typing in Batang.
Click into the quoted text. Font changes to Arial.
Step 3:
Click after the text written in Batang. Font says Arial but we write in Batang (default font).
Result:
After returning to the end of the line, the font is lost, the composition continues in the default font and the in the HTML the text is outside the <font></font> tags. The UI shows incorrect information.
Message saved/sent has this HTML:
<blockquote cite="mid:<email address hidden>" type="cite"><font
We have done little to address this trend.<
<font face="Batang">This is batang. </font>We continue to write in
batang, or so it seems.<br>
See video 2 enclosed.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #100 |
Created attachment 8515218
composition font also lost after insertion of image.
Composition font is also lost after inserting an image in a new message.
Watch the enclosed video. I am using these settings:
Options: Display, Formatting, Default Font: Arial.
Options: Composition, HTML, Font: Fixed width.
In Mozilla Bugzilla #756984, Charles (tanstaafl-libertytrek) wrote : | #101 |
Thanks Jorg...
I see now why I never encountered this bug. I can see how anyone who encounters it would find it frustrating, but...
I never do anything fancy with respect to fonts in my emails, and I always recommend to others that they should never do anything fancy in HTML emails. I tell them that if they want someone to get something fancy, send them a binary attachment (PDF is what I recommend).
Since Outlook (as much as I hate it, it is the mail client with the largest install base) switched to using Word for its HTML rendering engine (in spite of the immediate and ongoing massive complaints and uproar), which is one of the worst HTML rendering engines there is, it just doesn't make sense to waste a lot of time making something look fancy when there is every probability that the vast majority of anyone you may send it to will NOT see it the way you intended.
All I ever do is sometimes use lists, change styles, etc, but only minor tweaks...
And I never edit quoted text either (that just seems wrong to me)...
Anyway, hopefully this one will now get squashed sooner rather than later now that iti is easily reproducible...
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #102 |
(In reply to Jorg K from comment #12)
> This bug is still current at version 31.2.0 and 33 beta.
>
> Given that it's been carried over from bug 250539 created in 2004, it might
> be a good idea to one day do something about it ;-)
Unfortunately, we have no one actively working on the editor component, so basically all editor bugs on indefinitely on hold. Occasionally one or two gets fixed here or there, but as things stand, I wouldn't count on it.
In Mozilla Bugzilla #756984, Charles (tanstaafl-libertytrek) wrote : | #103 |
???
I thought the contrary was actually the case?
Unless I am sorely mistaken, or confusing components, the composer (editor) component just received some major changes, and regressions are actively being worked on.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #104 |
(In reply to :Aryeh Gregor from comment #16)
> Unfortunately, we have no one actively working on the editor component, so
> basically all editor bugs on indefinitely on hold. Occasionally one or two
> gets fixed here or there, but as things stand, I wouldn't count on it.
OK, when you say "editor" you mean "composer". The component that allows the user to more or less WYSIWYG enter text (with fonts, colour, etc.) and pictures and creates HTML which is sent out.
Charles beat me to it, but I thought this is being worked on, quoting:
https:/
===
The Addressing bugs are due to some significant movement on getting the
Composer rewrite going. This is a very *good* thing.
It is painful when bugs like this show up, yes, but the composer has
been needing the rewrite for 10+ years, so I for one am glad it is
happening.
===
I've certainly experienced a few of the regressions (bug 1042561 and bug 1043310).
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #105 |
(In reply to Jorg K from comment #18)
> OK, when you say "editor" you mean "composer". The component that allows the
> user to more or less WYSIWYG enter text (with fonts, colour, etc.) and
> pictures and creates HTML which is sent out.
I mean the code under editor/ in the Gecko source tree, which handles the backend of editors for both Firefox and Thunderbird. Thunderbird's composer uses the Gecko editor for composing mail, but also has its own code that it puts on top, so the post you link to may be referring to that. This bug is in the editor itself, not the Thunderbird-
That said, I actually haven't been paying much attention, and for all I know it could be someone has started working on editor again recently and I didn't notice. It doesn't seem so based on glancing at the log, but I didn't look at the commits in detail. If people are working on Thunderbird more, maybe they'll want to fix stuff in the editor too, since some high-profile Thunderbird bugs are really editor bugs. So we can still hope! :)
In Mozilla Bugzilla #756984, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #106 |
There's nobody actively working on it atm. The quote likely refers to the jsmime work, which has very little to do with the editor.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #107 |
From Bug 250539
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!, PTO 11/3-11/21) from comment #196)
2010-08-25 07:18:58 PDT
> It appears to me that this is an editor bug. If someone can create a test
> case as an HTML file and file a bug in Core::Editor, I may try to sneak a
> fix in for Gecko 2.0.
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!, PTO 11/3-11/21) from comment #232)
2011-09-22 19:46:20 PDT
> Everyone, please relax. I'm working hard to work out a solution to this
> bug.
What happened to that? The test case is here.
Is this a super-hard problem? To me at seems that it's just a simple special case: If cursor is moved to the very end of the text, pick up the font that was previously used.
In Mozilla Bugzilla #756984, Ehsan Akhgari (ehsan) wrote : | #108 |
As Aryeh said, there's nobody who is currently working on the editor code base, unfortunately. This is not a very hard problem, it is mostly an issue of having the human resources to work on this component. But it is also not as easy as you suggest, because we don't remember the history of all of the fonts/etcs used during editing.
If someone wants to fix this, I think they should first look into where in the DOM we collapse the selection when you click at the end of the paragraph. 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, and figure out the edge cases that we need to think about and also test the behavior of other browser engines in those cases, etc.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #109 |
In nsEditor:
if (mComposition) {
...
} else {
if (node->
...
} else {
// we are inserting text into a non-text node. first we have to create a
// textnode (this also populates it with the text)
node-
...
Debugging shows that when the font is lost - after clicking elsewhere and then clicking again at the end of the line - "we are inserting text into a non-text node". Dumping out the 'node' at this point gives:
body@1197C400 text="#000000" bgcolor="#FFFFFF" _moz_dirty="" state=[40000020004] flags=[00104008] ranges:1 primaryframe=
tt@0DAA42E0 _moz_dirty="" state=[40000020000] flags=[00100000] primaryframe=
Text@0C58D650 flags=[02000008] primaryframe=
>
br@0DCF3D00 _moz_dirty="" state=[40000020000] flags=[00100000] primaryframe=
br@0DCF3DC0 _moz_dirty="" state=[40000020000] flags=[00100000] primaryframe=
div@0DCF3E80 _moz_dirty="" class="
Text@0DCFFD80 flags=[03000008] primaryframe=
br@0DCF3EE0 _moz_dirty="" state=[40000020000] flags=[00100000] primaryframe=
>
(Note: In my test I was answering a Bugzilla e-mail and my composition style was "tt". I had typed the word "one" before clicking elsewhere and then clicking again after "one". On the next keystroke the above dump was produced.)
This confirms what Ehsan said in comment #22: The key to this problem is what happens when clicking at the end of the line to continue typing. By the looks of it, the click does not identify the correct element where the user would like to continue typing. Instead a new node is created which is lacking the font information.
I could use some help to locate the code that translates the click into identifying the element. Somewhere in ns(HTML)
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #110 |
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?
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>? Why can't this method be used for any subsequently created text elements? Currently further text elements are created with the "default" font, which is also configured in Thunderbird and must be communicated somehow to the editor.
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.
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?
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #111 |
(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)
> suppose.
nsFrame:
(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.
> 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.
> 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.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #112 |
Thank you for your detailed answer which clarifies a lot of things. I will investigate the interaction between Thunderbird and the editor further.
Re. your last comment:
> I _think_ to fix that part you need to get Thunderbird tell Gecko about how
> to format the new paragraph.
I tried with a <div contenteditable> in Firefox. The editor handles insertion of images by itself. So the question is: How could Thunderbird, the invoker of the editor, be notified, so it could in turn do whatever it does normally (I need to investigate what that is exactly) to communicate that the format required after the insertion? Can an callback be installed that the editor calls when new nodes are created in the DOM tree?
So far I get the following picture of the interaction between Thunderbird and the editor:
1) Thunderbird invokes the editor and communicates the initial conditions, font, size, etc.
2) The editor does all the editing. When new nodes are created in the DOM, no "special" style element is used, so to the Thunderbird user it looks like the style gets lost.
3) No callback to Thunderbird takes place while the editor is running.
4) Thunderbird may send "commands" to the editor, to change the font, bold, etc.
5) When the editing is done, Thunderbird receives a copy of the DOM (or the plain text or HTML) and stores it or sends it.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #113 |
I have to correct point 3) a little. In an e-mail with different fonts, colours, bold, italics, clicking in the editor does communicate something back to Thunderbird so it can update it's controls; or maybe the editor just sets some "global" variables, that can be queried in the UI.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #114 |
Sorry to trouble you again. I have some more questions to understand how the architecture hangs together. Let me summarise the questions from the previous posts here:
Where is the mouse click translated into identifying a node of the DOM tree?
Your answer was nsFrame:
How does Thunderbird communicate "composition font" or "default font" to the editor?
Your answer was that you didn't know. Fair enough. You suggested the document.
When the user writes an e-mail and clicks into a text, the UI controls are updated, that is the indicators for font, bold, italics, etc. reflect the properties of the text where the user clicked.
How is this done? How does the editor notify the UI, after identifying the node clicked and the finding the properties of the node. This is also important to know, because in cases where the font gets lost, the UI is not updated correctly.
And last question just repeated from comment #26. You said in comment #25:
> I _think_ to fix that part you need to get Thunderbird tell Gecko about how
> to format the new paragraph.
I tried with a <div contenteditable> in Firefox. The editor handles insertion of images by itself. So the question is: How could Thunderbird, the invoker of the editor, be notified, so it could in turn do whatever it does normally (I need to investigate what that is exactly) to communicate that the format required after the insertion? Can an callback be installed that the editor calls when new nodes are created in the DOM tree?
Note: I've just noticed that when an image, math, table, link, etc. is inserted from the "Insert" menu, the composition style is NOT lost. It is only lost when an image is *pasted* in. That's an interesting observation, leading to the question how the system manages to maintain the font in these cases, whereas on paste the font gets lost.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #115 |
(In reply to Jorg K from comment #26)
> Re. your last comment:
> > I _think_ to fix that part you need to get Thunderbird tell Gecko about how
> > to format the new paragraph.
>
> I tried with a <div contenteditable> in Firefox. The editor handles
> insertion of images by itself. So the question is: How could Thunderbird,
> the invoker of the editor, be notified, so it could in turn do whatever it
> does normally (I need to investigate what that is exactly) to communicate
> that the format required after the insertion?
If it works with a simple contenteditable element in Firefox, then Thunderbird is doing something that it should not be doing. I have no idea what that might be though. But at any rate, that is off topic for this bug.
> Can an callback be installed
> that the editor calls when new nodes are created in the DOM tree?
You can use a mutation observer to be notified when new nodes are injected into the tree, but like I said, that doesn't help if Thunderbird is doing something that it should not be doing.
> So far I get the following picture of the interaction between Thunderbird
> and the editor:
> 1) Thunderbird invokes the editor and communicates the initial conditions,
> font, size, etc.
> 2) The editor does all the editing. When new nodes are created in the DOM,
> no "special" style element is used, so to the Thunderbird user it looks like
> the style gets lost.
> 3) No callback to Thunderbird takes place while the editor is running.
> 4) Thunderbird may send "commands" to the editor, to change the font, bold,
> etc.
> 5) When the editing is done, Thunderbird receives a copy of the DOM (or the
> plain text or HTML) and stores it or sends it.
I'm not familiar enough with the Thunderbird side of things to be able to tell how it interacts with Gecko. And I don't know anyone who does. Your best bet may be reading the code.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #116 |
(In reply to Jorg K from comment #28)
> Sorry to trouble you again. I have some more questions to understand how the
> architecture hangs together. Let me summarise the questions from the
> previous posts here:
>
> Where is the mouse click translated into identifying a node of the DOM tree?
> Your answer was nsFrame:
> but didn't see anything connected to the editor.
Yes, that part has nothing to do with the editor. In general, the editor is usually oblivious to selection changes, caret movement and such.
> nsFrame:
> handles clicks anywhere on the mail composition window. I would like to find
> the spot where the editor looks through the DOM tree to identify the node. I
> looked in nsHTMLEditorEve
> last branch controlled by "else if (!isContextClick && buttonNumber == 0 &&
> clickCount == 1)" is executed. I would imagine to find a traversal of the
> DOM tree to find the correct node.
I'm not exactly sure why you're looking at the editor code. Nothing in comment 22 will probably need to be fixed in the editor code.
> How does Thunderbird communicate "composition font" or "default font" to the
> editor?
> Your answer was that you didn't know. Fair enough. You suggested the
> document.
> nsHTMLDocument:
> Equally, then the UI controls for bold, italics, font, etc. are operated,
> the breakpoint wasn't reached. I'd like to know how this is passed to the
> editor. So I will ask in the Thunderbird group.
I'd be curious to know, FWIW!
> When the user writes an e-mail and clicks into a text, the UI controls are
> updated, that is the indicators for font, bold, italics, etc. reflect the
> properties of the text where the user clicked.
> How is this done? How does the editor notify the UI, after identifying the
> node clicked and the finding the properties of the node. This is also
> important to know, because in cases where the font gets lost, the UI is not
> updated correctly.
Again, I know nothing about what Thunderbird does, but a normal web application which does this would probably use document.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #117 |
Thank you for your continued patience.
It is true that this bug is is about losing the font when clicking at the end of the line after clicking somewhere else. However, I'd like to consider other occasions where the font is lost, that is after inserting an image by paste.
Let's deal with this "off-topic" issue first: In Firefox, using <div contenteditable> you can paste in an image and then keep typing in the font that was used before the insertion. So as you concluded, TB must be doing something strange here.
As for the clicking at the end of the line: In Firefox, again with a <div contenteditable> I created two texts with different fonts, clicking in one, typing in one font, then clicking in the other one, then clicking at the end of the first one again does NOT lose the font.
So maybe this is not a Core/Editor bug, maybe it's solely a Thunderbird bug.
To answer your question why I was looking in the editor for the click processing: pure ignorance. Of course you can click onto a static document where no editor is involved and the click will be processed.
I will follow up on the other issues with the Thunderbird group
https:/
and keep you posted.
In Mozilla Bugzilla #756984, Hamiglorr (hamiglorr) wrote : | #118 |
Jorg K and Ehsan Akhgari, thank you so much for working on this pesky problem! I'm sure that a lot of other Thunderbird users are grateful too. This nuisance has been plaguing us for a very long time, and it would be *wonderful* to have it fixed!
Thanks again.
Gloria
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #119 |
@Ehsan from comment #30 ("I'd be curious to know, FWIW!"):
Turns out that the Thunderbird e-mail front end is one big JS/XUL application:
http://
I haven't looked very much, but I can answer some questions. For example the "Bold button" is defined here:
http://
There is an observer, so when the bold state changes, it gets noticed and the UI is updated.
I will now hunt through this code to see whether I can find the cause of the lost font.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #120 |
Without a working font indicator it is impossible to tell what's going on. So fixing bug 1139524 first.
Further testing over in the other bug showed that by clicking at the end of the line sometimes the font in the next line is activated rather then the one of the line being clicked.
In Mozilla Bugzilla #756984, Charles (tanstaafl-libertytrek) wrote : | #121 |
Just wanted to add another 'THANK YOU!!! to Jorg K for working on these editor bugs.
Too often these older bugs are filled with negative comments.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #122 |
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.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #123 |
Simple test using Midas: http://
1) type two lines, like shown:
one
two
They are shown in Times.
2) select first line and make it arial, select second and make it courier
3) Click after the word "one" in the first line and type. Typing happens in Times. Wrong font.
You must reload the page before trying again.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #124 |
Coming back to the suggestion from comment #25 and looking in nsFrame:
I traced it down into ns[Text]
nsFrame:
nsTextFrame:
nsFrameSelectio
nsFrameSelectio
nsFrameSelectio
nsFrame:
It varies whether nsFrame:
When the nsTextFrame:
Try it with a wide letter, like "m"!
So in case a "Frame" being hit instead of a "TextFrame", perhaps the program should look whether there is a text right before the caret once placed.
Here some debug showing the two cases:
=== before BidiLevelFromClick
=== in nsTextFrame:
nsTextFrame:
=== after BidiLevelFromClick
=== before BidiLevelFromClick
=== in nsFrame:
=== after BidiLevelFromClick
Any further hints? Five minutes of your time can possibly save me five hours or five days of "reverse engineering".
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #125 |
c/left/right/g ;-)
It varies whether nsFrame:
In Mozilla Bugzilla #756984, Fm-mozbugs (fm-mozbugs) wrote : | #126 |
From these posts, it sure looks like people are working on this, but the metadat at the top of the bug page says, "Assigned To: Nobody; OK to take it and work on it "
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #127 |
I'm working on it, but I can mostly do the debugging. Now I need some help to actually fix the problem. If I can get that help, I can assign it to myself. Otherwise, it might wait another 10 years ;-((
Note: The predecessor bug 250539 is from 2004.
In Mozilla Bugzilla #756984, Fm-mozbugs (fm-mozbugs) wrote : | #128 |
And jorg k, we REALLY REALLY REALLY REALLY appreciate it too!!
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #129 |
The problem with losing the style after inserting an image (see comment #14) has been moved to bug 1140617.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #130 |
Oops, after a refresh of my source, behaviour of nsFrame:
http://
Behaviour hasn't changed though. Click "far" left, font changes, click left/on, font is correct.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #131 |
Maybe better to look further up in call stack, for example PresShell:
In Mozilla Bugzilla #756984, Hamiglorr (hamiglorr) wrote : | #132 |
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 size stays the same at the correction, but when I go to the end of the line to continue my typing, the font size is smaller, not larger.
In Mozilla Bugzilla #756984, Fm-mozbugs (fm-mozbugs) wrote : | #133 |
>When I'm typing and correct something, the font size stays the same at the correction, but when I go to the end of the line to continue my typing, the font size is smaller, not larger."
That's because there is a hidden </ font> tag at the end of the line (but before the spot where you are typing). When you move away from the line to do the correction, then click back to the right of the line in white space, the cursor has now been placed OUTSIDE the end font tag, so you have thus "lost" what font had previously been specified.
In Mozilla Bugzilla #756984, Fm-mozbugs (fm-mozbugs) wrote : | #134 |
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).
In Mozilla Bugzilla #756984, Hamiglorr (hamiglorr) wrote : | #135 |
maybe-the-one - re comments 47 & 48: thanks for the clarifying explanation.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #136 |
(In reply to Jorg K from comment #38)
> Coming back to the suggestion from comment #25 and looking in
> nsFrame:
>
> I traced it down into ns[Text]
> call stack of:
>
> nsFrame:
> nsTextFrame:
> nsFrameSelectio
> nsFrameSelectio
> nsFrameSelectio
> nsFrame:
>
> It varies whether nsFrame:
> nsTextFrame:
> whether you click on the text, but almost to the left of the text, or
> completely to the left of the text.
>
> When the nsTextFrame:
> offset is calculated correctly and the font is right. When the
> nsFrame:
> latter case the caret still appears behind the text.
Yes, this is what I was explaining in comment 22. The frame on which this function is called depends on the frame receiving the click event; if you click on the text it's going to be a textframe, otherwise it's going to be the parent frame (in the normal case as in the test case you describe above) or anything else that is under the mouse cursor.
> Try it with a wide letter, like "m"!
>
> So in case a "Frame" being hit instead of a "TextFrame", perhaps the program
> should look whether there is a text right before the caret once placed.
No, we shouldn't change the way that we hit-test to find out which frame was clicked.
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.
But before we can do that, we need to investigate the behavior of other engines in this situation (as in, we should see where they put the selection.) You need to create a test case which lets you click somewhere and have it dump out the place of the selection (which you can get through window.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #137 |
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.
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.
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 ;-)
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #138 |
Created attachment 8574843
Stripped down Midas demo, also alerts on clicks and dumps out info
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #139 |
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.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #140 |
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.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #141 |
(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.
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 GetContentOffse
For example in attachment 8575104 if you click to the right of the first line, we get to GetSelectionClo
Beware that this will probably be a lengthy process and ...
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #142 |
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): start=#text(10) - end=#text(10)
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #143 |
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. :/
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.
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.
In Mozilla Bugzilla #756984, Fm-mozbugs (fm-mozbugs) wrote : | #144 |
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 place the cursor just before it?
"For me, this is the single most annoying bug in Thunderbird which after 10 years should finally be resolved." AMEN, and thank you so much for working on it.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #145 |
(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.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #146 |
Created attachment 8576320
A more comprehensive text
The more conservative approach would be not to change the selection behaviour but to maintain/
One could argue that clicking 10cm or 4" away from the text to the right should not select the text. On the other hand, if no <br> follows, then you can click far to the right and the text is still selected. Also for text in <p></p> you can click far to the right and still select the text. Note that links are not followed, even though the text is selected. That's the last example.
Personally I would fire any web designer who creates websites for one browser alone and who creates special code for somewhat far-fetched cases of clicking a text.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #147 |
It's not going past static FrameTarget GetSelectionClo
http://
... nor static FrameTarget GetSelectionClo
Also, very little processing in nsFrame:
http://
These functions fire when you hover over or click into the URL field (or the search box), but NOT the rendered HTML.
I'm not afraid of a large C++ code base, but I need a place to start. As I said, five minutes of your time can possibly save me five hours or five days of "reverse engineering".
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #148 |
I've done a little debugging.
On every mouse move event we get this:
>>> Entering PresShell:
PresShell:
PresShell:
PresShell:
=== about to call HandlePositione
=== in PresShell:
<<< Leaving PresShell:
(BTW, none of the frame numbers change when you move the cursor around. Unless you reload the page, they are always the same numbers).
Surely somewhere in there it works out what is under the cursor, since when the cursor is over a link, things happen (cursor changes, link target is displayed). Sadly, I haven't yet found that code.
If the button is clicked and released, we additionally get calls to HandlePress and HandleRelease
>>> Entering PresShell:
PresShell:
PresShell:
PresShell:
=== about to call HandlePositione
=== in PresShell:
=== in nsFrame:
<<< Leaving PresShell:
>>> Entering PresShell:
PresShell:
PresShell:
PresShell:
=== about to call HandlePositione
=== in PresShell:
=== in nsFrame:
<<< Leaving PresShell:
Here is the stack from the HandlePress call:
nsFrame:
nsFrame:
nsPresShellEven
mozilla:
mozilla:
PresShell:
PresShell:
PresShell:
PresShell:
As I said before, GetSelectionClo
printf ("=== in GetSelectionClo
printf ("=== in GetSelectionClo
printf ("=== in GetSelectionClo
printf ("=== in nsIFrame:
So the idea of discarding the BRFrame in GetSelectionClo
Further suggestions appreciated. I'd really like to find the code that identifies the element under the cursor. Also, is there a way to dump out/print these data structures? How do you "print" an nsIFrame or an nsBlockFr...
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #149 |
Any idea why TypeInState:
http://
Is that not a listener to listen to the selection changing? Maybe that has something to do with our problem(s) (thinking also of bug 1140617).
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #150 |
(In reply to Jorg K from comment #60)
> The more conservative approach would be not to change the selection
> behaviour but to maintain/
> click. That is what IE does: The DIV is selected, but typing continues in
> the "correct" font, see comment #54. Would you prefer this approach?
No. TypeInState can only remember the properties set while the selection has not changed, so it is never the right fix for bugs that occur when you move the selection around in the document.
> One could argue that clicking 10cm or 4" away from the text to the right
> should not select the text. On the other hand, if no <br> follows, then you
> can click far to the right and the text is still selected. Also for text in
> <p></p> you can click far to the right and still select the text. Note that
> links are not followed, even though the text is selected. That's the last
> example.
Sorry, I'm not really sure what you mean here.
> Personally I would fire any web designer who creates websites for one
> browser alone and who creates special code for somewhat far-fetched cases of
> clicking a text.
Or here. :-)
(In reply to Jorg K from comment #61)
> It's not going past static FrameTarget GetSelectionClo
> http://
> ... nor static FrameTarget GetSelectionClo
> FrameTarget GetSelectionClo
>
> Also, very little processing in nsFrame:
> leaving there at line 2819:
> http://
Hmm, I wasn't guessing in comment 55, I actually ran this under the debugger, so I'm pretty sure you're doing something wrong. Not sure what exactly...
> These functions fire when you hover over or click into the URL field (or the
> search box), but NOT the rendered HTML.
Hmm, maybe that's because you're attached to the wrong process? Does the active tab have an underline on its title? If yes, you're in e10s mode where we run the rendered content in a separate process. If this is what's happening, try either attaching the debugger to the content process, or open a new non-e10s window and load the test case there.
> I'm not afraid of a large C++ code base, but I need a place to start. As I
> said, five minutes of your time can possibly save me five hours or five days
> of "reverse engineering".
I'm trying to help, comment 55 should give you everything you need to get started.
(In reply to Jorg K from comment #62)
> As I said before, GetSelectionClo
> following statements I placed into the corresponding functions in
> nsFrame.cpp are not reached:
> printf ("=== in GetSelectionClo
> printf ("=== in GetSelectionClo
> printf ("=== in GetSelectionClo
> printf ("=== in nsIFrame:
This cannot possibly be true, I guarantee that. It's either you being attached to the wrong process or something else...
> Further suggestions appreciated. I'd really like to find the code that
> identifies the element ...
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #151 |
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 don't want to infuriate you ;-)
The problem in this bug and in the other bug 1140617 is, that a line is continued with a new element.
In this bug, someone clicks on a "DIV", since they click to the right of the text. The new text is inserted into a new element and loses the font. In the other bug, an image is inserted. After that the new text is inserted into a new element and loses the font. In both cases we could look in the inline frame and see whether there is a text element immediately before, whose attributes should be used.
Is this an option? If we did that, we would *not* have to change the selection behaviour and wear all the possible consequences. Changing the selection will fix this bug but not the other bug 1140617.
If this is not a viable solution, I can look further into changing the selection behaviour. My debugging works now:
Debug when clicking on the text:
>>> Entering nsFrame:
=== in nsIFrame:
=== in GetSelectionClo
=== in nsFrame:
>>> Entering nsFrameSelectio
=== before BidiLevelFromClick
>>> Endering nsTextFrame:
=== nsTextFrame:
<<< Leaving nsTextFrame:
=== after BidiLevelFromClick
*** TypeInState:
<<< Leaving nsFrameSelectio
<<< Leaving nsFrame:
When clicking to the right of the text:
>>> Entering nsFrame:
=== in nsIFrame:
=== in GetSelectionClo
=== in nsFrame:
=== in nsFrame:
=== in GetSelectionClo
=== in nsFrame:
>>> Entering nsFrameSelectio
=== before BidiLevelFromClick
=== after BidiLevelFromClick
*** TypeInState:
<<< Leaving nsFrameSelectio
<<< Leaving nsFrame:
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #152 |
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 places where it would cause bugs like this, such as on a BR node when you click at the end of the line.
If this approach proves to be impossible because of Web compatibility we can always re-evaluate.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #153 |
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 ranges can become empty during editing.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #154 |
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 treeherder URL so that we can look at the test failures.
Thanks!
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #155 |
Sorry, you need to help me out here. Never done it before.
I will get the access rights as discussed on IRC.
In Mozilla Bugzilla #756984, Archaeopteryx (archaeopteryx) wrote : | #156 |
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #157 |
(In reply to Archaeopteryx [:aryx] from comment #70)
> Pushed to Try:
> https:/
Canceled this as it misses the most important part of the tests, mochitests. Repushed:
https:/
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #158 |
When you have a minute, could you please look at the results or instruct me, how to interpret them.
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #159 |
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:/
Thanks a ton for working on this! If you want feedback from me on if your test looks good before asking for review, please feel free to ask me via the "feedback" flag when uploading your patch. I'm probably less busy than the reviewers. :)
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #160 |
@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 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*.
Also, we need to keep the sister bug 1140617 in mind. In bug 1140617 comment #8 Ehsan said:
> We still don't have a complete fix for bug 756984. The stuff that you're working on is
> just the tip of the *iceberg*. Can you please just *trust me* on this and wait for bug
> 756984 to be finished before worrying about this? Thanks!
To me, it's just a three line change, and if you want, with a test case. Obviously none of the other tests checks the selection after the click, so I can certainly add such a test following your suggestions.
However, before I start, I want to make 100% sure that we're all on the same page. I have the impression that Ehsan has something grander in mind.
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #161 |
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.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #162 |
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 other means of moving to the end of a line. For example, one such scenario that you need to investigate is if the caret is in the middle of the line, and you press End or Ctrl/Cmd+E. Another example is when you have multiple lines, and you place the caret at the end of a longer line and use up/down to navigate to the end of a shorter line. Same thing with using PageUp/PageDown in the same situation but with more lines of text obviously. Some of these code paths can end up going through the same code and some may already do the right thing but you need to test each one of them to make sure. The main entry point for all of these is nsFrameSelectio
Another thing that would be useful to test (but I'm pretty sure that it would work correctly based on the code changes) is what happens in both of these cases when you have several inline elements nested underneath each other, such as:
<span><
You should ensure that the selection is again put at the end of the text frame in this case, so that when the user starts to type again, the new text would have the correct styles imposed by all of those inline elements.
Once you've verified and fixed all of these cases, the next step would be to write a unit test as Aryeh mentioned that examines this behavior and ensures that we don't end up regressing it in the future. In addition to simulating a mouse click, you'd need to use synthesizeKey, for example, synthesizeKey(
And thanks again for working on this!
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #163 |
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 far to change script-specified selections, but the right way to do this is probably to have some sort of helper method in Selection like NormalizePoint(
Do we want to allow a selection like <b>foo<
I don't think any of this has to be in the scope of the current bug, though.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #164 |
(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 available, etc. I think it's taking things too
> far to change script-specified selections
Yeah, I think that's a bit too aggressive, and probably would cause authors to have to do insane hacks if they actually want to put the selection where the engine doesn't think is appropriate.
> but the right way to do this is
> probably to have some sort of helper method in Selection like
> NormalizePoint(
> selection change. We might want to disallow other types of user-created
> selections from occurring in the future, although my brain is too rusty to
> supply any.
Well, most of the code handling selection changes actually lives outside Selection. ;-) Depending on where we need to modify the behavior, having this kind of helper may or may not help... See Jorg's patch for example, I think the way he modifies the existing logic is cleaner than going with the current logic and then fixing it up elsewhere.
> Do we want to allow a selection like <b>foo<
> selection collapsed in between the <b> and <i>? IIRC, WebKit in my testing
> forced this to be <b>foo[
> text node). A ten-second test in WordPad suggests this is the right thing
> to do.
Yes, that makes sense to me. Follow-up bug perhaps?
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #165 |
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. :-)
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #166 |
Thanks for the suggestions made in comment #78. I'm testing with
<span><b><i><font face=Courier new">foo bar on the same line</font>
<span><b><i><font face="Arial">foo bar on the same line</font>
<strong>foo bar on the same line</strong><br>
This is <s>strikethroug
25 m<sup>2</sup><br>
H<sub>2<
and some <u>underline<
foobar
Moving around with the cursor already works with the current version of FF, including moving from a long line to a short one and getting to the end this way.
Pressing the "End" button is sadly NOT fixed by the patch. Clicking at the start of a line and then pressing "left arrow" to get to the end of the previous line is also NOT fixed by the patch.
So the next step is to fix the two mentioned cases: End button and "left arrow" at the start of the line. BTW, these two cases do work in Chrome and IE already.
I'd like to make sure that all positioning actions end up with the same correct result, clicking is only one of them.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #167 |
Cool, so yeah, a fix to those two additional cases + the unit tests is probably all that we'd need here!
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #168 |
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.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #169 |
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:/
http://
I don't know which tests we need to run here and on which platforms.
I'm also struggling with Mercurial. This
https:/
apparently is out of date. I got to the "hg qnew", the patch is enclosed. I tried "hg commit" but got "abort: cannot commit over an applied mq patch". Hmm.
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #170 |
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 "[x64]", but I don't think you need to do that here.
For Mercurial -- if you're using mq (which you should), you don't ever want to do "hg commit". The patch you've attached is exactly right.
Here are the try results for you: https:/
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #171 |
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 editor/
./mach mochitest-plain editor/
If you're on Linux, you should be able to install the appropriate package for the xvfb-run command and use this instead so it runs without creating a window you have to keep in focus:
xvfb-run ./mach mochitest-plain editor/
The other failure I see is layout/
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #172 |
The failure in editor/
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #173 |
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: <div>block 1<br><span>new line here</span>
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #174 |
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/
@@ +3555,3 @@
> for (int32_t n = aLine->
> --n, frame = frame->
> + // Bug 756984: Skip brFrames. Can only skip if the line contains at least one selectable and non-empty frame before
Nit: you don't need to mention bug numbers in comments. This information is available through hg/git blame.
@@ +3555,4 @@
> for (int32_t n = aLine->
> --n, frame = frame->
> + // Bug 756984: Skip brFrames. Can only skip if the line contains at least one selectable and non-empty frame before
> + if (!SelfIsSelecta
Nit: please wrap lines at 80 characters. For example, according to our coding style, this condition should be written as:
if (!SelfIsSelecta
(canSkipBr && frame->GetType() == nsGkAtoms:
@@ +6801,5 @@
> for (int32_t count = lineFrameCount; count;
> --count, frame = frame->
> if (!frame-
> + // Bug 756984: When jumping to the end of the line with the "end" key, skip over brFrames
> + if (endOfLine && lineFrameCount > 1 && frame->GetType() == nsGkAtoms::brFrame) continue;
Nit: again, please adjust the whitespace here. Also, please wrap if bodies in braces.
@@ +7090,5 @@
> + nsIFrame *currentBlockFrame, *currentFirstFrame;
> + nsRect usedRect;
> + int32_t currentLine = nsFrame:
> + nsAutoLineIterator it = currentBlockFra
> + it->GetLine(
There is already code which gets the line frame count earlier in this function. Please refactor it out of the else block it currently lives in and just use lineFrameCount from that code here. That already takes care of checking the return value of GetLine for errors too. Also, I think you want to check atLineEdge instead of aJumpLines here.
In Mozilla Bugzilla #756984, Charles (tanstaafl-libertytrek) wrote : | #175 |
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, but it seems that there is much more movement on lots of older bugs (and new ones) lately, and it is extremely gratifying to see people stepping up.
I just wish I had some coding skills (and time to use them)...
So - thanks to all!!!
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #176 |
(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 policy must have changed recently.
> Also, please wrap if bodies in braces.
Again, the policy seems to have changed here since there are many conditions of this style:
if (!range.content)
return NS_ERROR_FAILURE;
> There is already code which gets the line frame count earlier in this
> function. Please refactor it out of the else block it currently lives in
> and just use lineFrameCount from that code here. That already takes care of
> checking the return value of GetLine for errors too. Also, I think you want
> to check atLineEdge instead of aJumpLines here.
I disagree. I did what you suggest, but it didn't work. The
it->GetLine(
ealier on gets the details for the previous line where the left arrow was pressed.
We then move on to the line before. The next
it->GetLine(
is operating on the line we've just moved to, the one where we want to skip the brFrame.
The only thing which would be a bit cleaner is not to re-use the "it" variable but to declare another one.
I agree, I do need "atLineEdge".
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #177 |
(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 you entered for
> bug 596506), so this policy must have changed recently.
Well you're repeating it multiple times in the same file. The bug number is really not adding any useful information in this case.
> > Also, please wrap if bodies in braces.
> Again, the policy seems to have changed here since there are many conditions
> of this style:
> if (!range.content)
> return NS_ERROR_FAILURE;
We unfortunately don't consistently adhere to the coding style, but we should for new code that we're adding.
> > There is already code which gets the line frame count earlier in this
> > function. Please refactor it out of the else block it currently lives in
> > and just use lineFrameCount from that code here. That already takes care of
> > checking the return value of GetLine for errors too. Also, I think you want
> > to check atLineEdge instead of aJumpLines here.
> I disagree. I did what you suggest, but it didn't work. The
> it->GetLine(
> ealier on gets the details for the previous line where the left arrow was
> pressed.
> We then move on to the line before. The next
> it->GetLine(
> is operating on the line we've just moved to, the one where we want to skip
> the brFrame.
> The only thing which would be a bit cleaner is not to re-use the "it"
> variable but to declare another one.
Oh yeah, good point. So please make sure you check the return value of GetLine like above.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #178 |
(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 ssh://<email address hidden>
It returned: "No changes found" or words to that extent. I haven't tried after the "hg qnew".
So what is the exact sequence of commands? BTW, I'm on Windows 7. 30 seconds of your time save me three hours of (very frustrating) research (since I want to focus on the problem and not the infrastructure).
As for the test results: Mochitests 4, 5 and oth failed. I just had a very brief look:
oth says:
editor/
YES! Indeed, we want the text. I will need to change the test.
5 says:
layout/
Same thing, we want the text.
4 says:
TEST-UNEXPECTED
965721 Intermittent test_bug409604.
969526 Intermittent test_richtext.
1129538 Intermittent test_draggablep
1142900 Intermittent test_richtext2.html | application timed out after 330 seconds with no output
Any comments on these crashes and time-outs?
P.S.: Would you be able to let me know your time-zone so I know when not to expect feedback ;-)
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #179 |
(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: <div>block 1<br><span>new line
> here</span>
This works already.
My patch only tries to skip brFrames. In this example there is no brFrame at the end of "new line here".
In Mozilla Bugzilla #756984, Mkmelin+mozilla (mkmelin+mozilla) wrote : | #180 |
In .hg/hgrc (or ~/.hgrc) set up the path alias:
mc-try = ssh://<email address hidden>
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.
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #181 |
(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://<email address hidden>
> across the "hg qnew" command.
> It returned: "No changes found" or words to that extent. I haven't tried
> after the "hg qnew".
> So what is the exact sequence of commands? BTW, I'm on Windows 7. 30 seconds
> of your time save me three hours of (very frustrating) research (since I
> want to focus on the problem and not the infrastructure).
If you have some changes you want to commit, and no patches currently applied:
hg qnew mypatchname # This saves your changes to an mq patch
hg qnew -m "try: -b do -p all -u all[x64] -t none" try # Make a second patch with the try line
hg push -f mc-try # Make sure you have Magnus' line in .hg/hgrc
hg qdelete try # Delete the empty try patch
Note: this will leave you with a patch in mq called "mypatchname" with your changes. If you make any new changes to the patch and want to submit to try again, do the same, except instead of the first line, do "hg qref" to refresh the existing patch instead of making a new one. To view your existing patches, try "hg qser -s"; to move around, you can use "hg qpop" and "hg qpush" and "hg qgoto"; for more help, try "hg help mq" or "hg help commandname".
If you see any weird changes that only appear on some platforms and don't look related to your changes, they're probably random (intermittent) failures that are unrelated to your changes. You can usually spot changes that you really caused because they'll show up on all platforms, and look related to your changes. If you're not sure, you can ask us, or ask on IRC for a quicker response.
> However, this stuff worries me (3x crashed, 1x time out)
> 965721 Intermittent test_bug409604.
> test_richtext2.
> imgStatusTracke
> 969526 Intermittent
> test_richtext.
> crashed [@ KERNELBASE.dll + 0x89ae4] (ABORT: Should have mProgressTracker
> until we create mImage: 'mProgressTracker')
> 1129538 Intermittent test_draggablep
> application crashed [@ mozalloc_abort(char const*)] after "ABORT: Should
> have given mProgressTracker to mImage: '!mProgressTrac
> /image/
> 1142900 Intermittent test_richtext2.html | application timed out after 330
> seconds with no output
>
> Any comments on these crashes and time-outs?
Don't worry about those. These tests fail sometimes at random -- it's not connected to your changes.
> P.S.: Would you be able to let me know your time-zone so I know when not to
> expect feedback ;-)
I'm UTC+0200, and switching to UTC+0300 this Thursday night. Last I was aware, Ehsan lives in eastern Canada and so should be UTC-0400.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #182 |
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.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #183 |
These tests are a little mysterious. I wanted to look at
editor/
mach mochitest-plain editor/
doesn't work? I've run single tests before, but they weren't XUL files.
So I ran
mach mochitest-plain editor/
7043 INFO TEST-UNEXPECTED
xt2.html | Browserscope richtext2 selection: S-Proposed-
M - 1 should equal 1
TEST-INFO | expected FAIL
7044 INFO TEST-UNEXPECTED
xt2.html | Browserscope richtext2 selection: S-Proposed-
ody - 1 should equal 1
TEST-INFO | expected FAIL
7045 INFO TEST-UNEXPECTED
xt2.html | Browserscope richtext2 selection: S-Proposed-
iv - 1 should equal 1
TEST-INFO | expected FAIL
7046 INFO TEST-UNEXPECTED
xt2.html | Browserscope richtext2 selection: S-Proposed-
M - 1 should equal 1
TEST-INFO | expected FAIL
7047 INFO TEST-UNEXPECTED
xt2.html | Browserscope richtext2 selection: S-Proposed-
ody - 1 should equal 1
TEST-INFO | expected FAIL
7048 INFO TEST-UNEXPECTED
xt2.html | Browserscope richtext2 selection: S-Proposed-
iv - 1 should equal 1
TEST-INFO | expected FAIL
7049 INFO TEST-UNEXPECTED
hould have four SMP characters - got 𝐀𝐀, expected 𝐀𝐀𝐀𝐀
7050 INFO TEST-UNEXPECTED
hree complete characters should remain - got 𝐀, expected 𝐀𝐀𝐀
7051 INFO TEST-UNEXPECTED
wo complete characters should remain - got , expected 𝐀𝐀
7052 INFO TEST-UNEXPECTED
nly one complete SMP character should remain - got , expected 𝐀
7053 INFO TEST-UNEXPECTED
ntent should be pasted in plaintext format - got , expected green text
7054 INFO TEST-UNEXPECTED
med out while polling clipboard for pasted data. - expected PASS
7055 INFO TEST-UNEXPECTED
iled to copy the second item to the clipboard - expected PASS
7056 INFO TEST-UNEXPECTED
med out while polling clipboard for pasted data. - expected PASS
SUITE-END | took 376s
So we got a few TEST-UNEXPECTED
No sight of test_selection_
https:/
Yes, I'm running the text on Windows 7, not on Linux, but still.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #184 |
Created attachment 8582686
Easy fix for test due to new selection behaviour (layout/generic)
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #185 |
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.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #186 |
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_
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #187 |
(In reply to Jorg K from comment #97)
> These tests are a little mysterious. I wanted to look at
> editor/
> mach mochitest-plain editor/
> doesn't work? I've run single tests before, but they weren't XUL files.
That test is part of the mochitest-chrome test suite, so you can use either mach mochitest-chrome, or even better, mach mochitest (which figures out which mochitest variant a test lives in.)
(The way you can know what test suite a test file belongs to is to look for its name in the .ini files in the same directory, for example, mochitest.ini and chrome.ini for mochitest-plain and mochitest-chrome, respectively.)
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #188 |
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 roc to review!
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #189 |
Comment on attachment 8582701
Easy fix for test due to new selection behaviour (richtext2)
Review of attachment 8582701:
-------
Fantastic! r=me.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #190 |
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.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #191 |
Created attachment 8582923
Easy fix for test due to new selection behaviour (move commands)
This is the last of the updated tests.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #192 |
Created attachment 8582931
Unified patch (code + test changes) ready for next push to try.
Pushed to try server (thanks guys for the support!):
https:/
Aryeh: Please help me review the results.
Actually, I followed what was suggested for the try:
try: -b do -p all -u all[x64] -t none
Just out of interest: Why build on all platforms and then just execute on Linux? I mean, why build it in the first place? Just to see that it compiles? If it already compiled once, and I only rerun tests, that doesn't make too much sense.
Further steps: If this try run goes well, the only thing missing is a test for the changes I made. Two scenarios are already covered by the existing tests which I had to change: the "moving around with the left arrow" and the "jumping to the end of the line with a key stroke". What's missing is the "clicking beyond the end of the line". The first try run in comment #71 was done with only the code to fix the clicking. No tests failed, so there wasn't a test for this, so it needs to be added now.
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #193 |
(In reply to Jorg K from comment #106)
> Pushed to try server (thanks guys for the support!):
> https:/
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 platforms and then just execute on
> Linux? I mean, why build it in the first place? Just to see that it
> compiles? If it already compiled once, and I only rerun tests, that doesn't
> make too much sense.
Yes, to see that it compiles. Different platforms use different compilers, and maybe sometimes different compiler versions, and they treat different things as errors. Compiling the code on all platforms is usually a good resources-safety tradeoff. (Ideally all tests would be run on all platforms, but it overloads the try servers.)
> Further steps: If this try run goes well, the only thing missing is a test
> for the changes I made. Two scenarios are already covered by the existing
> tests which I had to change: the "moving around with the left arrow" and the
> "jumping to the end of the line with a key stroke". What's missing is the
> "clicking beyond the end of the line". The first try run in comment #71 was
> done with only the code to fix the clicking. No tests failed, so there
> wasn't a test for this, so it needs to be added now.
Sounds good!
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #194 |
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?
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #195 |
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 fraction will break on some systems for various reasons, and in practice we only require that they work on the try servers.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #196 |
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 that skip the next line? Perhaps you can suggest a line where it should go. Or say: After such and such.
In the test I use a <span>123</span> to get offset 3 when clicking behind it. Without the span, I get offset 4, which I find surprising, or clicking at the front gives offset 1 instead of 0. FF 36 does the same, so I guess it's right, but I'd like to understand why 4 and not 3, or 1 and not 0. Why does the span make a difference?
Anyway, the tests are passed. Without my changes, the first test fails as expected.
As I said in comment #106: There are already tests for hitting the "end" key and navigating with the arrow keys, so this test should be the only one we need additionally.
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #197 |
(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 that says
[test_
(assuming that's the file's name). Put it right before the next test line, like "[test_
> In the test I use a <span>123</span> to get offset 3 when clicking behind
> it. Without the span, I get offset 4, which I find surprising, or clicking
> at the front gives offset 1 instead of 0. FF 36 does the same, so I guess
> it's right, but I'd like to understand why 4 and not 3, or 1 and not 0. Why
> does the span make a difference?
You have a newline at the beginning of the div. That's the first character in the text node (although it doesn't normally render). If you did
<div id='div1'
all on one line, the offsets would be as you expected even without the span.
> Anyway, the tests are passed. Without my changes, the first test fails as
> expected.
>
> As I said in comment #106: There are already tests for hitting the "end" key
> and navigating with the arrow keys, so this test should be the only one we
> need additionally.
Sounds great!
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #198 |
I'll revise the test and post a new one in a second.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #199 |
Created attachment 8583354
Test case (revised)
If this is good to go, I'll submit another "unified" patch (code + all tests), if necessary.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #200 |
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/
@@ +13,5 @@
> +<body>
> +<a target="_blank" href="https:/
> +<p id="display"></p>
> +<div id="content" style="display: none">
> +</div>
Since you mentioned you're new to writing tests, I'll add some bits about how this stuff works here. I hope that helps!
The above is basically boilerplate that we include in most mochitests. The only parts that are really required are the two script elements that load the SimpleTest and event synthesis APIs.
@@ +25,5 @@
> +
> + /** Test for Bug 756984 **/
> + /** We test that clicking beyond the end of a line terminated with <br> selects the preceding text, if any **/
> +
> + SimpleTest.
This is used to tell the test harness to not stop the test once the page load finishes (which is the default.) This is required for all tests that can run past that point. For example, this test is asynchronous because of the waitForFocus call below.
@@ +27,5 @@
> + /** We test that clicking beyond the end of a line terminated with <br> selects the preceding text, if any **/
> +
> + SimpleTest.
> +
> + SimpleTest.
This is required to ensure that the test window is raised to the top on the desktop, which is needed to ensure proper event delivery.
@@ +35,5 @@
> + var sel = window.
> + var f = document.
> + theDiv.focus();
> + sel.collapse(
> + synthesizeMouse
The last argument of synthesizeMouse is the window object corresponding to the element that should receive the event. If omitted, the default is the current window object. Now, f is an HTMLDivElement, which doesn't have a contentWindow property, so f.contentWindow ends up as undefined. The reason this works is that from the perspective of the callee function, omitted arguments are undefined, so that's what this function checks for: <https:/
So please just remove this last argument here and elsewhere in the test.
@@ +36,5 @@
> + var f = document.
> + theDiv.focus();
> + sel.collapse(
> + synthesizeMouse
> + synthesizeMouse
Nit: You can just issue one synthesizeMouse as {type: "click"} and it will dispatch both of these events internally.
@@ +37,5 @@
> + theDiv.focus();
> + sel.collapse(
> + synthesizeMouse
> + synthesizeMouse
> + var selObj = window.
Nit: You already have |sel| ...
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #201 |
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 makes the test fail with:
failed | uncaught exception - NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUt
This is actually the only test I intended to submit ;-)
This is for the case where the user clicks beyond the end of the line.
There are two tests already which I had to adapt to the new selection behaviour which test the moving to the end
(editor/
and moving from the subsequent line using left arrow
(layout/
If you wanted to be really purist a test with a "div contenteditable" could be added where an empty line is first filled with some text, which is then removed so the range becomes empty. The code caters for this case.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #202 |
(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 from "mousedown/up" to "click" as you had suggested makes
> the test fail with:
> failed | uncaught exception - NS_ERROR_FAILURE: Component returned failure
> code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUt
> chrome:
Err, sorry, I misspoke. I should have said: "remove the type value" altogether (just pass an empty object `{}'). That should do the right thing: <https:/
> This is actually the only test I intended to submit ;-)
>
> This is for the case where the user clicks beyond the end of the line.
> There are two tests already which I had to adapt to the new selection
> behaviour which test the moving to the end
> (editor/
> and moving from the subsequent line using left arrow
> (layout/
>
> If you wanted to be really purist a test with a "div contenteditable" could
> be added where an empty line is first filled with some text, which is then
> removed so the range becomes empty. The code caters for this case.
I think relying on the selection movement tests is sort of OK, but I really prefer to have much better testing on this, since this code is extremely fragile and I'm pretty sure that without extensive tests, we'll end up breaking it again in the future. That being said, I guess it's not fair for me to make you do this. :-)
But at the very least, we should have tests for clicking past the end of the line with the line terminating with a bunch of inline elements that have a text node inside them. That is essentially what this bug is really about. So please add some test along those lines.
Also, to reiterate, the second test in your test case is wrong...
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #203 |
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 ;-)
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #204 |
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 empty line 7, DIV is still returned.
If the code were wrong, this line couldn't be clicked at all and the caret would move to the previous or subsequent line. I know, because at first my code didn't cater for this case.
IMHO my test is correct, if you don't think so, please be more specific.
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 this is fixing a long-standing TB bug that people have been pulling their hair out for over 10 years now.
If you really want more tests to be written, I can do that, but *afterwards* ;-)
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #205 |
(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 lines 1-6 and 8, "#text" will be
> returned, but for the empty line 7, DIV is still returned.
>
> If the code were wrong, this line couldn't be clicked at all and the caret
> would move to the previous or subsequent line. I know, because at first my
> code didn't cater for this case.
>
> IMHO my test is correct, if you don't think so, please be more specific.
OK, I understand what you want to test now. So your test is actually correct, it was the comments where you mentioned clicking past the *second* line that confused me. :-)
> 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
> this is fixing a long-standing TB bug that people have been pulling their
> hair out for over 10 years now.
Sorry but this patch is not suitable for backporting into Aurora (which will soon become Beta) at this point, because it's quite risky in terms of the possibility to cause regressions. It needs to land on trunk and ride the trains. I understand that you'd like to see it fixed as soon as possible, but please be a bit more patient. :-)
> If you really want more tests to be written, I can do that, but *afterwards*
> ;-)
OK, that's fair. :-)
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #206 |
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 - Collapse the selection on the last text node on the line, skipping br and inline frames when clicking past the end of line; r=roc,ehsan".
Thanks again! Once you address these nits, this is ready to be checked in.
::: layout/
@@ +43,5 @@
> + is(selRange.
> + is(selRange.
> + }
> +
> + // click beyond the second line (100px to the left and 2px down), expect DIV.
Nit: please make this "first line".
@@ +47,5 @@
> + // click beyond the second line (100px to the left and 2px down), expect DIV.
> + // This is the previous behaviour which hasn't changed since the line is empty.
> + // If the processing were wrong, the selection would end up in the preceing non-empty line.
> + theDiv = document.
> + sel = window.
Nit: this is not needed.
In Mozilla Bugzilla #756984, Charles (tanstaafl-libertytrek) wrote : | #207 |
(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
>> this is fixing a long-standing TB bug that people have been pulling their
>> hair out for over 10 years now.
> Sorry but this patch is not suitable for backporting into Aurora (which will
> soon become Beta) at this point, because it's quite risky in terms of the
> possibility to cause regressions. It needs to land on trunk and ride the
> trains. I understand that you'd like to see it fixed as soon as possible,
> but please be a bit more patient. :-)
Oh god, I hope I'm mis-reading this...
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?
Please tell me it ain't so.
As for regressions - so you're saying it is OK for major regressions to happen for the entire lifecycle of TB 31 (see all of the Address auto-entry bugs that are only just now being fixed), but not for Firefox?
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #208 |
Created attachment 8584639
Unified patch (code + test changes + four times revised new test)
This should be good to go then ;-)
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #209 |
(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 free to compile their own version, which is what I'll do.
In Mozilla Bugzilla #756984, Charles (tanstaafl-libertytrek) wrote : | #210 |
(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,
> that's 10 months ;-)
> However, everyone is free to compile their own version, which is what I'll
> do.
Fine for us, but what about companies using TBird...
<sigh> I just don't get this kind of reluctance... even if there were regressions, they could easily be fixed...
Oh well, I guess beggars cannot be choosers...
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #211 |
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.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #212 |
Comment on attachment 8584639
Unified patch (code + test changes + four times revised new test)
Review of attachment 8584639:
-------
Thanks, looks great!
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #213 |
(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 software to pick its foundation and additional patches. I've seen client software (KompoZer, or for example KDE with its so-called "build dependencies") where I couldn't believe my eyes how much they patch the underlying components.
This discussion, however, should be continued elsewhere.
In Mozilla Bugzilla #756984, Charles (tanstaafl-libertytrek) wrote : | #214 |
(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, and prefer to
> give things more time to bake.
Yes, but Firefox is primarily a web browser - just how bad could a regression in some code in the editor be?
That said, Jorg is correct that this isn't the right place for such a conversation...
So, all that is left is to say THANK YOU!!! to Jorg, Ehsan, and everyone else involved for finally getting this bug squashed!
In Mozilla Bugzilla #756984, Malix (malix0) wrote : | #215 |
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.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #216 |
(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 Firefox, we are usually very conservative, and prefer to
> > give things more time to bake.
>
> Yes, but Firefox is primarily a web browser - just how bad could a
> regression in some code in the editor be?
Potentially very bad. :-) Any regression that can break lots of websites is very bad.
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #217 |
In Mozilla Bugzilla #756984, Aryeh Gregor (simetrical+launchpad) wrote : | #218 |
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. Perhaps file a bug against the Thunderbird product, or get on IRC/e-mail/etc. with the appropriate people.
In Mozilla Bugzilla #756984, Philringnalda (philringnalda) wrote : | #219 |
In Mozilla Bugzilla #756984, Charles (tanstaafl-libertytrek) wrote : | #220 |
Ummm... ok, but... who are these 'Thunderbird people', and how do we contact them?
In Mozilla Bugzilla #756984, Fm-mozbugs (fm-mozbugs) wrote : | #221 |
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.
In Mozilla Bugzilla #756984, Mozilla-jorgk (mozilla-jorgk) wrote : | #222 |
(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" that is used in Thunderbird when writing an e-mail messase is Mozilla core software. It is also used in Firefox: Please go to http://
The problem happens when losing the font goes unnoticed while writing. You will notice it when reading a reply that contains your original ill-formatted message.
The (In reply to Charles from comment #134)
> Ummm... ok, but... who are these 'Thunderbird people', and how do we contact them?
They are aware of the problem via this meta bug 1142879.
In Mozilla Bugzilla #756984, Fm-mozbugs (fm-mozbugs) wrote : | #223 |
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.
In Mozilla Bugzilla #756984, Fm-mozbugs (fm-mozbugs) wrote : | #224 |
Is there any way we can lobby for landing it in 38?
Changed in thunderbird: | |
status: | Confirmed → Fix Released |
In Mozilla Bugzilla #756984, Ehsan-mozilla (ehsan-mozilla) wrote : | #225 |
(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!
In Mozilla Bugzilla #756984, Mike-cloaked (mike-cloaked) wrote : | #226 |
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 once v39 moves to that channel in the next few days? Of course it would mean a longer delay for those running stable versions. Anyway congratulations on this superb work.
In Mozilla Bugzilla #756984, Fm-mozbugs (fm-mozbugs) wrote : | #227 |
Release channel is at 31.5 as of this post.
Seems a long way to reach 39 assuming it moves +1 at a time
In Mozilla Bugzilla #756984, Mike-cloaked (mike-cloaked) wrote : | #228 |
OK I guess the delay for one version is about two months if it does not get into v38?
In Mozilla Bugzilla #756984, Charles (tanstaafl-libertytrek) wrote : | #229 |
No... if it doesn't get back-ported to 38, then it has to wait for version 45 - another, what, 10 months?
Paul White (paulw2u) wrote : | #230 |
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 |
Using trunk builds 20030428 onw winxp, macosx and linux if the user changes
their Mail composition default for font style, the prepopulated text used in
Replys "xyx wrote:" does not change to this default. If the user backspaces in
the first line all the way to the left, the newly typed text picks up the font
style of this pre populated text.
1. Launch app - set to reply above quoted text (default for commercial builds)
2. Change your mailnews preference for composition to another font style.
3. Click Reply to a message someone sent preferably with the default font style.
4. Start typing (note you will see your default style), backspace all the way
to the left margin, start typing again.
Result: the font is now of the style of the prepopulated text instead of your
default text.
Expected: to be able to backspace and still have my default font used.