[regression] Dijits in dijit.TooltipDialog not rendering correctly on first display

[Luis Montes]

If I embed a ColorPalette into a TooltipDialog attached to a DropDownButton, the ColorPalette will not display correctly or return a value the first time it's rendered and clicked.

Other types of content (such as a div of dijit buttons) inside of TooltipDialogs do not display the same the second time they display either.

This worked fine in 1.5: ​http://jsfiddle.net/monteslu/vmVwe/

This is broken in 1.6: ​http://azprogrammer.com/examples/palette1.6.html

I've tried in the FF 3.6.14, IE8, and Chrome 9

[bill]

Are you talking about the misalignment between the color swatches and the boxes around them?

Probably it's that you need to include claro.css and dojo.css before dojo.js, so that the CSS loads before we start rendering. Try that and write back here if that fixes your issue or not, thanks.

[Luis Montes]

I've updated my 1.6 example to laod the css first. Still broken

It's worse than just the mis-aligment, this bug changes the way colorPalette works, It will fire an onChange when a color is selected, but give null value the first time through.

I've also added a line of console logging to both the 1.5 and 1.6 examples to demonstrate this.

[bill]

I see, OK thanks you are right, it is something weird about the TooltipDialog, although the version in the editor works (for foreground/background color).

And I see the null onChange too. I'll look into it.

[bill]

About onChange(), onChange(val) is working fine assuming you use the value parameter passed to the onChange callback, ex:

dojo.connect(cp,'onChange',function(val){
	console.log("selected color",val);
});

However, due to a bug in [23191], cp.value isn't updated until after the onChange() callback fires, which is why your test file isn't working. I'll fix that.

[bill]

(In [23971]) Set this.value before calling onChange(), in case onChange handler references this.value. Fixes a regression from 1.5. Checking into trunk/ and 1.6/ branch.

Refs #12386 !strict.

[bill]

(In [23979]) In non-high-contrast mode, use background-color CSS for color swatches, rather than an image. In high-contrast mode, make each color swatch contain an <img> node that loads the entire palette image, but scrolls/clips it to only show the color for that swatch.

This change avoids swatch/border alignment issues on webkit with a zoom setting, and alignment issues in other browsers, even when not zoomed, that started in 1.6, as seen in #12386.

Note that webkit never enters high contrast mode; even when the machine is set to high-contrast mode, the browser still displays background images. So webkit will always using background-color CSS.

Fixes #3919, #10959, #12386 in trunk/ and 1.6/ branch, !strict.