106274 - Colors is not correct on toolbar colorpicker swatch when selection is collapsed (at caret)

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Tracy Walker [:tracy]]

seen on Linux commercial build 2001-10-23-08-trunk 
(this is the only build out so far this morning. I will update the Platform/OS 
if it shows on others)

-Open composer

notice the interlinked squares icon that denotes the active colors of text and 
background.  They are blank(colorless).  

-Click on the icon and selected and accept a color for a font.

The color for the font is active but the toolbar icon doesn't change to the 
selected color as expected.

Comment 1

[Charles Manske]

I've also noticed this. Seems we aren't getting the correct color at the caret
location. It does display the color when you select text that has a color set.
I believe it's an editor core bug, but I'll take it for now to debug it more.

Comment 2

[sairuh (rarely reading bugmail)]

just wondering: what theme is this seen in --or is it in both...?

Comment 3

[Tracy Walker [:tracy]]

Sarah,  you can't switch from either theme to the other.

Comment 4

[sairuh (rarely reading bugmail)]

erk, you're right! sorry, forgot about bug 106273 [but that has an upcoming fix,
at least]...

Comment 5

[Charles Manske]

Themes don't have anything to do with this.
nsHTMLEditor::GetFontColorState() (which calls GetInlinePropertyBase())
is returning an empty string for the color rather than the actual color at the 
caret.

Comment 6

[Charles Manske]

Colors don't show at all now!

Comment 7

[Charles Manske]

*** Bug 105534 has been marked as a duplicate of this bug. ***

Comment 8

[sujay]

we need to get this fixed ASAP.

Comment 9

[Kathleen :Brade]

is there a bug for bold and other styles not working correctly?  should this bug
be generalized?

Comment 10

[Joe Francis]

Brade, what do you mean?  There is a bug for the whole toolbar not showing state 
- Waterson has a fix for that (already in?).

Comment 11

[Charles Manske]

Added depends, which currently masks this bug. But underlying problem still 
exists -- will have to wait for fix to bug 101982 to investigate this more.

Comment 12

[michael wendell]

Thanks to a fix to bug 101982, this works for me on Win 2k using build
2001111503 and Mac OS 9.1 using build 2001111504.

Resolving WORKSFORME.  

Comment 13

[Tracy Walker [:tracy]]

verified on commercial builds:

windows 2001-11-15-05-trunk
linux 2001-11-15-06-trunk
mac 2001-11-15-04-trunk

the color is back in the icon

but the icon is not maintaining the proper color.  I believe that is addressed 
bug 101982?

Comment 14

[Charles Manske]

I changed the summary to better describe what I saw.
This bug still exists *when selection is collapsed*.

Comment 15

[Charles Manske]

Really changing the summary this time.

Comment 16

[Joe Francis]

Attachment: diffs for editor/libeditor

Most of the diff is just some extraneous comment removal.  I also had to update
the signature of a protected method so that caller/callee agree on string
types.	But the real fix is just to pass along attribute, value, and retrieved
value when making one of the inline style calls.

Comment 17

[michael wendell]

This works for me on Win 2k using build 2001112603.  Is anyone still seeing 
this problem?

Comment 18

[michael wendell]

. . . but the problem described in 105534 (which was duped to this one) is 
still happening. 

Comment 19

[Charles Manske]

Comment on attachment 59082 [details] [diff] [review]
diffs for editor/libeditor

r=cmanske
So did you eliminate the "mTypeInState" stuff in a different bugfix? Not clear
to me how you could remove all the code you did! I did test it and it does
work.

Comment 20

[Kathleen :Brade]

michael wendell--if this bug is resolved fixed, and the duplicate bug still is a
problem, then reopen the duplicate.  However, *please* wait for this bug to be
resolved before reopening (unless you've tested the patch).

Comment 21

[TucsonTester1]

Noticed differences in the way that the color picker reacts to the tool icon
depending upon where you access it from.  
Text Color Icon (toolbar)- The toolbar icon changes to whatever color you choose
but as soon as you stop typing it reverts back to black (default) - it will
still type in the color font you selected.  Also if you go back into the color
picker the last color you selected is no longer highlighted.

Background Color Icon (toolbar) - Acts as you would expect it to.  The toolbar
icon changes to the color you choose and remains that color until you select
another color in the color picker, also if you go back into the color picker the
last color you selected is still highlighted.

Accessing from Format > Page Colors and Background
Normal Text - The toolbar icon does not change color (remains the default black)
but it will change the normal text and any new text to the color selected.  Also
if you go back into the color picker the last color you selected is still
highlighted.

Background - The toolbar icon does not display the color you selected until you
make some change in the document body (eg. type new text, highlight text, or
just click the mouse in the document body).  Otherwise it acts as expected.

Comment 22

[kinmoz]

Comment on attachment 59082 [details] [diff] [review]
diffs for editor/libeditor

sr=[e-mail]

Comment 23

[Joe Francis]

fix on trunk

Comment 24

[sujay]

tracy please verify on latest trunk build..thanks.

Comment 25

[Tracy Walker [:tracy]]

verified, this has been working on the trunk for about two weeks. (comment #13)
it is still functioning correctly in the latest builds

Comment 26

[Charles Manske]

*** Bug 112633 has been marked as a duplicate of this bug. ***