All users were logged out of Bugzilla on October 13th, 2018

Color picker not dynamically updating color selection icon

VERIFIED FIXED in mozilla1.2alpha

Status

()

P1
major
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: tracy, Assigned: dbaron)

Tracking

Trunk
mozilla1.2alpha
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
seen on commercial trunk builds:

windows 2002-08-19-04-trunk
linux 2002-08-29-05-trunk
mac os9 2002-08-19-03-trunk

-open composer
-type some text then highlight it.
-click on the color picker icon 
(notice the colors don't update 'til mouse over)
-in the color picker dialog select a color
(notice that the choice you just made is not shown in the color icon, however
the text field shows the updated value for the color, and the color is actually
selected)
-click "Okay"
the selected text is now the color chosen, but the color picker icon in the tool
bar is not updated
-mouse over the color picker icon and the colors change to what had been chosen.

Comment 1

16 years ago
I did the steps, and on MacOSX, it just takes about 3 seconds to update the color.
Odd, though.

Comment 2

16 years ago
--> cmanske
Assignee: syd → cmanske

Comment 3

16 years ago
Something very fundamental is messed up! There are no changes in ColorPicker that
could cause this. We set the background color on the "color swatch" in both the 
toolbar and in the colorpicker using this CSS:
setAttribute("style",("background-color:"+color));
where "color" is the HTML color string.
This problem also exists for the color swatches in the Table Properties and
Page Properties dialog (color shows only after a mouse-over.)

I see a slightly different version of the problem using the color-picker in
the prefs: Appearance -> Colors): the color values in for the colors are not
initialized. If you click on one and change the color, it then appears in the 
color button. But if you switch to a different prefs panel, then switch back,
the colors are no longer displayed on the 4 color buttons.

I'm not sure if this is a CSS or widget problem -- assigning to widgets first.
It occurs in both Modern and Classic themes.
Assignee: cmanske → jaggernaut
Component: Editor: Composer → XP Toolkit/Widgets
QA Contact: sujay → jrgm

Comment 4

16 years ago
I think the changes to attribute handling for bug 156971 are suspect.
Some more information:
Bring up the Composer ColorPicker by clicking on the toolbar button.
The Color swatch to the right of the color input field is a <spacer> element;
we set the "background-color" to the user's selected color by setting a "style"
attribute on this element. Note that if you click on the "Default" button,
the background color is set to "inherit" and the change shows up immediately.
The next color you click on in the colorpicker will display correctly.
But the next one after that will not. So when a color is already set, changing
it is not triggering the redraw of the spacer element.

I'm having trouble reproducing this on Linux.  I think I might have managed to
reproduce the problem mentioned in comment 4 about the change after using the
"Default" button once, but it might have just been because I didn't really click
the mouse, and I couldn't reproduce it again.

Comment 6

16 years ago
David: So every time you click on a color in the colorpicker, you see that 
color appear on the color swatch to the right of the input field?
I definitely don't see that on Windows.
Do you see the toolbar symptoms? Type some text, select some, change the color
using the colorpicker. Then move caret into the colored area by clicking in it
or with arrow keys. The text color should update in the toolbar swatch. I don't
see it do that until I move the mouse over it.

Note that I tried to backout to the file versions just before your patch to 
bug 156971, but the resulting build crashes during startup :(.
We did test the morning build from 8/16 and it doesn't show this bug, so I think
your changes are still the most suspicious!
Hmm.  I can see it in a release build, but I don't see it in my own tree.  I'll
diff my tree and see if there's anything I missed checking in...
It also could have something to do with the MOZ_SVG ifdef in
nsCSSFrameConstructor::AttributeChanged.
Created attachment 96100 [details] [diff] [review]
patch

This fixes it, although I'm not crazy about the patch.
Created attachment 96102 [details] [diff] [review]
alternative patch

I might like this one better.  (I'm not really sure, though.)
Comment on attachment 96102 [details] [diff] [review]
alternative patch

r=bbaetz. This patch better reflects whats actually happening
Attachment #96102 - Flags: review+
Taking.
Assignee: jaggernaut → dbaron
Component: XP Toolkit/Widgets → Style System
Priority: -- → P1
QA Contact: jrgm → ian
Target Milestone: --- → mozilla1.2alpha

Comment 13

16 years ago
"alternative patch" tested for all cases described above and it works fine.
If one of you wants to explain what was the problem or why the patch fixes it,
that would be appreciated. :)
The problem was that I was testing using an SVG-enabled build, and there was
that little MOZ_SVG ifdef that made sure we always knew the style attribute
affected style.  That needs to happen for XUL too.  (We don't use the
AttributeAffectsStyle optimization for HTML, so HTML is OK.)
Comment on attachment 96102 [details] [diff] [review]
alternative patch

sr=bryner
Attachment #96102 - Flags: superreview+
Fix checked in, 2002-08-21 17:01 PDT.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 17

16 years ago
verified fixed as seen on commercial trunk builds:

windows 2002-08-23-04-trunk
linux 2002-08-23-05-trunk
mac os9 2002-08-23-03-trunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.