EASY FIX for IES bug in Post Editor textarea

Started by Jscripts, August 23, 2010, 11:50:33 PM

Previous topic - Next topic

Jscripts

I can't work out how to post in BugTracker... so this is to tell you all that I have created a REALLY simple solution that seems to work great.

Problem - in IE8 the cursor position jumps all over the place once the contents of the post editor's textarea exceeds what will fit without dispaying scrollbars.

Cause - The IE8 textarea bug is caused when you set the width= (style) attribute to be wider than the COLS= attribute in HTML. This is made HEAPS worse in SMF by that little 'storeCaret(this)' thingy that is called on various onChange events (try removing that code and you will see what I mean).

Previous fix attempts - Setting a fixed width is yucky, and min-width / max-width cludges don't work reliably... I also saw some pretty convoluted workarounds and hacks here on the boards and in the bugtracker. None work properly, many broke after a minor IE8 patch was released by M$.

Also see BugTrack http://dev.simplemachines.org/mantis/view.php?id=3354 and other thread http://www.simplemachines.org/community/index.php?topic=388767.0

SOLUTION - The simple solution is to set COLS to a bigger size than what IE will eventually calculate the "width" (of the textarea object) to be. Since the posting Editor is inside a DIV anyway, this should not affect the layout, and because it is pretty much straight HTML this should also degrade gracefully...

GenericControls.template.php - Search for <textarea class="editor" and CHANGE...

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


TO...

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



In other words...

cols="', $editor_context['columns'], '"  TO  cols="6000"

Note - I have not yet checked what happens in other Browsers. Nor have I checked any other Editor modes... just the main editor box. Not sure if it requires detection and conditional insertion based on the Browser Detection routine, I just made this quick and dirty hard-coded solution to make my own  forum functional.

Sorry for the somewhat incomplete answer here... I only installed SMF2.0 yesterday, haven't even opened the forum yet!  This is my first look at the next SMF2 code :o

Because I am inexperienced with the new SMF2, I though the easiest thing was to post what I have found so far, and let the experts develop the proper fix from here. Please test it and post back your ideas!

J

Jscripts

OK - I have tested some more... I tested first with Windows7 64bit with IE8, and it works great.

My solution also works perfectly on XP 32bit in IE8, FF3.6.6 and Chrome 5.0.375.126

What else has to be tested?

Oya

this would break some mods btw where they set the size of the editor itself

Linda.V

Oké, thanks, I will also change that code because we have the same problem  ;)

Antechinus

Cool. Thanks for the heads up. Noted for more extensive testing. :)
Sources code: making easy front end changes difficult since 1873 :P

Mods & Themes | Revamped theme for this site | Dark theme for this site | GitHub for n00bz

InsaneMustang


Dynam0

Is possile to apply this fix in previous versions? (like 1.1.12).

Thanks.

Antechinus

Yes it should work in textareas for 1.1.12, although I haven't tried it yet. There would be several templates to edit.
Sources code: making easy front end changes difficult since 1873 :P

Mods & Themes | Revamped theme for this site | Dark theme for this site | GitHub for n00bz

Dynam0

Quote from: Antechinus on December 12, 2010, 06:43:59 PM
Yes it should work in textareas for 1.1.12, although I haven't tried it yet. There would be several templates to edit.

Dude, can you tell what files i need to change?  Im a newbie, help me please.

Thanks.

joe90

If this works so well can we have it included in the next upgrades to 1.1.12 and 2.0 RC4
This problem is a major bug for all users it would be good to take it out
SMF: 1.1.17
Simpleportal:

Spuds


Antechinus

There are actually two different fixes for different textareas. We wanted to try both to check their effectiveness. So far we haven't had any feedback from the beta testers so we have to assume both are working.
Sources code: making easy front end changes difficult since 1873 :P

Mods & Themes | Revamped theme for this site | Dark theme for this site | GitHub for n00bz

Arantor

No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

Antechinus

Well, I was trying to avoid making that assumption as I would have hoped someone had tried RC4 with IE8.
Sources code: making easy front end changes difficult since 1873 :P

Mods & Themes | Revamped theme for this site | Dark theme for this site | GitHub for n00bz

Arantor

Well, it's a fair bet to say that it hasn't been properly tested otherwise you wouldn't have to be guessing.

That's the thing about beta testers having access to things ahead of time, they should be able to test so that come release day you shouldn't have such gotchas. If a change was made to this in time for RC4, it should have been tested by someone (anyone, dev or beta tester) prior to RC4's deployment, but the very fact you haven't had any beta testers commenting on it either means 1) they didn't bother to test it, or 2) they didn't bother to tell you, which to me doesn't sound like very good beta testing, since really, the job of a beta tester is not only to find and report new ones, but also confirm that existing bugs have been squished once the devs think they've done so.

At least, that's how we did it at the company I used to work for, and post-release issues were understandably at a minimum.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

Antechinus

Sources code: making easy front end changes difficult since 1873 :P

Mods & Themes | Revamped theme for this site | Dark theme for this site | GitHub for n00bz

Arantor

The failure with RC4's very initial launch is another example; the changes to Manage Posts without anyone testing it prior to deployment... it just meant you got some eager users upgrading, only to find a fatal error hit them in execution. It wasn't like it was an intermittent fault that came and went, it was demonstratable, repeatable and it's the sort of reason you have beta testers - to test for stuff like that.
No good deed goes unpunished / All helpful urges should be circumvented

I have something to say: it's better to burn out than to fade away. There can be only one.

searchgr


Illori

i believe this has been solved in the 2.0 release

Advertisement: