Text only | Text with Images

ElkArte Community

Elk Development => Bug Reports => Exterminated Bugs => Topic started by: IchBin on September 04, 2013, 03:01:01 pm

Title: Quickedit
Post by: IchBin on 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.
Title: Re: Quickedit
Post by: FF / MFG on September 04, 2013, 03:04:41 pm
Let's see.

Works fine here (if you see that message) on Chrome 29 - Linux
Title: Re: Quickedit
Post by: IchBin on September 04, 2013, 04:02:57 pm
Nope, not working for me.
Win7 pro
Chrome Version 29.0.1547.66 m
Title: Re: Quickedit
Post by: Antechinus on September 04, 2013, 05:27:26 pm
Quote from: IchBin – 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.
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. :D
Title: Re: Quickedit
Post by: emanuele on September 04, 2013, 06:10:23 pm
Just use good browsers and not hype-based ones. :P
Title: Re: Quickedit
Post by: Spuds on September 04, 2013, 07:07:05 pm
Quoteclean up the markup coz Ant is stoopid
Someone DOES read my commits  :D
Title: Re: Quickedit
Post by: IchBin on September 05, 2013, 07:29:34 pm

Quote from: emanuele – Just use good browsers and not hype-based ones. :P
Chrome > all other browsers. You obviously don't know what you're talking about. ;)
Title: Re: Quickedit
Post by: Antechinus on September 12, 2013, 04:58:41 am
Quote from: Antechinus – 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. :D
AHA! Futhermuckerzzzzzzzzzzzzz!!!!!!! Who removed the space then? Itz gone innit. No wonder we haz bugz. :P

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

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.
Title: Re: Quickedit
Post by: Spuds on 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.
Title: Re: Quickedit
Post by: Antechinus on 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.
Title: Re: Quickedit
Post by: Arantor on September 12, 2013, 10:17:34 am
Why is this still a bug in current Firefox?
Title: Re: Quickedit
Post by: Spuds on 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.
Title: Re: Quickedit
Post by: Antechinus on September 12, 2013, 04:33:22 pm
Quote from: Spuds –
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. :D

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.
Title: Re: Quickedit
Post by: Arantor on September 12, 2013, 04:40:26 pm
Those code boxes don't behave in Chrome either, they overflow out of the main container.
Title: Re: Quickedit
Post by: Antechinus on 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.
Title: Re: Quickedit
Post by: TE on September 13, 2013, 12:57:32 am
Quote from: Antechinus – 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.
Nah, yust set the outer DIV to (The parent from "postarea" and ul with class "poster") the CSS property:
Code: [Select]
display: flex;

and it's fixed :P
 I'll send a PR for that issue later this day..
Title: Re: Quickedit
Post by: Antechinus on September 13, 2013, 01:07:36 am
Not supported in IE or Safari, so how can we use it? Have you checked those for overflow too (I haven't yet).
Title: Re: Quickedit
Post by: Nao on September 13, 2013, 01:24:10 am
Fixed that in Wedge yesterday for the blog homepage. ;)
This was also an important fix in SMF itself back in mid-2010. Something all table-based layout deva should be aware of. ^^
Title: Re: Quickedit
Post by: Antechinus on September 13, 2013, 05:01:12 pm
Quote from: Nao – Fixed that in Wedge yesterday for the blog homepage. ;)
Congratulations.

QuoteThis was also an important fix in SMF itself back in mid-2010.
Welcome to 2013. You'll love it.

QuoteSomething all table-based layout deva should be aware of. ^^
I have no idea what a "table-based layout deva" is supposed to be, or what they should or should not be aware of. Personally, I'm a carbon-based life form. Delighted to make your acquiantance.

Anyway, regarding this little buglet, what happened is that I changed the CSS to use display: table-cell; on .poster and .postarea instead of a float on .poster and a margin on .postarea. At the time I didn't check for overflowing code blocks, because I didn't see any reason why the change should result in a child element several levels down forcing an overflow. However, apparently it does.

If necessary, it can be fixed by just reverting to using the old float and margin, which is basically what 2.0.x did, but without so much redundant markup.
Title: Re: Quickedit
Post by: Nao on September 13, 2013, 05:18:06 pm
Quote from: Antechinus –
Quote from: Nao – Fixed that in Wedge yesterday for the blog homepage. ;)
Congratulations.

QuoteThis was also an important fix in SMF itself back in mid-2010.
Welcome to 2013. You'll love it.

QuoteSomething all table-based layout deva should be aware of. ^^
I have no idea what a "table-based layout deva" is supposed to be, or what they should or should not be aware of. Personally, I'm a carbon-based life form. Delighted to make your acquiantance.

Anyway, regarding this little buglet, what happened is that I changed the CSS to use display: table-cell; on .poster and .postarea instead of a float on .poster and a margin on .postarea. At the time I didn't check for overflowing code blocks, because I didn't see any reason why the change should result in a child element several levels down forcing an overflow. However, apparently it does.

If necessary, it can be fixed by just reverting to using the old float and margin, which is basically what 2.0.x did, but without so much redundant markup.
I meant dev not deva. Stupid autocorrect.
And the answer was...... table-layout: fixed.

You're welcome ;)
Title: Re: Quickedit
Post by: Antechinus on September 13, 2013, 05:57:23 pm
K, well that would be the important fix in SMF that doesn't appear anywhere in SMF's CSS then. :D

If you mean portal pages using it to deal with the side blocks, etc then I'd forgotten about that. I haven't used tables for that for years. You can do portals without table-based markup, as long as you aren't trying to support IE6 (and I'm not). Whenever I did a custom portal installation, I just re-wrote it to use divs.

I may still use a float anyway. The thing is that display: table hasn't been declared anywhere at the moment. That could be declared on the .windowbg2/ divs, but I didn't bother at the time because it was unnecessary bloat.

Problem is that when the layout is switched to the compact option (no poster area as such) I want to switch the display of .posterarea to block, because that's the best way of dealing with it. Mozilla doesn't behave properly when there is only one "table-cell".

As long as having table and fixed on the windowbg/2 divs doesn't screw anything else further down, with either layout option ,then that would be fine. If it turns out to be a chasing-your-tail scenario then just going back to a float may make more sense.
Title: Re: Quickedit
Post by: Bloc on September 13, 2013, 07:07:27 pm
When reading this I am reminded of why I started Protendo(and its predessors) in the first place.. ::)
Title: Re: Quickedit
Post by: Nao on September 14, 2013, 04:12:38 am
It just came back to me. That wasn't SMF. That was a fix we discussed at the time for your portal Bloc, isn't it..?
Title: Re: Quickedit
Post by: emanuele on March 18, 2014, 01:02:13 pm
Is the original fixed?
Title: Re: Quickedit
Post by: Spuds on March 18, 2014, 09:29:41 pm
@IchBin was having the problem, I think its been fixed but he would be the one to say for sure.
Title: Re: Quickedit
Post by: IchBin on March 20, 2014, 07:37:01 pm
Looks like it's working to me.!
Title: Re: Quickedit
Post by: emanuele on March 21, 2014, 03:46:01 am
Good! :D
Title: Re: Quickedit
Post by: Spuds on March 28, 2014, 01:29:54 pm
Just to note here (old strawhead just remembered) this was the expired cookie / chrome issue from BB that we had fixed in BB itself.
Text only | Text with Images