Item2476: Slow, erratic editing in plain textareas with IE8
Priority: Urgent
Current State: Closed
Released In: 1.0.9
Target Release: patch
Applies To: Engine
Component:
Branches:
Browser and Operating Systems tested
OS Family |
OS Version |
Browser |
Defective |
Who |
Windows XP |
5.01.2600 Service Pack 3 |
8.0.6001.18702 |
Yes |
PaulHarvey |
Windows 7 |
Build 7600 (64bit) |
8.0.7600.16385 (u0) |
Yes |
MarkusUeberall |
Windows XP |
version 2002 SP3 |
8.0.6001.18702 |
Yes |
KennethLavrsen |
Windows 7 |
version 6.1 7600 64 bit |
8.0.7600.16385 |
Yes |
KennethLavrsen |
I have been editing a very long topic.
One of those that would print out on 10-20 pages.
When you go to Wiki text editing (the old pickaxe) mode you should be in a good old plain text editor.
But some Javascript has been added recently which runs at every keypress.
And this is annoyingly slow when the topic is large. We need this thing removed.
It also has a tendency to make the cursor jump in IE.
When you have a large topic and deleting some text with back space the screen flickers and you end somewhere else in the document.
When you Raw Edit for real there is no issue. The issue is related to Wysiwyg editing first and then going to wiki text mode.
Wiki text mode must be raw and without JS running. And without cursor jumping.
Release blocker.
--
KennethLavrsen - 08 Dec 2009
edit.pattern.tmpl defines an onKeyDown event in the wysiwyg textarea, and I'm not sure why.
Right: Actually,
foswiki_src.js
in
TinyMCEPlugin intercepts the escape key.
--
PaulHarvey - 08 Dec 2009
The JS profiler in Firebug on FF3.5 shows nothing out of the ordinary.
IE8's profiler on the other hand, shows TMCE adding undo levels at every keypress when in the plaintext editor.
Somehow TMCE isn't shut down properly or the browser still has the addUndo callback tied to the keydown event when in raw mode.
Apparently not affected:
- IE6
- IE7
- FF3.0
- FF3.5
- Opera 10.10
- Google Chrome 3 (will confirm with profiling - strange performance behaviour - maybe their JS interpreter does runtime optimisation to mask the problem?)
- Safari 4 Update: Originally listed under affected with IE8, unable to reproduce a second time.
Affected:
Next step: replicate behaviour on vanilla TMCE setup (below)
Vanilla TinyMCE test
This editor below includes a topic with 183KB of junk. The MCE editor loads and automatically uses the
mceToggleEditor
command to disable itself, much as we do when we switch to raw in the Foswiki configuration. It also sets
forced_root_block: false
.
--
PaulHarvey - 08 Dec 2009
Kenneth, as you can see in the above vanilla setup, the problem persists without any foswiki customisations, but strangely on all browsers. So a bug needs to be filed upstream. I have confirmed this problem occurs on latest trunk checkout of TinyMCE rev 1271.
I thought perhaps we could use
mceRemoveControl
instead of
mceToggleEditor
to get
TinyMCE to shut down properly, but it didn't work.
The only way around this, short of fixing the TinyMCE code itself (which I can't do because between IE8, FF3.5 and Chrome - none of their JS profilers are giving me any info), would be to create a brand new textarea element which hasn't been hijacked by TinyMCE... messy :/
I'm almost out of ideas. Another possibility is to nuke whatever function is getting bound to the button pressing event(s), but without a profiler giving me results that's going to be hard...
--
PaulHarvey - 09 Dec 2009
The problem has arrived very recently. It was not in Foswiki 1.0.7 which used the previous TMCE version. I would have noticed at work.
If it cannot be fixed we need to revert to the Tiny we had in 1.0.7. It is impossible to live with the delay and the cursor jumping. We are talking about the most basic of features - editing a topic. Something all users are exposed to and something they already have tons of complains about for so many good reasons.
I have users editing long documents switching to Wikitext mode all the time. It is not an exception. It is the normal use case. Luckily most are still in IE6. But many have upgraded their IE (against the rules) and they will be on my back if I upgrade our Foswiki to 1.0.8.
We must have a solution to this in a 1.0.9. Even if it is messy.
--
KennethLavrsen - 09 Dec 2009
The difference between the others vs Safari + IE8 is that "the others" are allowing
PatternSkin's onKeyDown event handler in the textarea attributes to override
TinyMCE's binding for the same event when it's "disabled".
Whereas IE8 and Safari seem to be running
TinyMCE's handler. So the only reason the other browsers aren't affected, is by accident.
I am hopeful I can up with a way of safely nuking
TinyMCE's binding to that event in switchToRaw and restoring it in switchToWYSIWYG.
Actually, restoring it might be tricky :-/
Confirmed we don't have this bug in 3.2.2
--
PaulHarvey - 10 Dec 2009
Kenneth, can you raise a separate bug or describe to me any new defects with the 3.2.7 version of
TinyMCEPlugin for the cursor jumping.
Our existing cursor jumping task items apply equally to the 1.0.7 release/3.2.2 TMCE and largely affect Firefox (eg. finishing lists).
There is a "simple" work-around to the cursor jumping issues that I already know about. It involves wrapping the content issued to
TinyMCE by tml2html in a div.
I haven't committed it yet because it's not the best solution. But if I commit it now, it won't have had any testing, so I will have to spend at least 5 hours testing on at least five different browsers to make sure it doesn't cause any new bugs.
--
PaulHarvey - 10 Dec 2009
The cursor jumping is reported here because I am sure they are related or have same root cause.
I have seen it only under these conditions.
- Topic must be very long
- You must start with Wysiwyg and then change to Wikitext mode
- The browser must be IE8. I do not see it in FF
- You must select some text and then backspace it away.
And after the text is gone I have found myself in another part of the document. It does not always happen. But since it only happens when I also have the little hour glass at each keypress I assume it is the unwanted JS that causes the problem.
--
KennethLavrsen - 10 Dec 2009
I'm going in circles.
Problem:
- Large topics are slow in both ?nowysiwyg=1 (raw from the beginning) and switchToRaw, in IE8.
- That's why the javascript profilers are coming up with nothing. IE8 is just slow at large quantities of content in a textarea.
- I have to take back what I said about 3.2.2 not having this problem. I tested again, confirmed I had 3.2.2 loaded, and IE8 after switchToRaw is just as slow with the current contents of Item2476junk as it is
?nowysiwyg=1
Visit
Item2476junk for yourself; it's the plain skin, with minimal overhead: the only javascript being loaded is jquery, and yet IE8 is painfully slow to type into that textarea.
And so I've been chasing the wrong problem. I suspect you aren't editing topics with 183KB of topic text, so I have not reproduced the problem you are seeing.
Please update
Item2476junk with a typical quantity of content that is
sluggish to edit after
switchToRaw
and yet
behaves normally via
?nowysiwyg=1
--
PaulHarvey - 10 Dec 2009
IE8 Seems to be less sluggish when in IE7 or quirks mode. Can you confirm? I used the Developer Tools -> Browser Mode
Attached a possible work-around, apparently phpBB guys had a similar problem... Needs review by the browser/skin experts (I am not sure of the consequences of forcing IE8 into quirks mode).
--
PaulHarvey - 12 Dec 2009
You are right. IE8 is also showing this symptom in plain edit mode
And it does work like normal if you put IE8 in IE7 mode
If I choose compatibility view then it is also like normal
I have seen the cursor jumping on the quick fox. It is actually not the cursor that jumps. It is the whole page that scrolls. Typically you edit something in the middle and after a backspace delete of a character the current edited line is at the bottom of the edit textarea. Editing this topic I even get this rolling effect just starting typing.
So this is probably not a JS problem but an IE8 problem. The idea to change to compatibility or IE7 mode is not bad.
If we make it a setting it can easily be turned off when Microsoft fixes this problem sometimes in 2012
The cursor jump also goes away in compatibility view. They are for sure related. IE8 is a piece of junk. I am 99.9% sure putting the browser into a mode where the user does not experience this is a thing we have to persue. But then we get new problems.
There is a CSS side effect of IE7 mode. We seem to hit an old IE7 bug related to CSS of tables. Maybe
ArthurClemens know a work around for the style sheets for this
- IE8mode.png:
- IE7mode.png:
Also tried the quirks mode. That gets even worse. The length of a document does not have to be long to see the hour glass. This topic is now long enough to show the effect. Both hour glass and the scrolling thing. In fact the scrolling effect is so annoying that I have accidently typed the wrong place 3 times now editing this topic now. At work we still have IE6 and at home my favorite is FF so this is why I did not notice until I opened this report.
--
KennethLavrsen - 12 Dec 2009
Some notes from the IRC channel:
--
MarkusUeberall - 12 Dec 2009
I don't think I can find a solution on connect.microsoft.com. It turns out that one can set an arbitrarily large COLS attribute on the textarea, which somehow fools some part of the standards mode renderer into not triggering the bug.
I don't trust magic numbers, and it would kill the
EDITBOXWIDTH
setting, so I've committed a work-around which introduces a new (default) setting in
DefaultPreferences to force IE8 into compatibility mode in the edit template.
Added an OS/browser version table at the top.
The optimist in me says we can set this to "WaitingForRelease", but will wait for feedback instead (I'm not sure I know what I'm doing with skin templates).
This bug has really wasted a lot of my time... But I learnt from it.
--
PaulHarvey - 12 Dec 2009
I have tested your latest code.
It does not work. It does not put my IE8 into compatibility mode. And the problem persists.
I have two different client machines. One on XP and another in Windows 7. Same problem both places.
I can see in the Microsoft pages this text
The X-UA-compatible header is not case sensitive; however, it must appear in the Web page's header (the HEAD section) before all other elements, except for the title element and other meta elements.
But in our case the directive comes rather late. It may need to be placed earlier in the template
-
So, it looks like we have to deal with Item2095 (e.g., by introducing before="*") first? No; for the record: Paul's fix hardcodes the position immediately after the title tag -mue
--
KennethLavrsen - 13 Dec 2009
I tried to hack foswiki.pattern.tmpl adding the <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/> right after the head tag. Sometimes it works then and sometimes not.
If I place the thing BEFORE the html head it seems to always work. But then in all modes making view look bad. I did not persue trying to make it conditional to editing. I just did this as an experiment. So it seems IE8 is picky on how it gets this directive
--
KennethLavrsen - 13 Dec 2009
It seems picky about being inside a conditional comment, so I removed it (this will cause problems if future versions of IE that support
EmulateIE7 mode where we don't need it). It also didn't seem to work properly for me prior to the title element, so I've placed it afterwards. And for good measure, made it use double quotes for the meta attributes.
In the interest of getting 1.0.9 moving, hopefully this change does it..
--
PaulHarvey - 13 Dec 2009
As far as I can see in my tests it works fine now
- I also verified this using the code from release branch -mue
So merging this to trunk is what is missing getting this to
WaitingForRelease but it no longer blocks 1.0.9
--
KennethLavrsen - 13 Dec 2009
Last note: Regardless whether there's a plan to update f.o (which currently claims to run on 1.0.7) to 1.0.9, we should replace the four files in question (
templates/edit.tmpl
,
templates/foswiki.tmpl
,
templates/foswiki.pattern.tmpl
,
data/System/DefaultPreferences.txt
)
ASAP. If their old versions haven't been customised, this is a no-brainer (I diff'ed and tested them locally in my sandbox which is running on 1.0.7 as well).
--
MarkusUeberall - 13 Dec 2009
Ergghhh. It shouldn't have taken 57 commits to get this into trunk. Done...
--
PaulHarvey - 17 Dec 2009