Ticket #1547 (closed Bug: worksforme)

Opened 7 years ago

Last modified 7 years ago

Unwanted BR and   tags in IE6

Reported by: BlizzRD Owned by:
Priority: Normal Milestone:
Component: Project : MediaWiki+FCKeditor Version:
Keywords: Cc:

Description

Hi,

I am using the FCKEditor for MediaWiki in a test environment with IE6 and FireFox 2. I've installed the FCKEditor for MediaWiki following the instructions on http://www.mediawiki.org/wiki/Extension:FCKeditor_%28by_FCKeditor_and_Wikia%29

In internet explorer 6 if a word in a line of text is selected and deleted, and the page is saved there is a line break inserted on the place where the word was deleted. Sometimes accompanied by &nbsp'es.

I tried installing version 2.4.3 of the FCK subfolder instead of 2.5 and the problems, then are fixed. Instead a problem occurs with changing between wikitext and WYSIWYG and the escaping of HTML tags.

Note: these problems don't occur on FireFox 2.

Attachments

Screenshot-3.png (157.7 KB) - added by moisadoru 7 years ago.
capture of the actual data sent by POST
Screenshot-4.png (61.6 KB) - added by moisadoru 7 years ago.
after deleting the third "test"

Change History

comment:1 Changed 7 years ago by mertam

I have seen this as well, and it is a crucial fix for me. This basically makes the editor useless, since you can't reliably edit any file after initial creation using Internet Explorer. I prefer Firefox, but my company doesn't.

comment:2 Changed 7 years ago by Stephen R

We're experiencing this on our wiki as well. Doesn't bother me (personally), because I use FireFox, but a huge barrier to our users. Can someone do a quick bugfix for this? As the original poster mentioned, it only occurs when you highlight a line of text... it took us a while to figure out why we were getting randomly inserted line breaks.

comment:3 Changed 7 years ago by janweel

Hello there i am experiecing the same problem! Ì also have unwanted BR and   tags in IE6. I'm using mediawiki and FCK on an intranet. We use internet explorer 6.0. It could take ages before our (traditional) IT-department upgrades to a higher version of ie. I hope this Bug is fixable!

comment:4 Changed 7 years ago by mertam

It appears to me that a change done on Nov. 28 to fix another problem, fixed this problem also, as shown at:

http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/FCKeditor/plugins/mediawiki/fckplugin.js?view=log

So if someone else verifies this, this bug should be closed as a byproduct of 1586.

comment:5 Changed 7 years ago by BlizzRD

Correct, some bugs, like switching between wikitext and WYSIWYG doesn't generate html entities of wiki tags anymore, so this is fixed.

Still, in IE 6 the problem persists.

New notice, I know how to reproduce some of the bugs:

  1. Type: test <space> test <space> test <space> test
  2. Make the first test word bold.
  3. Save the page.
  4. Edit the page again and delete test word number 3.
  5. Save the page.

Now the bold code is extended, and the wikisource looks like this:

test''''test test 

comment:6 Changed 7 years ago by janweel

@mertam, thanks for your response. We installed a newer version of the plugin. Unfortunately the problem is still there. This is really a serious problem, i use wikimedia as an internal wiki for a publisher. I hope it is possible to fix it!

comment:7 Changed 7 years ago by w.olchawa

  • Keywords Confirmed added

Confirmed in IE6. It seems to work in IE7 and FF2.

Steps to reproduce:

1. Paste this text

This is some sample text written in MediaWiki+FCKeditor using IE6.

into the mediawiki page/

2. Save the page

3. Edit the page again and delete the word text

4. Either Save the page and edit it again or just switch to Wikitext and see that the code has been transformed into this:

This is some sample&nbsp;

<br>written in MediaWiki+FCKeditor using IE6.

Additional <br> and &nbsp; has occurred. Although the "&nbsp; is understandable because it replaces two spaces beside the word, the <br> shouldn't occur in the code.

Tested in Mediawiki 1.10 and 1.11.

comment:8 Changed 7 years ago by w.olchawa

#1624 has been marked as DUP

comment:9 Changed 7 years ago by w.olchawa

#1528 has been marked as DUP

comment:10 in reply to: ↑ description Changed 7 years ago by tschroeder

I've got the same problem and think the normalize() function in IE could be the problem. After the call rootNode.normalize() ; in the file fckplugin.js the problem occurred. The internet explorer put some additional XML endtags in it.

I guess that it isn't a good suggestion but by commenting out this line, the editor won't normalize the document and the problem won't appear again.

comment:11 Changed 7 years ago by julia82

I'm interested too. (If this bug really corresponds to my problem, I will give details too as soon as possible)!

comment:12 follow-up: ↓ 15 Changed 7 years ago by wwalc

  • Keywords Confirmed removed
  • Status changed from new to closed
  • Resolution set to worksforme

This issue doesn't seem to occur in the latest version of FCKeditor extension (where FCKeditor 2.5.1 is included).

comment:13 Changed 7 years ago by BlizzRD

Confirmed, works fine, great job!

Unfortunately I still can't use the extension... new ticket: #2075

Changed 7 years ago by moisadoru

capture of the actual data sent by POST

Changed 7 years ago by moisadoru

after deleting the third "test"

comment:14 Changed 7 years ago by moisadoru

I cannot reproduce this, please see the attached screenshots. After deleting the extra "test", a &nbsp; appears, which is fine, because in html you cannot have two consecutive spaces to display.

I'm using IE version 6.0.2900.2180.xpsp_sp2_rtm.040803-2158, Mediawiki svn rev.32912 and FCKEditor svn rev.1850

comment:15 in reply to: ↑ 12 ; follow-up: ↓ 16 Changed 7 years ago by julia82

  • Status changed from closed to reopened
  • Resolution worksforme deleted

Replying to wwalc:

This issue doesn't seem to occur in the latest version of FCKeditor extension (where FCKeditor 2.5.1 is included).

Hello, I'm using FCKeditor v2.5.1 WITHOUT the mediawiki extension and I (still) have the exact same problem described in the bug report.
I put at the end of this message a relevant part of my configuration file (the rest is personal plugins and fonts...): basically it tries that the FCKeditor touchs as less as possible the html generated.

I repeat the description of the problem (I have tried it with the aim to get an empty text in the editor and the result is a: "<br />" text)

"In internet explorer 6 if a word in a line of text is selected and deleted, and the page is saved there is a line break inserted on the place where the word was deleted. Sometimes accompanied by &nbsp'es."

Configuration file:

FCKConfig.FormatSource=false;
FCKConfig.FormatOutput=false;

FCKConfig.EnterMode='br';
FCKConfig.ShiftEnterMode='br';


System configuration: IE6 / WinXP for the user / Fedora4 for the server


1- Open the editor with some text inside
2- Try to select the whole text and delete it
3- If you navigate in the editor area you can see that it remains a line break

If you look at the html code (I don't even use the button "Source": I have my proper variables display) => the result is <br />

4- After some tries, it's ok you've got an empty text
5- Save it
6- open the same text from the saved file
7-The result is a non-empty text that contains the line break"<br />"


So please, give us a fix because it's a real problem for my client (I exactly check if the text changes for some validation!).

Thanks!

comment:16 in reply to: ↑ 15 Changed 7 years ago by w.olchawa

  • Status changed from reopened to closed
  • Resolution set to worksforme

Hello, I'm using FCKeditor v2.5.1 WITHOUT the mediawiki extension and I (still) have the exact same problem described in the bug report.

This is a actually a different issue. The reporter pointed out the &nbsp and <br> problem in MW and FCKeditor extension. The bug that you are referring to is a different issue , so you should open a new ticket for it.

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy