Opened 13 years ago

Last modified 10 years ago

#8164 confirmed Bug

IE8: empty paragaphs not editable/visible in wysiwyg mode

Reported by: Michal Malének Owned by:
Priority: Normal Milestone:
Component: General Version: 3.4.3
Keywords: IE8 Cc:

Description

Empty paragraphs (<p></p><p>&nbsp;</p>) cannot be accessed and edited and are not even visible in IE8. config.fillEmptyBlocks has no effect on this behavior. FF/Chrome work just the way they are expected to.

Attachments (3)

ck_empty_p.png (13.8 KB) - added by Michal Malének 13 years ago.
IE8.png (43.0 KB) - added by Jakub Ś 13 years ago.
test.html (749 bytes) - added by Jakub Ś 13 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 13 years ago by Jakub Ś

Status: newpending

I think I will be needing more information on this one because I was not able to reproduce it. I have pasted the code <p></p><p>&nbsp;</p> and depending whether config.fillEmptyBlocks was set to true or not these paragraphs were filled with &nbsp; or left empty. There was no problem in accessing or editing them.

  1. What version of CKEditor are you using?
  2. What operating system are you using?
  3. Have you tested this problem in default sample of CKEditor or you have used your configuration settings? If so, what settings have you used?
  4. Does it occur in clean version of CKEditor or in integration with Java, PHP etc.
  5. What doctype, if any, are you using on your HTML page?

Any sample files that will help us to reproduce the issue are welcome.

Changed 13 years ago by Michal Malének

Attachment: ck_empty_p.png added

comment:2 Changed 13 years ago by Michal Malének

I've done a little "research". I've reduced the source file to the minimum and X-UA-Compatible seems to be the cause. Without it, empty paragraphs are displayed all right, with it, the problem appears:

<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-W3CDTD XHTML 1.1EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="cs"> <head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="content-language" content="cs" />

<meta http-equiv="X-UA-Compatible" content="IE=9" />

<script type="text/javascript" src="http://localhost/_source/_fckeditor/3.6.1/ckeditor/ckeditor.js"></script>

</head>

<body>

<textarea name="ArticleText0" rows="8" cols="60"> &lt;p&gt;Not empty&lt;/p&gt; &lt;p&gt;&lt;/p&gt; &lt;p&gt;&amp;nbsp;&lt;/p&gt; &lt;p&gt;Not empty&lt;/p&gt; </textarea>

<script type="text/javascript"><![CDATA[4 CKEDITOR.replace( 'ArticleText0' ); ]]></script>

</body> </html>

Changed 13 years ago by Jakub Ś

Attachment: IE8.png added

Changed 13 years ago by Jakub Ś

Attachment: test.html added

comment:3 Changed 13 years ago by Jakub Ś

From the code you have provided I have created test.html file, pasted it in samples folder and opened under IE8. I did not get the same results as you did (See IE8.png).

Is there something I have missed or perhaps there are some other configuration setting that were used to reproduce the deffect.

comment:4 Changed 13 years ago by Michal Malének

Well, the problem seems to be even weirder than I thought it could. The "reproduction scenario" is as follows:

  • have a page with ckeditor and without X-UA-Compatible
  • switch to "compatible mode" (so far everything works fine)
  • add X-UA-Compatible and voila - the bug appears (it obviously is a bug of MSIE rather than CKeditor - the browser partially seems to be still running in a quasi-compatible mode - that cannot be turned off - and it has rendering problems with empty paragraphs)
  • to make things even more interesting: in ckeditor, neither nbsp'd paragraphs (<p>&nbsp;</p>) nor copletely empty ones (<p></p>; if fillEmptyBlocks is true) are visible. The rest of the page acts so that it does not show completely empty paragraphs but it does show the nbsp'd ones.

Note: I found this weird behavior while working on an upgrade of a cms system that used to rely on fckeditor and had to use compatibility mode in ie as there were some issues with fck that conflicted with the standard mode. In the framework of the upgrade, ckeditor and X-UA-Compatible were both added and this weird behavior appeared all of a sudden...) The weird behavior can be seen at http://_ck.pub-me.com/ but I guess you will have to copy it to your own server and follow the steps described above to be able to see what I mean :(

comment:5 Changed 13 years ago by Jakub Ś

Keywords: IE8 added
Status: pendingconfirmed
Version: 3.4.3

An easier way to reproduce would be:

  1. Paste test.html to samples folder (this page already contains X-UA-Compatible )
  2. Load the page test.html in IE8 in IE-8 mode
  3. Switch IE8 to compatibility mode

Result: Empty paragraphs are visible in source mode but not in WYSIWYG mode.

Reproducible in IE8 from CKEditor 3.4.3

comment:6 Changed 12 years ago by Gene

I've also reported this bug here:

http://dev.ckeditor.com/ticket/7157

It's a problem with Document Model: IE9 Standards

comment:7 Changed 12 years ago by Jakub Ś

I have rechecked this problem but it is has only been reproducible in IE8.

comment:8 Changed 10 years ago by shr

I stumbled upon this bug with ckeditor 4.0.1.1 and IE8 in "Compatibility View" mode (default for intranet sites). It could be fixed by patching plugins/wysiwygarea/plugin.js and adding

<meta http-equiv="X-UA-Compatible" content="IE=Edge" />

to the dynamically built iframe directly after "<head>".

It seems that for intranet sites, IE8 behaves like IE7 unless told otherwise. We already used the <meta> tag on the surrounding page, but the information did not propagate to the iframe, so the older rendering engine was used, causing empty <p> tags to be invisible.

I'm interested in feedback and hope this helps.

comment:9 Changed 10 years ago by Jakub Ś

I can confirm this is still an issue in latest CKEditor 4.2.2. What is more the below native code works in IE8:

<div contenteditable="true">
	<p>aaa</p>
	<p></p>
	<p></p>
	<p></p>
	<p>&nbsp;</p>
	<p>&nbsp;</p>
	<p>&nbsp;</p>
	<p>aaa</p>
</div>

@shr if you think you have the fix for the issue please get our master code and prepare pull request for it (https://github.com/ckeditor/ckeditor-dev/pulls). Please don't forget to put ticket number in pull request title.

comment:10 Changed 10 years ago by shr

I gave it a shot, but unfortunately it is not as easy on master. There are two conflicting changes between 4.0.1.1 and master that add a <title> and a <script> to <head> before the <meta> and the <meta> tag needs to be the very first child of <head> to function.

Sorry but I do not have the time to delve deeper.

comment:11 Changed 10 years ago by otomo

I have been also troubled with this bug in CKEditor 4.2.2.

However, I have found a way to solve the bug with following codes.

CKEditor.dom.document.prototype.write = function (html) {

this.$.open( 'text/html', 'replace' ); if ( CKEDITOR.env.ie ){

html = html.replace( /<\/title>/i, '$&\n<meta http-equiv="X-UA-Compatible" content="IE=8" />\n<script data-cke-temp="1">(' + CKEDITOR.tools.fixDomain + ')();</script>' );

} this.$.write( html ); this.$.close();

};

Can I use the codes in my javascript codes ?

Or is it a license violation to overwrite CKEditor's function prototype ?

Version 0, edited 10 years ago by otomo (next)

comment:12 Changed 10 years ago by Wiktor Walc

@otomo - this would not constitute a license violation, although please do note that you would still need to meet the requirements of a chosen Open Source license regarding derivative works

comment:13 Changed 10 years ago by Piotrek Koszuliński

I have checked this issue. It is a ridiculous case because IE starts to pretend that it's a IE7 and IE8/9 at the same time.

* document.documenMode = 8
* navigator.userAgent = "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0)"
* document.compatMode = "CSS1Compat"

And situation without <meta http-equiv="X-UA-Compatible" content="IE=Edge" /> (this one is correctly handled by CKEditor):

* document.documenMode = 7
* navigator.userAgent = "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0)"
* document.compatMode = "CSS1Compat"

In the first case CKEDITOR.env.version is set to 8 and maybe switching it to 7 would help, but who knows - it's IE. There's a limit of weirdnesses that we can handle and in this situation IE exceeds it.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy