maybe bug 105740?

(In reply to Cor Nouws from comment #1)
> maybe bug 105740?

Nope, I checked (an verified with latest daily). This one is about the initial state when opening the arena dialog for an empty document. A blue background color is preset as "NEW", but not selected in the color picker.

The colour is not preselected as someone thought it would be a brilliant idea and improved UX when standard colour aka Tango Blue aka #729FCF was removed from standard colour palette 

It has moved to 'tango' pallete, which would then have to become standard

(In reply to Katarina Behrens (CIB) from comment #3)
> The colour is not preselected as someone thought it would be a brilliant
> idea and improved UX when standard colour aka Tango Blue aka #729FCF was
> removed from standard colour palette 

I think that is more a mistake, something that has been overseen.

Light Blue 3 (#7DA7D8) of the current default color palette can be used instead of #729FCF. Seems to be the most similar color of the palette.

And Blue (#0066B3) instead of #3465A4 for the line color.

The default blue area fill or stroke/border colors dont need to be part of the default palette in my view, so no this wasnt a mistake when we changed the standard palette.

For me it looks better and consistent when all default colors are part of the standard palette. Same as text highlight and font color.

(In reply to Thomas Lendo from comment #8)
> For me it looks better and consistent when all default colors are part of
> the standard palette. Same as text highlight and font color.

I agree. And in fact, for users friendliness, older default fill colors should be in there too (After all, we don't change that so often :)  )

works fine in Version: 6.3.0.0.alpha0+
Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b
CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35
Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US
Calc: threaded

Cor, I can reproduce this issue with

Version: 6.3.0.0.alpha0+
Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35
Locale: de-DE (de_DE.UTF-8); UI-Language: en-US
Calc: threaded

"blue color isn't pre-selected in the color palette" means that there is no selection border in the palette on the left half of the Area color tab although the blue color is really selected (if you click OK the page will be blue colored and the blue color is previewed in the "New" column at the right of the Area color tab.

Going to dupe this to bug 108670, issues are the same. 

Opening the Area -> Color panel arriving from another Area type, especially default 'None' mode, opens the Active Color with no actual assigned color--and incorrect indicator of what would be assigned.

The GUI shows a Black (#ffffff) swatch, but with default 114, 159, 207 RGB values for #729fcf Area fill (Old Tango: Sky Blue 1, now Light Blue 2 on Standard palette).

Once the New color #729fcf, or another pick from pallet or custom pick made, is applied--the GUI will refresh. If pick is made from Standard palette or swittched to and made from another installed pallet--the indicator on the palette swatches will show the pick.

Until a pick is made and applied the color Swatch is wrong, while the lack of an swatch indicator on the pallet GUI--could be seen as correct, no Color has been selected/applied yet--but would be more consistent UI to show what would be applied.

Work on bug 108670 should resolve this with a better null color assignment, tweaking the UI to either symbolize the null area fill.

*** This bug has been marked as a duplicate of bug 108670 ***