Setting font color to "" doesn't remove font color attribute

VERIFIED FIXED in mozilla0.9.3

Status

()

P3
major
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: scalkins, Assigned: cmanske)

Tracking

Trunk
mozilla0.9.3
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed, reviewed, nsBranch+, PDT+)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Sorry if this is a dupe, but I couldn't find this bug
See this on branch and trunk with todays builds (7/6)
All platforms

Steps to repro:
1)Launch composer
2)Type some text
3)Change the color of subsequent text you type from default to some other color
via selecting it, under the Format-->Text color menu
4)Verify it applies the new color for new text typed
5) Go back to Format-->Text color menu, click the Default button. Then click OK
6)Type some more text

Actual results:The default color does not apply, you still see the new color
when typing text.
 The same goes for changing colors via the text and background icons on the
editor bar. 

This affects IM as well, where it's more visible.

Comment 1

18 years ago
sure enough, the default selection is not working correctly.
Assignee: beppe → cmanske
Priority: -- → P3
Whiteboard: [dialog]
Target Milestone: --- → mozilla1.0

Comment 2

17 years ago
In the html source I see that we are adding: <font color="">

We might want to release note that this button doesn't work.  Workaround is to 
use Remove Text Styles (or Discontinue Text Styles) and re-apply any styles that 
are desired.
Keywords: relnoteRTM
(Assignee)

Comment 3

17 years ago
Something has changed in the rules code such that setting color to "" no longer
removes the color.
But this is easy to fix in JS. Patch comming.
Status: NEW → ASSIGNED
(Assignee)

Comment 4

17 years ago
Created attachment 41817 [details] [diff] [review]
Use "RemoveTextAttribute" when clearing text color

Updated

17 years ago
Whiteboard: [dialog] → [dialog] [QAHP]
(Assignee)

Comment 5

17 years ago
I would argue that the suggested JS change is much better than the previous
code that assumed setting font color to empty string should remove the attribute,
i.e., we should be using "RemoveTextAttribute" instead.
This is an important useability issues, so we should make this fix for 6.1.

r=akkana for the fix.
Keywords: relnoteRTM
Summary: Default button in color picker doesn't really reset colors → Setting font color to "" doesn't remove font color attribute
Whiteboard: [dialog] [QAHP] → [dialog] FIX IN HAND, need sr=
Target Milestone: mozilla1.0 → mozilla0.9.3

Comment 6

17 years ago
sr=kin@netscape.com
Whiteboard: [dialog] FIX IN HAND, need sr= → [dialog] FIX IN HAND, reviewed
(Assignee)

Comment 7

17 years ago
Per discussion with beppe, setting nsBranch.
Keywords: nsBranch
Whiteboard: [dialog] FIX IN HAND, reviewed → [dialog] FIX IN HAND
(Assignee)

Comment 8

17 years ago
checked into trunk
(Assignee)

Updated

17 years ago
Whiteboard: [dialog] FIX IN HAND → fixed, reviewed
(Assignee)

Updated

17 years ago
Keywords: vtrunk

Comment 9

17 years ago
adding nsBranch+
Whiteboard: fixed, reviewed → fixed, reviewed, nsBranch+

Comment 10

17 years ago
this is still not fixed in today's 7/11 trunk build.

Comment 11

17 years ago
I take that back.

THis is fixed on 7/11 trunk. it is indeed working for me on the trunk..

Removing vtrunk keyword.

Lets get this puppy in on the branch.
Keywords: vtrunk
(Assignee)

Comment 12

17 years ago
PDT+ approved by Steve Elmer.
Whiteboard: fixed, reviewed, nsBranch+ → fixed, reviewed, nsBranch+, PDT+
(Assignee)

Comment 13

17 years ago
Checked into MOZILLA_0_9_2_BRANCH.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 14

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