If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in mozilla0.8

Status

()

Core
Editor
P2
major
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Tim Smith, Assigned: Joe Francis)

Tracking

Trunk
mozilla0.8
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
WORKSFORME
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2001010512

Reporter are you still seeing this?

Comment 2

17 years ago
I can reproduce this problem in the 2001010808 (Mac), 2001010804 (Win) and
2001010808 (Linux) build.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

17 years ago
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

17 years ago
Created attachment 22088 [details]
Two paragraph elements

Comment 5

17 years ago
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.
Changed component to Editor. Reassigned
Assignee: kmcclusk → beppe
Component: Compositor → Editor
QA Contact: petersen → sujay

Comment 7

17 years ago
peterson and I verified the issue, assigning this to jfrancis
Assignee: beppe → jfrancis
(Assignee)

Comment 8

17 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Updated

17 years ago
Status: RESOLVED → VERIFIED

Comment 9

17 years ago
verified in 1/16 build.
(Reporter)

Comment 10

17 years ago
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.
(Assignee)

Comment 11

17 years ago
i am able to get this to happen now.  reopening bug.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 12

17 years ago
Created attachment 23692 [details] [diff] [review]
patch for fix
(Assignee)

Comment 13

17 years ago
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.
Whiteboard: fix in hand, awaiting review

Comment 14

17 years ago
Adding PATCH & review keyword.
Keywords: patch, review
(Assignee)

Comment 15

17 years ago
kin, simon, can u r/sr this small patch?
(Assignee)

Comment 16

17 years ago
moz 0.8
Priority: -- → P2
Target Milestone: --- → mozilla0.8

Comment 17

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

Otherwise that looks fine. sr=sfraser

Comment 18

17 years ago
r=kin@netscape.com

Removing "awaiting review" from the status whiteboard.
Whiteboard: fix in hand, awaiting review → fix in hand
(Assignee)

Comment 19

17 years ago
fixed
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Keywords: patch, review
Resolution: --- → FIXED
Whiteboard: fix in hand

Comment 20

17 years ago
verified in 2/6 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.