Steps: 1) Open a blank or an existing document 2) Type new text and select text on document 3) Use the color picker to change the text color Actual Results: Color picker icon changes, but selected text stays the same color. Type more and new text does not change to the new color picked. Expected Results: Selected text color changes to new color as indicated by Color picker icon. This should work for both background and foreground.

Build Platform/Date: WinNT using 2000052208

I opened the Composer tabs bar and clicked on a few tabs. Surprisingly, the color did apply as expected but does not get reflected unless I click on these tabs. Since this Composer tab bar will be closed by default, we need the colors applying without requiring the end user to go into this tab mode.

assign to cmanske

The fact that the color appears correct after changing modes indicates that this is a layout bug, since changing modes forces a repaint.

Text color (upper left color button) seems to work fine. It's the background color that doesn't seem to work. But for both, I have to click 2 or 3 times before I event get the popup! Marc has dealt with the problem before (bug 11491), although I'm not sure if it's the same problem since now resizing the window doesn't trigger the repaint of background. Note that changing "edit modes" loads/unloads style sheets, which seems to trigger the background repaint. Setting background color seems to be a dogfood issue.

Putting on [nsbeta2+][6/15] radar.

I have been trying to duplicate this with my new build (pulled source this morning) and it is working fine. I do have some unrelated chagnes in my tree as well, so I'll try with a spanking-clean build and see what is up. It sure looks like a WORKSFORME... Unless I am doing it wrong. The steps seem simple enough though. This may be related to a fix I had to put in for a regression on background colors being set via the BGCOLOR attribute on the body. I just checked the fix in so if you are setting the background color like that then this is probably fixed. Might want to grab /mozilla/layout/html/base/src/nsFrameManager.cpp and try it, or just test it with tomorrow's build.

I just updated Marc's latest checkin and that fixes this.

almost fixed... color picker toolbar icon does not change to the new color unless you glide your mouse cursor over it...then it changes to the new color...

I don't think you want me trying to fix that! Back to Charles...

Updating the color swatch on the toolbar is a totally different issue. There are general problems with updating CSS styles and attributes in toolbars; probably belong to the XUL team, but they are CSS-driven, so Marc may not be totally off the hook!

Beppe thought this was a good task for Tony

I'd like to keep this bug. I'm sure I can find others to pass on to Tony! This is blocked now because we can't get the color of the text in the page at the selection. Removing all nsbeta2 keywords and status -- we'll tackle it for beta3.

m18 - nsbeta3+

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

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

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

changing priority.

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

I did not see this on today's builds windows & linux 2000-08-22-06-M18 no mac build yet

checked in 8/22. Just one small problem: Click cursor to locate caret in text ("collapsed selection") Select a differnt text color using colorpicker, but *dont type anything* (if you did, it would be in the new color, so color picker button color shows the new color correctly.) Instead, move caret using left arrow into previous text. The color button color should change to the color of that text, but it doesn't. I've discussed this with jfrancis and he thinks it's a bug in his code -- we'll follow up with a separate bug on him.

verified in 8/31 build.