onBeforeUnload event is fired in IE by switchin modes

[Alfonso Martínez de Lizarrondo]

Modify the replacebyclass example adding this code:

	<script type="text/javascript">

		window.onbeforeunload = function() {
			if (typeof(CKEDITOR)!='undefined')
			{
				var oEditor = CKEDITOR.instances.editor1 ;
				if (oEditor.checkDirty())
					return "The text has been modified, do you want to save it before closing?.";
			}
			return undefined;
		}

	</script>

Now load the page and switch to source and back to design.

Expected: nothing special.

Results: the onBeforeUnload is fired on each change, and the checkDirty() returns true (#6274)

Tested with IE8. Firefox works fine, only shows the alert if the content has been modified and you want to close the page.

[Alfonso Martínez de Lizarrondo]

Correction: this happens with almost any toolbar button.

The problems started with [6971]

This is a critical bug for anyone that has set a onBeforeUnload handler and is using IE, I suggest to nominate it for 3.6.1

[Wiktor Walc]

Nice catch

[Garry Yao]

This ticket just reveal some evilness of [6971], so re-propose a fix for #188 as I tried to do on that ticket.

[Garry Yao]

I don't think unselectable should be applied recursively, the purpose of the selectable call is to prevent text selection from starting on the specified element, and a single attribute turns out to be enough unless you cite me an evidence that I'm wrong.

[Frederico Caldeira Knabben]

Replying to garry.yao:

This ticket just reveal some evilness of [6971], so re-propose a fix for #188 as I tried to do on that ticket.

The way you put seem sounds like this ticket was logically predictable, which was not (there is no logic for it). In any case the proposed patch already have R- on #188, so there is no reason to have it differently now.

Replying to garry.yao:

I don't think unselectable should be applied recursively, the purpose of the selectable call is to prevent text selection from starting on the specified element, and a single attribute turns out to be enough unless you cite me an evidence that I'm wrong.

That thing is there since I can remember it. There is no correlation between that change and the fix. If we have that code, I'm sure there is a good reason for it. We'll not spend time on looking for the reasons to justify changing stable code.

To conclude, the right way to close this ticket is simply reverting [6971] and reopening #188. I'll do that now.

[Frederico Caldeira Knabben]

Reverted [6971] with [7027].