queryCommandValue + hiliteColor

[emorvill]

A queryCommandValue with a hiliteColor doesn't work.

In dijit._editor.plugins.TextColor?, if you overwrite the method updateState like this :

updateState: function(){
	var _e = this.editor;
	var _c = this.command;
	if(!_e || !_e.isLoaded || !_c.length){ return; }
	if(this.button){
		var value;
		try{
			value = _e.queryCommandValue(_c);
		}catch(e){
			console.error(e);
		}
		console.warn("Update State ::: ", _c, " : ", value);
	}
}

value is always equals to "transparent".

[Adam Peller]

does this happen for all browsers and all test cases?

[bill]

I'm unclear what the actual bug (or ramifications of the bug) are. That the hilite-color and background-color buttons don't reflect the current state of the text where the caret is?

See also #5829.

[emorvill]

Hi,

I made a test : ​http://volantis.ccett.fr/test_hilitecolor/dijit/tests/test_Editor.html

Firefox 3.x :

• The hiliteColor always returns the value transparent

• The foreColor works and returns an hexadecimal value.

IE 6/7/8 :

• The hiliteColor works and returns an Integer value.

• The foreColor works and returns an Integer value.

Safari 4 /Chrome :

• The hiliteColor works and returns a rgb/rgba value (rgb(135,41,41) for example)

• The foreColor works and returns a rgb/rgba value (rgb(135,41,41) for example)

I think that the bug is on Firefox for hiliteColor command. (It seems impossible to get the right value). May be it will be easier to always returns an hexadecimal value in all browsers ?

[emorvill]

Test for hilite color

[emorvill]

if ​http://volantis.ccett.fr doesn't work you can test on ​http://volantis.rec.orange.fr/test_hilitecolor/dijit/tests/test_Editor.html

[emorvill]

Patch hiliteColor

[emorvill]

The problem is when useCSS is set to false after the execCommand. With the patch, I get the right value on Firefox.

[Jared Jurkiewicz]

I'm not sure that patch is appropriate, as it is going to change a lot of default behavior. In other words, the styling of all elements is going to change. That may have far-reaching effects to other actions.

[Jared Jurkiewicz]

I'm assuming that updateState method is yours, if so, then why not just implement it like:

updateState: function(){
	var _e = this.editor;
	var _c = this.command;
	if(!_e || !_e.isLoaded || !_c.length){ return; }
	if(this.button){
		var value;
		try{
                        if(dojo.isMoz){
                           e.execCommand("styleWithCSS", false, true);
      			   value = _e.queryCommandValue(_c);
                           e.execCommand("styleWithCSS", false, false);
                        }else{
                           value = _e.queryCommandValue(_c);
                        }
		}catch(e){
			console.error(e);
		}
		console.warn("Update State ::: ", _c, " : ", value);
	}
}

That avoids having to change the default editor behavior (been around for years), for something you desire to over-ride.

[Jared Jurkiewicz]

Updated over-ride that works with current editor.

[emorvill]

Hi,

It works with this code :

updateState: function(){
	var _e = this.editor;
	var _c = this.command;
	if(!_e || !_e.isLoaded || !_c.length){ return; }
	if(this.button){
		var value;
		try{
                        if(dojo.isMoz){
                          _e.document.execCommand("styleWithCSS", false, true);
      			   value = _e.queryCommandValue(_c);
                          _e.document.execCommand("styleWithCSS", false, false);
                        }else{
                           value = _e.queryCommandValue(_c);
                        }
		}catch(e){
			console.error(e);
		}
		console.warn("Update State ::: ", _c, " : ", value);
	}
}

I think that the queryCommandValue has to work fine without specific code. Maybe, the problem could be resolved in a future version ? I let you decide ;) Thanks for your support

[Jared Jurkiewicz]

I added a testcase that alters your over-ride and gets it to work without making any changes to RichText?.js. I'm loathe to change the editor from named tags to CSS styling in 1.X, as it has been the normal editor behavior for years.

Bill, Liu,

Any opinions here? I can change editor over to do styleWithCSS true, but it alters a long-standing behavior. I'm worried what impact such a change might have.

[Jared Jurkiewicz]

Another possible patch that solves it without altering the default value the editor is using for styleWithCSS

[Jared Jurkiewicz]

(In [20573]) Minor tweak to get this to function on Moz based browers. \!strict fixes #10096

[bill]

Yah, I don't see any reason to change the editor's behavior in general. I'm sure it's a religious issue that some people feel <b> and <strong> are evil but I don't really care.

I would like to have editor output be consistent across browsers but we can do that with pre/post filters (both DOM based and regex based) so I don't see a pressing need to alter the representation of styles while the document is being edited.

[Jared Jurkiewicz]

(In [20612]) Used wrong varname, fixed some tabs/spaces mixing. \!strict refs #10096