Font size and style of html message changes when refocusing on edit window [Affects TB HTML compose]

RESOLVED DUPLICATE of bug 250539

Status

()

Core
Editor
RESOLVED DUPLICATE of bug 250539
7 years ago
6 years ago

People

(Reporter: Martin Jungowski, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1

When composing an HTML message in Thunderbird 3.1 the font size and style in the message body changes after editing the subject.

Reproducible: Always

Steps to Reproduce:
1. Start composing a new HTML message
2. Start typing something in the message body
3. Edit the message's subject
4. Go back to the body pane and resume typing

Actual Results:  
After editing the subject font size and style are diffent than before

Expected Results:  
Font size should be the same

Seems to be architecture independent, I was able to reproduce this bug in Fedora 13 (x86_64) and openSUSE 10.3 (x86).
(Reporter)

Comment 1

7 years ago
Created attachment 466978 [details]
Different font size & style after editing the subject

Comment 2

7 years ago
While most of these editor complaints have been duped to bug 250539
We probably should be breaking this one out as a specific (different) bug
See https://bugzilla.mozilla.org/show_bug.cgi?id=250539#c93

This appears to be a bug in "selection" rather than editor core.
Martin, when you return to the editor window, try positioning the cursor before the last typed character, then resume your composition.

Thinking about marking this new..suggestions welcome for the core component.

Comment 3

7 years ago
This seems to be reproducible using the Midas demo
http://www.mozilla.org/editor/midasdemo/
So that would indicate core code.
Working on STR.

Comment 4

7 years ago
STR:
Start the midas demo and select a font
Type a few characters in that font
Remove focus on the edit window by using the dropdown for size, but just click out and not select anything.
Attempt to refocus the edit window after the last typed character
The cursor appears to be just to the right of the last typed character
Resume typing.

Result: Further composition results in the lose of the previously selected font.
I believe this is because the cursor position is actually outside of the span tag.
Thunderbird uses the font tag rather than span, but the same issue is seen when focus is returned to the edit panel, after moving focus elsewhere and attempting to continue the edit.

This has caused untold grief and many duplicate bugs for Thunderbird HTML composition.
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → Editor
Ever confirmed: true
OS: Linux → All
Product: Thunderbird → Core
QA Contact: front-end → editor
Summary: Font size and style of html message changes after editing the subject → Font size and style of html message changes when refocusing on edit window [Affects TB HTML compose]
Version: unspecified → Trunk

Comment 5

7 years ago
This appears to be a duplicate of the symptoms described in Bug 273622, the cause of which is explained in this comment in Bug 250539:
https://bugzilla.mozilla.org/show_bug.cgi?id=250539#c93
Yes, this is indeed a problem with where the selection ends up being.

Perhaps a good fix would be to inspect the selection at the beginning of nsHTMLEditRules::WillInsertText and adjust it if it's right after an inline element which is the last child of a block element...

Comment 7

7 years ago
(In reply to comment #6)
> Yes, this is indeed a problem with where the selection ends up being.

That's what I thought.  You seem to be MUCH more familiar with the HTML structure in the editor, and with the code (and what might need to change).  I'm more concerned with getting all the bugs which describe this problem into one place where the fix can be done.  Bug 273622 seems to have the most accurate description, but that's been DUP'd to Bug 203810 -- which I'm not sure is appropriate; I can't tell by reading the description in Bug 203810, or by looking at the proposed patch (now outdated, I'm sure).

I'd like your input into whether this bug should also be DUP'd to Bug 203810, or whether Bug 273622 should be reopened and this bug DUP'd to Bug 273622; you certainly seem more qualified to make that determination than I!
Bug 203810 doesn't have anything to do with this bug.

Bug 273622 (or part of it) might be a dupe of this bug, but it's not worth fiddling with it after all this time.  Let's just keep this bug open to track the issue at hand.
If this bug references change of size of html font size while typing. Then it applies to SM2.0.x as well. Has every since SM 2 has existed. 

what happens is you type a word or sentence and pause for a few seconds, the start typing again. Font will always resize to original size designed in SM2 even if you have default set to a larger size.  And will even happen if you pause in the middle of a word.

Comment 10

7 years ago
(In reply to comment #9)
> If this bug references change of size of html font size while typing. [...]

No, it doesn't (see the "Summary" and the Steps to Reproduce).
I can use those steps to reproduce in SM2.0.2
sorry Version 2.0.6 not 2.0.2

Updated

7 years ago
Duplicate of this bug: 601208

Updated

6 years ago
Duplicate of this bug: 677046

Comment 15

6 years ago
Bug 677046 (which I submitted) was much more specific than what I read above as to how to replicate this intermittent bug, but it got discarded. 

1. Hit 'Reply' to any e-mail. The bug doesn't occur in a fresh e-mail.
2. Type the following (without the indent):
	the quick fox jumped
3. Using the mouse, place the cursor before the 'f' of 'fox' and start typing 'brown ' (without the apostrophes)
4. Using the mouse, place the cursor after 'jumped'
5. start typing a space plus:
	over the lazy dog

You should find that 'over the lazy dog' is in a reduced font.
(In reply to Ehsan Akhgari [:ehsan] from comment #6)
> Yes, this is indeed a problem with where the selection ends up being.
> 
> Perhaps a good fix would be to inspect the selection at the beginning of
> nsHTMLEditRules::WillInsertText and adjust it if it's right after an inline
> element which is the last child of a block element...

On the second thought, this is just a dupe of bug 250539.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 250539

Comment 17

6 years ago
I won't quibble about the duping to bug 250539, but this is easily reproducible using the midas demo, and is symptomatic of loosing the selected font.
Simple steps to reproduce using the midas demo:
Select a font
Type in several words
Use your mouse to position the caret to the first word by left click
Make some changes there

Now attempt to reposition the cursor at the end of the line via mouse left click

Result:
You are outside the span, and your selected font does not apply.

Note:
After editing the 1st word, if you move the cursor to the right via the right arrow key you are good to go.(It's only the mouse repositioning that causes the problem)

I don't see how this can be the desired behavior, even for the midas demo.
For Thunderbird message composition, I think that mouse left click to reposition the cursor would be the most common case.
You need to log in before you can comment on or make changes to this bug.