Changing style (removing 'preformat') on a <pre> block is difficult

NEW
Unassigned

Status

()

12 years ago
12 years ago

People

(Reporter: david, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6


Sometimes, changing the style of text in the Thunderbird compose window doesn't work.

I attach an easily reproduceable example.

This is using the Version 3 alpha 1 release 20060822 but the problem also happens in the production builds.


Reproducible: Always

Steps to Reproduce:
1. Open the attached HTML in firefox.
2. Click the firefox browser window.
3. Press CTRL-A to select the whole lot
4. Press CTRL-C to copy the whole lot.
5. Open a new compose window in thunderbird
6. Click in the text area of the window
7. Press CTRL-A to highlight anything there
8. Press CTRL-V to paste the content into that window replacing anything there
9. Click the mouse on the line containing the yyyy
10. Notice that the style is "Preformat"
11. Try to change the style to "Body Text"
12. Notice that the style DOES NOT change to "Body Text" but remains "Preformat"
13. Try to change the style to "Body Text" again
14. Notice that the style DOES change to "Body Text" the second time around.
Actual Results:  
Wrong behaviour.

Expected Results:  
When changing the style to "Body Text", it should actually change.
(Reporter)

Comment 1

12 years ago
Created attachment 234987 [details]
html for reproducing the issue

Comment 2

12 years ago
This is a core editor problem (occurs in NVu, Seamonkey Composer, and HTML mail compose).  The specific action here is a single line in a multi-line block being 'changed' but the only change is that the <pre> is split into two <pre> blocks.

Note that as reported, change is attempted without a selection, only the cursor within the line that should be changed.

The <pre> block ends with <br><br>, and the line that is being changed is the last (visible) line in the block:
================
bodytext<br>
<pre wrap="">line1<br>line2<br>line3<br><br>targetline<br><br></pre>bodytext
================
After the attempted command, there are now two blocks, the second one containing targetline and a single <br>:
================
bodytext<br>
<pre wrap="">line1<br>line2<br>line3<br><br></pre><pre 
wrap="">targetline<br></pre>bodytext
================
Visibly, the spacing between targetline and the text above increases slightly.

If, in the original text, I select just targetline (dragging the mouse from beginning to end), the formatting indicator continues to show 'preformatted'; and if I type Shift+Right, the selection expands (invisibly) to include the first <br> and the indicator *still* shows 'preformatted'.

But if I Shift+Right again to include the second <br>, the indicator changes to 'mixed' (even tho only <pre> text is actually part of the selection) -- and in this state, changing the dropdown to 'body text' actually makes the change.
================
bodytext<br>
<pre wrap="">line1<br>line2<br>line3<br><br></pre>targetline<br><br>
bodytext
================

Even with the extra features in Composer (such as being able to select the <pre> tag by clicking on the <pre> item in the status bar), there is no way to tell exactly what is selected or exactly what is going to change, and any serious editiong job requires mucking about in the HTML source.
Assignee: mscott → nobody
Status: UNCONFIRMED → NEW
Component: Message Compose Window → Editor
Ever confirmed: true
OS: Windows XP → All
Product: Thunderbird → Core
QA Contact: message-compose
Hardware: PC → All
Summary: Message compose: changing text style sometimes doesn't actually change the text style → Changing style (removing 'preformat') on a <pre> block is difficult
Version: unspecified → Trunk
QA Contact: editor
You need to log in before you can comment on or make changes to this bug.