[patch][ccla]Editor scrolling bugs on IE with large text

[guest]

One of our product teams reported the following problems with Editor.

• Type some text in a Dojo editor for at least a couple of pages (causing the scroll bar to show)
• go to the bottom on the document (scrolled down) and then highlight some text with the keyboard (shift/arrows)
  • bug 1: if you try to highlight with a double-click, the editor scrolls back up to the top
• once the text is highlighted, bold it (either with Ctrl-B or by clicking on the Bold icon)
  • bug 2: the editor scrolls back to the top

The problems occur on both Dojo 0.4 and 1.0 and was able to reproduce this problem. But on FCK, i couldn't. This leads us be to believe it's a Dojo bug and not a core IE problems because underneath both implementations lies the same IE control.

This is clearly a really bad bug that makes the Dojo editor on IE unusable but for the simplest of typing.

This bug has shown up on several sites which use Dojo 1 and 0.4 on IE 6 and 7. I believe this makes the editor useless in IE except for basic text typing of very short text.

[Douglas Hays]

This is much worse in 1.1. Clicking scrolled content in the editor area causes the editor to scroll to the top and the input caret is not even close to where you clicked.

[Adam Peller]

Cougar's got a handle on this.

[liucougar]

patch to fix the issue

[liucougar]

bill, is the patch for focus.js look ok for you?

[liucougar]

(In [13071]) fixes #6112

[Douglas Hays]

I applied the patch and I'm not seeing any change in the bad behavior. I'm running IE6 on WinXP.
Load test_Editor.html
Click in the text area of the first Editor box (Created from div).
Hold down the ENTER key until the scroll bar appears - then add a few more blank lines and then some text at the end.
Click away from the Editor in open whitesspace of the document to cause a blur.
Click back to the same Editor on the last line of text.
The Editor scrolls to the top and the last line is not visible and the input caret is changed.

[liucougar]

fix #6112 while keep #4996 and #5835 working

[Douglas Hays]

Fix blur/click scroll problem - bug#2 in the problem description remains

[Douglas Hays]

(In [13076]) References #6112. Proxy commit for haysmark. Fix tabbing on IE for Editor and prevent scrolling to the top on focus.

[Douglas Hays]

Bug 2 in the problem description remains.

[Adam Peller]

Comment By: Mehmet Akin (mehmeta) Date: 2008-03-17 01:43 GMT

If the page is in quirks mode and you focus the iframe manually with focus() or with the Tab-button IE will always scroll to the top of the iframe. If the page has a strict doctype, than the focusing with the tab-button lets the cursor position appear on the correct position like in FF and does not scroll to the top, but if u press any of the editor plugins, e.g. bold, italic, etc. the iframe is still scrolled to the top. This is caused by the manual focusing of the iframe with "this.editNode.focus()" in line 848 in Richtext.js. Since it works correct when the browser handles the focusing I attached a patch where I remove that manual focusing and fire an onfocus event to the iframe , so IE handles the focusing and it works fine. I had no time yet to write a patch for quirks mode. The idea for quirks would be maybe to first focus the iframe and then scroll to the latest cursor position manually with dijit.moveToBookmark() or so.

[Adam Peller]

patch from Mehmet Akin (IBM)

[Douglas Hays]

same patch but reformatted to use relative filenames - verified the patch fixes bug 2 on IE6

[alex]

(In [13156]) merging supplied patch from Mehmet Akin of IBM to fix a pretty bad editing behavior issue on IE. I've tested in both standards and quirks mode on IE 6 and the results appear to be the same. I'm not sure we need another patch. Fixes #6112

[Adam Peller]

(In [13734]) remove test. Refs #6112