[3354][IE8] Problems with text box scroller/cursor moving.

Started by Adam112, May 08, 2009, 09:46:18 PM

Previous topic - Next topic

Norv

Thank you very much for the feedback!
Apparently another attribute works now, for newer IE8 versions...
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

Jscripts

Hi all, I am new here and not sure how to get my solution noticed by the correct part of dev team?

The problem of the Post Reply textarea jumping all over the place once the text content is big enough to need scrollbars...

Bugtracker item is here:
http://dev.simplemachines.org/mantis/view.php?id=3354

Please refer to my thread here, for details of a really simple fix:
http://www.simplemachines.org/community/index.php?topic=397316.0

EDIT - I just found the thread http://www.simplemachines.org/community/index.php?topic=309186.80
- Mods, please merge / move / whatever

Jscripts

Hi all, I am new here and not sure how to get my solution noticed by the correct part of dev team?

Bugtracker item is here:
http://dev.simplemachines.org/mantis/view.php?id=3354

Please refer to my thread here, for details of a really simple fix:
http://www.simplemachines.org/community/index.php?topic=397316.0

Seems to work in all browsers, no special kludges required  ;D

Norv

Hello there, and welcome to SMF!
Thank you for the interest and for sharing your solution. :)

It feels a bit hacky ;), but it appears to work.

On another note, answering your other topic, the Bug Tracker is read only for community members. Testers and SMF team members or former team members can post into it. This board however is fully dedicated to issues discussions, reports, solutions, and open to everyone.
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

Oya

except anything that calls for its own size of editor widget wont work :( will break on my site then

Jscripts

Quote from: Oya on August 24, 2010, 02:10:07 PM
except anything that calls for its own size of editor widget wont work :( will break on my site then

Not sure how that would break anything - the Style still controls the resultant size - you can change that with hard-coding or with JS after the page has loaded.

So, if you want 300px wide textarea, you can still set the style's width to that, or use a percentage - if it's a mod then you are the one who's coding the numbers, so you can set it however you wish! The COLS attribute is supposed to be lower in the "pecking order" than the style! Remember, the original command is "66 COLS" then over-ride that with width:100%... instead, all we are doing is telling it to ignore COLS=6000 instead of ignoring COLS=60  ;)

The solution is simply to ensure that your style width=percentage command is resizing the textarea smaller, and never larger  ???

What I had originally considered was to detect the width of the textarea's parent element using a small script, and then after the page had loaded to use JS to dynamically resize the textarea to an absolute number. But the hassle then is handling the window.onResize event... would have to have a listener there to resize the textarea each time the width of the page was altered by the user.

There's enough stuff going on in the background anyway with the onClick etc... it doesn't need any more event-driven JS running!

By the way - the majority of the "cursor jumping" problem is being caused by those event listeners for what gets typed into the editor box. I haven't checked the *.js files - but I assume that those are attempting to track the position of the cursor or something? Try it - if you disable those, the textarea operates reasonably "normally" in IE8. Whilst there is a minor IE bug, it's the strange 'storeCaret(this)' function which is actually making the bug cause the strange behaviour.

Oya

i dont think you understand

when the editor is created with control_create_richedit one of the parameters is width which cannot be set using your method

and by the way the majority of the cursor jumping isnt the event listeners since it happens outside the wysiwyg editor as it happened in 1.1.10 and the ie7 compatibility tag was added its an ie8 bug with textboxes that arent a fixed but percentage width since plenty of other systems had the same problem

Jscripts

Hi Oya

I understand perfectly, but I only installed the new forum a few days ago so I am not conversant with the new code. I have other boards running 1.1.9, but this is my first 2.0.

Quotewhen the editor is created with control_create_richedit one of the parameters is width which cannot be set using your method

It is totally irrelevant "how" the editor gets created... the modification is hard-coded into section of the script that actually creates the final HTML. You can call the function with whatever width you like - it still gets set by whatever parameter is passed by $editorOptions['width']. So, if you call it with width=20%, the editor will still get created at 20%. If you call it with width=300px, then the editor will get created with 300px wide.

From your comments, I am guessing that (unlike Norv) you haven't actually tried my solution, have you?  ;)

-----

Anyway, I have found that the cludge is not perfect, so I am coding a Javascript solution instead.

What this does is detects IE8 then converts any existing style width from a percentage to absolute pixels, and also resizes the message textarea upon a window resize event.

My test page is working beautifully now, and means that no existing code needs to be altered (it's an add-on script, will use PHP to insert the script tag conditionally if IE8 is detected)

I was trying NOT to do this in JS, but I've found that my previous "HTML solution" is definitely an improvement on the esiting SMF code but is not 100% reliable in all cases.

Back soon with a demo, once I get the JS tweaked.

Oya

i didnt try it because it would break some of the stuff on my site like i said

Jscripts

LOL - how could it break something on your site, but not on mine or anybody elses? But anyway...

My Javascript fix is completed and works great. It's a one liner for a *.JS call, which load a script that detects if the browser is IE8. If so then it dynamically changes any % style to a px style for the editor width. Works on load and on window resize.

You'll have to upload a remote *.JS file somewhere for it to run from, but that has the advantage that the fix is easier modified than hard-coding inside the PHP if we need to tweak it later. The original PHP will work as-is, as will any parameters passed to the PHP (irrespective of how or where or when) - it runs AFTER the textarea is created.

I've gotta go to the office for a while, so will be back in about 8 hours with a demo. I suppose we'll need to find somebody to test it who is actually prepared to install the code to try it  :o  ;D

GRRR - I've just realised that it has to detect both max-width as well as width, since there are a couple of variants of PHP out there in the wild. Could somebody please clarify that for me... my version used the max-width and min-width (but not width), what else is there?

If somebody can help me to understand where else and HOW that editor box gets created, I can test all the various options. Right now I am just using document.getElementById("message") - is that the only way that the editor box is "named"?

Cheers, J

Oya

because like i said i actually use that parameter for a mod i made! that means on my site your hack will change what my site does

the code is added in genericcontrols.template

Norv

Quote from: Jscripts on August 27, 2010, 12:00:55 AM
My Javascript fix is completed and works great. It's a one liner for a *.JS call, which load a script that detects if the browser is IE8. If so then it dynamically changes any % style to a px style for the editor width. Works on load and on window resize.

It may be useful to take a look at Themes/default/scripts/script.js, it defines is_ie8. Also, in GenericControls.php, $context['browser'] is populated, like for example $context['browser']['is_ie8'].
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

Jscripts

Quote from: Oya on August 27, 2010, 03:14:55 AM
because like i said i actually use that parameter for a mod i made! that means on my site your hack will change what my site does

the code is added in genericcontrols.template

Yes, I realise that - however the both mods that I have made (both the simple one already posted, and the new code I'm creating), allow infinite changes to the width parameter, inside genericcontrols.template. You can set that width to anything you like (either percentage or pixels) and the value is still passed on and works perfectly.

I've tested it extensively... I know it works because neither of my changes makes any alteration whatsoever to the existing SMF code - they simply correct the results of the IE8 bug. If you are so concerned about this and running a hack - what is it? If you were specific, then I can check for you (since you are not prepared to do so).

Jscripts

Quote from: Norv on August 27, 2010, 11:04:56 AM
Quote from: Jscripts on August 27, 2010, 12:00:55 AM
My Javascript fix is completed and works great. It's a one liner for a *.JS call, which load a script that detects if the browser is IE8. If so then it dynamically changes any % style to a px style for the editor width. Works on load and on window resize.

It may be useful to take a look at Themes/default/scripts/script.js, it defines is_ie8. Also, in GenericControls.php, $context['browser'] is populated, like for example $context['browser']['is_ie8'].

Thanks Norv. I have the code working perfectly, using JS detection because that was it can be tweaked later if there is a M$ fix.

My main difficultly is that I am not conversant with SMF 2 code, so I don't know where else this editor box is having "the problem".

Is it just the main (post reply) editor when it's running in "non-WYSIWIG" mode? Are there other instances of textareas within SMF that exhibit the same jumping problem?

I've been caught up on another project the past few days... will get back to documenting my mod over the weekend. I'm curently testing it on my new forum anyway.

Oya

QuoteI've tested it extensively... I know it works because neither of my changes makes any alteration whatsoever to the existing SMF code - they simply correct the results of the IE8 bug. If you are so concerned about this and running a hack - what is it? If you were specific, then I can check for you (since you are not prepared to do so).

in my mod i pass a width value to the control-create-richedit when it is created maxing it at 50% which as far as i can tell wont work with your hack

QuoteIs it just the main (post reply) editor when it's running in "non-WYSIWIG" mode? Are there other instances of textareas within SMF that exhibit the same jumping problem?

quick reply box which isnt wysiwyg is also affected in most cases and potentially and oversize large_text edit boxes in the admin panel (which will be mod only)

Jscripts

Quotequick reply box which isnt wysiwyg is also affected in most cases and potentially and oversize large_text edit boxes in the admin panel (which will be mod only)

Thanks - I'll take a look at those and change the new script to fix those as well.

There is no point making a fix that only solves one instance of the textarea problem. I suppose I could create a loop and run through EVERY textarea on every page, but I'd prefer to only address those textareas that speciifcally have the problem. Therefore, I must refer to a specific Object (I am testing with "message", which is the non-WYSIWYG main editor).

My difficulty isn't with solving the problem, but rather because I only installed SMF2 a few days ago. So I don't even know where the problem occurs... it annoyed the hell out of me in SMF1.x, but honestly thought that such an annoying (yet easily-fixed) problem would be resolved in a brand new (pre)release!  :o

Oya

the problem is actually ie8 not actually an smf bug exactly

more accurately its a bug in ie8 that smf actually put a workaround in 1.1.11 for and that the pre releases of 2.0 havent fixed yet

Jscripts

Quote from: Oya on September 02, 2010, 04:59:02 PM
in my mod i pass a width value to the control-create-richedit when it is created maxing it at 50% which as far as i can tell wont work with your hack

OK, I see that I need to explain the fix more clearly...

This is the code at the very beginning of the "standard" SMF function template_control_richedit, which is inside GenericControls.template.php

I have edited the PHP for readabilty, but not changed the content

<textarea class="editor" name="', $editor_id, '" id="', $editor_id, '" rows="', $editor_context['rows'], '"
cols="60" 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>


This code sets the Style's "width" conditionally, depending if  it is IE8 or not... here is is again, edited a bit more to make it clearer:

style="', $context['browser']['is_ie8']
? 'max-width: ' . $editor_context['width'] . '; min-width: ' . $editor_context['width']
: 'width: ' . $editor_context['width'],


Whatever value that is stored inside $editor_context['width'] is passed through to the HTML in this way:
- if it's IE8, it sets max-width and min-width
- otherwise it sets width.

OK, now stay with me here... my code DOESN'T change any of that!

If you leave $editor_context['width'] as 100% (the default), then the resultant  HTML will read:

<textarea class="editor" name="message" id="message" rows="12" cols="60"
onselect="storeCaret(this);" onclick="storeCaret(this);" onkeyup="storeCaret(this);"
onchange="storeCaret(this);" tabindex="2"
style="max-width: 100%; min-width: 100%; height: 175px;">


To the Browser, this says:
"Create a TEXTAREA that is 60 COLumnS wide
... and then forget about that, and use CSS styles to size it to 100% of the parent (DIV)"


However, if you customise your SMF and set the value inside $editor_context['width'] to 50%, then the resultant HTML will read:

<textarea class="editor" name="message" id="message" rows="12" cols="60"
onselect="storeCaret(this);" onclick="storeCaret(this);" onkeyup="storeCaret(this);"
onchange="storeCaret(this);" tabindex="2"
style="max-width: 50%; min-width: 50%; height: 175px;">


To the Browser, this says:
"Create a TEXTAREA that is 60 COLumnS wide
... and then forget about that, and use CSS styles to size it to 50% of the parent (DIV)"


See the difference? OK, now my original fix doesn't alter any of that, except to tell the browser to:

"Create a TEXTAREA that is 6000 COLumnS wide
... and then forget about that, and use CSS styles to size it to (whatever)% of the parent (DIV)"


Can you see it? All this does is tell the browser a different number of columns THAT IT MUST IGNORE
- so, instead of ignoring COLS=60, instead it must ignore COLS=6000

The actual style still gets set to whatever is stored inside $editor_context['width'] - whether that is 100%, 50%, or 40px, that is irrelevant!  :)

------

Anyway, the whole thing is an awful cludge, and it really needs to be re-written. I've made a small Javascript that corrects the IE8 bug, and then I'm removing all that messy (conditional styles for IE) stuff from the SMF code.

Jscripts

By the way, the SMF code is what's causing the problem... it's making a tiny and almost insignicant IE8 bug into something much much worse, completely destroying the functionality of the forum editor for the majority of users.

The main part of the SMF code that causes it is the onclick="storeCaret(this);" and other event handlers... these are what makes the textarea jump!

You can confirm this by removing them from the code... the textarea then works in a much more "normal" fashion. Furthermore, have you noticed that the Textarea doesn't jump about when the editor is in WYSIWYG mode?

------------

Whilst playing with this stuff, you needn't test on a live forum or the PHP itself - just go to your own forum and do a "File > Save as > Webpage Complete". Then you can open that saved HTML and work on an exact "clone" of the page and test things.

Oya

first up the default width of the editor component is 70% not 100% as evidenced by subs-editor.php

it is also not practical to test it on a non working installation seeing how you also need to test it going back and forth between wysiwyg mode which explicitly needs to be on a working installation as it calls back to php to update stuff

sure i noticed it doesnt jump about in wysiwyg mode now but do you know why thats the case the wysiwyg editor doesnt actually work on the textarea so it doesnt trigger the bug

Advertisement: