Opened 16 years ago

Closed 16 years ago

#1547 closed Bug (worksforme)

Unwanted BR and   tags in IE6

Reported by: Stefan van Gastel 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 (2)

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

Download all attachments as: .zip

Change History (18)

comment:1 Changed 16 years ago by SJB

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 16 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 16 years ago by jan

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 16 years ago by SJB

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 16 years ago by Stefan van Gastel

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 16 years ago by jan

@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 16 years ago by Wojciech 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 16 years ago by Wojciech Olchawa

#1624 has been marked as DUP

comment:9 Changed 16 years ago by Wojciech Olchawa

#1528 has been marked as DUP

comment:10 in reply to:  description Changed 16 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 16 years ago by Julia

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

comment:12 Changed 16 years ago by Wiktor Walc

Keywords: Confirmed removed
Resolution: worksforme
Status: newclosed

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

comment:13 Changed 16 years ago by Stefan van Gastel

Confirmed, works fine, great job!

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

Changed 16 years ago by Doru Moisa

Attachment: Screenshot-3.png added

capture of the actual data sent by POST

Changed 16 years ago by Doru Moisa

Attachment: Screenshot-4.png added

after deleting the third "test"

comment:14 Changed 16 years ago by Doru Moisa

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 ; Changed 16 years ago by Julia

Resolution: worksforme
Status: closedreopened

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 16 years ago by Wojciech Olchawa

Resolution: worksforme
Status: reopenedclosed

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 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy