Quickedit

Quickedit Started by IchBin · September 04, 2013, 03:01:01 pm · Read 16195 times 0 Members and 2 Guests are viewing this topic. previous topic - next topic

Quickedit

September 04, 2013, 03:01:01 pm

Is quickedit working for you guys in Chrome? It shows the message at the top of the page when I click to quick edit, but it's not opening the post up for edit for me.

I also noticed in the editor, that the cursor and text line can get partially covered when typing and it goes behind the height/width adjustment bar on the textarea.

Re: Quickedit

Reply #1 – September 04, 2013, 03:04:41 pm

Let's see.

Works fine here (if you see that message) on Chrome 29 - Linux

Re: Quickedit

Reply #2 – September 04, 2013, 04:02:57 pm

Nope, not working for me.
Win7 pro
Chrome Version 29.0.1547.66 m

Re: Quickedit

Reply #3 – September 04, 2013, 05:27:26 pm

Quote from: IchBin – September 04, 2013, 03:01:01 pmI also noticed in the editor, that the cursor and text line can get partially covered when typing and it goes behind the height/width adjustment bar on the textarea.

I'm getting that on FF too. Haven't tried Chrome lately. I know there was a bug with the editor in FF before, in that it needed a wotsit (can't remember what) before the closing tag for the editor or else it got this same bug. IIRC, it needed a space before the textarea closing tag. If someone removed that to helpfully "clean up the markup coz Ant is stoopid" this would explain why we now haz hidden content.

Re: Quickedit

Reply #4 – September 04, 2013, 06:10:23 pm

Just use good browsers and not hype-based ones.

Re: Quickedit

Reply #5 – September 04, 2013, 07:07:05 pm

Quoteclean up the markup coz Ant is stoopid

Someone DOES read my commits

Re: Quickedit

Reply #6 – September 05, 2013, 07:29:34 pm

Quote from: emanuele – September 04, 2013, 06:10:23 pmJust use good browsers and not hype-based ones.

Chrome > all other browsers. You obviously don't know what you're talking about.

Re: Quickedit

Reply #7 – September 12, 2013, 04:58:41 am

Quote from: Antechinus – September 04, 2013, 05:27:26 pmIIRC, it needed a space before the textarea closing tag. If someone removed that to helpfully "clean up the markup coz Ant is stoopid" this would explain why we now haz hidden content.

AHA! Futhermuckerzzzzzzzzzzzzz!!!!!!! Who removed the space then? Itz gone innit. No wonder we haz bugz.

I'm gonna put it back in, with notez. In bold.

To be clear, this bit in GenericControls.template.php:

Code: [Select]

function template_control_richedit($editor_id, $smileyContainer = null, $bbcContainer = null)
{
	global $context, $settings, $options;

	$editor_context = &$context['controls']['richedit'][$editor_id];

	echo '
		<textarea class="editor" name="', $editor_id, '" id="', $editor_id, '" cols="600" onselect="storeCaret(this);" onclick="storeCaret(this);" onkeyup="storeCaret(this);" onchange="storeCaret(this);" tabindex="', $context['tabindex']++, '" style="width:', $editor_context['width'], '; height: ', $editor_context['height'], '; ', isset($context['post_error']['no_message']) || isset($context['post_error']['long_message']) ? 'border: 1px solid red;' : '', '" required="required">', $editor_context['value'], '</textarea>

Has to be like this to stop this bug in FF:

Code: [Select]

function template_control_richedit($editor_id, $smileyContainer = null, $bbcContainer = null)
{
	global $context, $settings, $options;

	$editor_context = &$context['controls']['richedit'][$editor_id];

	echo '
		<textarea class="editor" name="', $editor_id, '" id="', $editor_id, '" cols="600" onselect="storeCaret(this);" onclick="storeCaret(this);" onkeyup="storeCaret(this);" onchange="storeCaret(this);" tabindex="', $context['tabindex']++, '" style="width:', $editor_context['width'], '; height: ', $editor_context['height'], '; ', isset($context['post_error']['no_message']) || isset($context['post_error']['long_message']) ? 'border: 1px solid red;' : '', '" required="required">', $editor_context['value'], ' </textarea>

Yes, I know it's a trivial and stupid change, but it works. There ya go.

However, this leads to another question. Why are $editor_context['width'] and $editor_context['height'] still present? I was sure we killed those ages ago. I'm 90%+ sure they were even killed in SMF 2.1 Alpha, let alone Elk.

These settings are remnants from IE4 days, when no browser supported CSS. If we can't do this without them, we aint trying.

Re: Quickedit

Reply #8 – September 12, 2013, 07:43:45 am

Maybe $editor_context['value'] should be checked and if empty initialized to a space, with a comment about why, might be easier to see in the future.

The width/height are passed in the editors initialization object to allow it to be set as needed / desired.

Re: Quickedit

Reply #9 – September 12, 2013, 09:04:33 am

But the problem is that you need the space even if the editor is NOT empty. That's what allows the overflow to work properly with FF. Remove the space and it's borked.

And sure, we need to set height and width for the js. My point there is that these should just be numerical values, not back end PHP weirdness. The editor is probably just going to be full wdth in whatever wrapper element, and height can be set to any old thing (within reason). I can't see that we need to drag $context into it at all.

Re: Quickedit

Reply #10 – September 12, 2013, 10:17:34 am

Why is this still a bug in current Firefox?

Re: Quickedit

Reply #11 – September 12, 2013, 11:45:22 am

QuoteBut the problem is that you need the space even if the editor is NOT empty. That's what allows the overflow to work properly with FF. Remove the space and it's borked.

Well thats even easier to do ... just add a space, don't bother to check.

QuoteWhy is this still a bug in current Firefox?

Good question, not sure what version of FF has this issue, or if its really a bug of the editor itself.

QuoteAnd sure, we need to set height and width for the js. My point there is that these should just be numerical values, not back end PHP weirdness. The editor is probably just going to be full wdth in whatever wrapper element, and height can be set to any old thing (within reason). I can't see that we need to drag $context into it at all.

Sure I suppose you can set those values in the css (I think they are all 250px high and 100% wide) ... just have to make sure that those values will be overwritten with the editor object so addon folks can size it to what they may want without having to make css adds/changes.. I suppose the editor, if not passed any width/height values, will inherit them from the textbox it grabs.

Re: Quickedit

Reply #12 – September 12, 2013, 04:33:22 pm

Quote from: Spuds – September 12, 2013, 11:45:22 am
QuoteBut the problem is that you need the space even if the editor is NOT empty. That's what allows the overflow to work properly with FF. Remove the space and it's borked.
Well thats even easier to do ... just add a space, don't bother to check.

I did. Somebody removed it.

On another note, I'm having trouble getting the code boxes to behave with FF. Had a go at them last night. Will try some other tricks.

Re: Quickedit

Reply #13 – September 12, 2013, 04:40:26 pm

Those code boxes don't behave in Chrome either, they overflow out of the main container.

Re: Quickedit

Reply #14 – September 12, 2013, 04:48:07 pm

Doesn't surprise me. I have a suspicion that it's due to display: table-cell; not behaving properly when the contents of a child element have nowrap. May have to go back to using floats on the template.