64152 - In the Composer test page I can apply different text formats such as bold and italics but I cant remove them in the toolbar

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P2)

Description

[Tim Smith]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010102
BuildID:    20011010204

In the composer test page I can change anything by selecting the text, clickin
and icon in the toolbar to apply and clickin again the remove, but for some
funky reason the bold, italic and underline will apply but wont remove using the
toolbar

Reproducible: Didn't try
Steps to Reproduce:
1.Run the comoser test in the debug menu	
2.Select some text
3.Click the bold, italic, or underline icon in the toolbar
4.Click it again

Actual Results:  The window goes from the top of the selected text to the bottom
of the selected text which is the very bottom of the page in my case		

Expected Results:  The text should remove whatever style you added (italic,
bold, or underline)

Comment 1

[Keyser Sose]

WORKSFORME
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001010512

Reporter are you still seeing this?

Comment 2

[Chris Petersen]

I can reproduce this problem in the 2001010808 (Mac), 2001010804 (Win) and
2001010808 (Linux) build.

Comment 3

[Chris Petersen]

The issue occur when multiple elements are selected and style settings have been
applied via the toolbar. Clicking bold, italic, or underline icons on toolbar ,
with elements selected, are not removed for paragraphs.

Comment 4

[Chris Petersen]

Attachment: Two paragraph elements

Comment 5

[Chris Petersen]

Steps to reproduce:

1) Open attached test case in Composer.

2) Select both paragraphs.

3) Click bold, italic , and underline icons to apply to select paragraphs.

4) With paragraphs still selected, click bold, italic , and underline icons

to remove each setting.

5) Notice that none of the styles are removed from the paragraphs.

Comment 6

[Kevin McCluskey (gone)]

Changed component to Editor. Reassigned

Comment 7

[rubydoo123]

peterson and I verified the issue, assigning this to jfrancis

Comment 8

[Joe Francis]

hmm.  I cannot reproduce this with a build from the 11th of jan.  I also tried 
NS6 installed bits just for giggles.  No code in this area has changed recently 
either.  If there is a problem I suspect it event related.

I'm going to mark worksforme, reopen if you can still get this to happen on a 
later build.

Comment 9

[sujay]

verified in 1/16 build.

Comment 10

[Tim Smith]

It still occurs in the latest nightly build 2001012720.  If you can reproduce it
try selecting the whole page.  That seems to set it off.  It just isn't handing
all the different formats of text in the demo page right.

Comment 11

[Joe Francis]

i am able to get this to happen now.  reopening bug.

Comment 12

[Joe Francis]

Attachment: patch for fix

Comment 13

[Joe Francis]

the problem was that nsHTMLEditor::GetInlineStyle() did not check nodesto see if
they were editable.  There is a textnode that is a single newline in between the
paragraphs that represents the formatting in the html source.  This newline is
of course not bolded, underlined, etc, so GetInlineStlye() concludes that not
all the selection is bold etc.  Anyway, easy fix.  Awaiting review on patch.

Comment 14

[Keyser Sose]

Adding PATCH & review keyword.

Comment 15

[Joe Francis]

kin, simon, can u r/sr this small patch?

Comment 16

[Joe Francis]

moz 0.8

Comment 17

[Simon Fraser [no longer active]]

Better to declare and init the iter in one step:
     nsCOMPtr<nsIContentIterator> iter(do_CreateInstance(kCContentIteratorCID));

Otherwise that looks fine. sr=sfraser

Comment 18

[kinmoz]

r=[e-mail]

Removing "awaiting review" from the status whiteboard.

Comment 19

[Joe Francis]

fixed

Comment 20

[sujay]

verified in 2/6 build.