StartupFocus=false being ignored in IE 6.0

[corpsusvitale@…]

I started this new bug so I can attach my test files. This is actually a comment on bug [ 1313002 ] StartupFocus=false being ignored in IE 6.0.

I can confirm this behavior in version 2.2. I don't know what is happening but I managed to conjure an example. I have no clue what causes the behavior. Just try the example (test.html) on IE6.0 and see what happens. A similar behavior occurs in our application, where we try every trick in the book to prevent browser caching. If you need more info, I'll be happy to provide anything I can.

---

Moved from SF:
​http://sourceforge.net/tracker/index.php?func=detail&aid=1396116&group_id=75348&atid=543653

[Frederico Caldeira Knabben]

Test Case - Moved from SF. Original author: fredck

[Frederico Caldeira Knabben]

2 HTML files, open test.html - Moved from SF. Original author: corpsusvitale

[Frederico Caldeira Knabben]

Yes, I have the same problem.

---

Moved from SF. Original poster: noamway

[Frederico Caldeira Knabben]

I can confirm that we're having the same problem in our application. Don't know what's causing it yet.

---

Moved from SF. Original poster: geirhelge

[Frederico Caldeira Knabben]

The bug seems to happen at line 257 in file: "editor/_source/internals/fck_1_ie.js".

The line is:

this.EditorDocument.body.contentEditable = true ;

When this line is called the focus is set to the first editor on a page, and the browser scrolls down and reveals the editor.

Commenting out the line stated above will prevent this from happening, but will ofcause also efficiently prevent users from editing anything in the editor.

I will experiment some more in order to find a fix for the problem.

---

Moved from SF. Original poster: johnnyege

[Frederico Caldeira Knabben]

Patch 1466303 should fix this bug:
​http://sourceforge.net/tracker/index.php?func=detail&aid=1466303&group_id=75348&atid=543655

---

Moved from SF. Original poster: johnnyege

[Frederico Caldeira Knabben]

I am not able to reproduce it here with the 2.2. Version 2.3 Beta has introduced a new loading system (I can't reproduce it with it too).

Can you confirm you still have problems with that?

Thanks in advance.

---

Moved from SF.

[Frederico Caldeira Knabben]

Hi,

I've done some more testing on this issue today and I don't think this is a bug in the FCKeditor (not in our case anyway). The fix johnnyege (colleague of mine) posted 2006-04-07 fixed our problem. If the fix johnnyege can't be used, we'll have to find another way to work around this in IE. I've reproduced the problem in both 2.2 and 2.3. Couldn't find a way to upload it here, so I've uploaded it to our demo server: ​http://demo.coretrek.no/FCKeditor/

Short explanation: The reason we're changing the href for links on body load, is that we want to run the checkdirty function before a user leave our article editor using any of the links (there are several input elements in addition to FCKeditor). None of the links in the article body are changed. As you can see, it's enough to change one link that's not related to the editor at all.

Please let me know if you need any more information.

Best regards Geir Helge

---

Moved from SF. Original poster: geirhelge

[Frederico Caldeira Knabben]

I'm attaching a simple TC for it. A workaround is included in the code.

It seams to be an IE bug (or feature?), quite difficult to fix. I've tracked the editor code, and the "FCK.Focus" function is not being called. So, the browser is placing the focus there by itself.

---

Moved from SF.

[Frederico Caldeira Knabben]

Hi

Did you test this workaround in version 2.3 as well? It seems like it works in version 2.2, but not in 2.3.

Best regards Geir Helge

---

Moved from SF. Original poster: geirhelge

[Frederico Caldeira Knabben]

The Test Case is there to show the bug. The workaround is commented in the file. I've tested with version 2.3.

---

Moved from SF.

[Frederico Caldeira Knabben]

The following is a DUP of this one:
​http://sourceforge.net/tracker/index.php?func=detail&aid=1577437&group_id=75348&atid=543653

[Martin Kou]

After a lot of testing, I found a trick to fix that by using the IE-only UNSELECTABLE property. I've committed the trick-fix as changeset [569].

The trick involves setting UNSELECTABLE to "on" just before setting contentEditable to true. This make Internet Explorer unable to move the focus into the editor document. After that, we set UNSELECTABLE back to "off" with a setTimeout() so everything returns to normal.

I've also made a very simple test case which illustrates how the browser bug occurs and how the fix works. Since it is a browser bug, it can be reproduced even without FCKeditor.

<html>
	<head>
		<script type="text/javascript">
// set the onload attribute of <body> to this function for fixed behavior.
function initFixed()
{
	document.getElementById("lynk").href = "http://www.google.com" ;
	frames[0].document.body.unselectable = "on";
	frames[0].document.body.contentEditable = true;
	setTimeout('frames[0].document.body.removeAttribute("unselectable");', 1);
}

// set the onload attribute of <body> to this function for the browser bug.
function initBugged()
{
	document.getElementById("lynk").href = "http://www.google.com" ;
	frames[0].document.body.contentEditable = true;
}
		</script>
	</head>
	<body onload="initFixed();">
		Some text here <a href="about:blank" id="lynk">and a link</a>.
		<div style="margin-top: 1600px">
			<iframe src="about:blank" width="500" height="500"></iframe>
		</div>
	</body>
</html>