Closed Bug 485638 Opened 15 years ago Closed 12 years ago

Text styles formatting only applied to first part of multiple discontiguous selections (bold/italic/underline, text color change, smaller/bigger font size)

Categories

(Core :: DOM: Editor, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: annie.sullivan, Unassigned)

References

()

Details

Steps to reproduce:
1. Go to midas demo: http://www.mozilla.org/editor/midasdemo/
2. Type "test test"
3. Select first word, then press Ctrl to select second word, but not space in between.
4. Apply some formatting (e.g. bold)

Actual result:
Formatting applied to first segment of selection only, e.g.
<span style="font-weight: bold;">test</span> test

Expcted result:
Either formatting should be applied to all segments of selection, or multiple discontiguous selections should not be allowed.
I confirm same bug on Ubuntu 10.4 and ThunderBird 3.0.4
Taking this.
Assignee: nobody → ehsan
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Addition from Bug 608205.

Multiple selections where the whole line is selected does NOT interrupt formating, only when selection stops before new line does formating break.

so for example (* indicates selecttions)

*Hello World*
Nice Day Today
Good *Night* World
Good *Morning World*

In this example "Hello World" and "Night" will be formated but not "Morning World"


*Hello World*
Nice Day Today
*Good Night World*
Good Morning *World*

In this example all 3 selections will get format since the two first selects the whole line even though there is an unselected line between the two first.

So its only when selections does not include last char before newline that formating ends prematurely.
My report seems like it COULD BE a variation of the circumstances reported in Bug #485638.

My OS: Fully patched Windows Vista Home Premium

Thunderbird version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7

I was composing a new HTML message (not a forward or reply) with nothing except two lines of text (Body Text, Variable Width) that automatically wrapped to a second line.  I then selected the last word of line #1 (not including the end-of-line space) and applied Bold and Italics.  After that change, I selected a string of text that began before the Bolded/Italicized word at the end of line #1 and the selection continued to the end of the e-mail.  I then applied a color change to this multi-line selection.

Expected Result: All the selected text should have changed color.

Actual Result: The portion of the selected text on line #1 reflected the new color; the portion of the selected text on line #2 was ignored.

This bug IS reproducible.

Additional Info: Above I specifically indicated the Bold and Italics were applied to only the last word of line #1; the space following the last word of line #1 was not included in the application of the Bold and Italics.  However, if my selection also included the trailing space, the bug is not revealed.
Ehsan Akhgari [:ehsan] (assignee), can we still hope for a patch from you for this problem? Duplicates keep coming in...
Summary: Formatting only applied to first segment of multiple discontiguous selections → Text styles formatting only applied to first part of multiple discontiguous selections (bold/italic/underline, text color change, smaller/bigger font size)
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

More detailed STR of duplicate bug 753298:

Steps to reproduce:

Steps 1 and 2 are common to all scenarios.

1. Press Write button
2. Type the following text in the message body:
abc def
ghi jkl
mno pqr

Scenario 1

3. Select b, h, o (keeping ctrl pressed)
4. Choose a different text color from the picker

Scenario 2 -- same happens with italic and underline buttons

3. Select e and q (keeping ctrl pressed)
4. Press bold button
Note that other combinations might work correctly sometimes.

Scenario 3 - same goes for smaller/bigger font size

3. Select abc, pqr (keeping ctrl pressed)
4. Press larger font size button.

Note: The deletion works correctly with multiple selection.


Actual results:

Scenario 1

Only b changed color, h and o remained unchanged.

Scenario 2

e became bold, q remained unchanged.

Scenario 3

abc became larger and somehow bold, while pqr seemed unchanged.


Expected results:

Scenario 1

All the selected text should have changed its color.

Scenario 2

All the selected text should have become bold.

Scenario 3

All the selected text should have become larger, but not bold.

-------

confirming almost exactly as described above
scenario 3, both "abc" and "pqr" get larger, but "abc" gets an additional <big> over "pqr" (still wrong)

selecting whole non-contiguous words and apply format like bold sometimes works.
switching a format on and off multiple times on dis-contiguous selection sometimes works from 2nd time onwards.

it's very unpredictable, and clearly not working as expected.
No, in fact I have plans to remove support for multi-range selections at some point.
Assignee: ehsan → nobody
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
(In reply to Ehsan Akhgari [:ehsan] from comment #12)
> No, in fact I have plans to remove support for multi-range selections at
> some point.

Ehsan,
Thunderbird has a feature "reply selected"
Where multiple selections can be made prior to calling the Editor.
These selections are not shown as "selected" when entering the editor code.

Hopefully, your removal of multi-range selections will not affect this feature.
Just an FYI to keep in mind.
(In reply to Ehsan Akhgari [:ehsan] from comment #12)
> No, in fact I have plans to remove support for multi-range selections at
> some point.

Hmm, what a pity! I'd think that multi-range selections would be a lot more useful to many users than, say, an imbuilt chat client in Thunderbird.

Ehsan, can you say something *why* you want to remove this useful feature (especially considering we keep getting duplicates)?

Is there a technical problem? I always imagine that if we can handle a single selection correctly for whichever command, then applying that same command sequentially on a number of selection segments (e.g. selection[1], selection[2], selection[3]) should not be too hard?
I filed bug 753718 to explain the reasons for removing multi-range selection support.  If you want to discuss it, a newsgroup might be a better place, though.
You need to log in before you can comment on or make changes to this bug.