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)
Core
DOM: Editor
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.
Updated•14 years ago
|
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Comment 5•14 years ago
|
||
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.
Comment 10•12 years ago
|
||
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)
Comment 11•12 years ago
|
||
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.
Comment 12•12 years ago
|
||
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
Comment 13•12 years ago
|
||
(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.
Comment 14•12 years ago
|
||
(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?
Comment 15•12 years ago
|
||
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.
Description
•