This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 224513 - color chooser don't take edited value
Summary: color chooser don't take edited value
Status: NEW
Alias: None
Product: web
Classification: Unclassified
Component: CSS Visual Tools (show other bugs)
Version: 7.3
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: Jan Stola
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-05 01:29 UTC by maxym
Modified: 2014-10-06 13:26 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description maxym 2013-01-05 01:29:26 UTC 
Color chooser always opens with the last edited color, instead of one for which it is opening.

for example we may have two styles:

.style1 {color: #111111}
.style2 {color: #222222}

After changing the color of style1 to, let's say, #333333, opening color chooser for style2 will result with #333333 set.

In short, color chooser always opens with the last edited color. Doesn't matter we are trying to pop-up the chooser just from css code or even using Rule selector.


Also might be good to improve support of color chooser while manually writing style,

(I will use | character as cursor position):

Example 1
.style1 {color: |#111111} 
if we call (CTRL+space) color chooser from this position and save new color we get sequence:
.style1 {color: #222222#111111} 

Example 2
.style1 {color: #|111111} 
No color popup appear

Currently, best solution (for both cases) is to select whole color, including hash character, before calling color chooser. 

with regards
Comment 1 Marek Fukala 2013-01-07 11:09:22 UTC 
Thank you for the report.

Unfortunately this is how the completion behaves now - it does take into account just the prefix, but not any postfix. AFAIK not overwriting any text after the caret (even if it matches the completed item).

From this perspective, it could  IMO be bit confusing to preset the color chooser color with the value of the text whose at least a part is after the caret.

I'll give it a try and play with the behaviour, in any case, this is enhancement, not a bug (at least in terms of the generic completion behaviour).
Comment 2 maxym 2013-01-07 20:32:24 UTC 
ok. in-line parser is one thing. Would be fine if fixed, but I will understand if current behaviour will remain.

But second one is initializing color chooser with specific color. Even if using rule editor, it's never set to just editing one. While editing the same a few styles trying to match colours, it is annoying to enter manually previous colour instead of changing it a bit only. From this perspective it might be considered as a bug ;) since it would be expected behaviour of color chooser.

with regards