Opened 5 years ago

Closed 5 years ago

#11308 closed Bug (duplicate)

editor in 'enter_br' mode loses br tags if multiple br tags are present before a table (tested for IE 9, IE 10 and IE 11)

Reported by: thomb Owned by:
Priority: Normal Milestone:
Component: Core : Parser Version: 4.1.2
Keywords: Cc:

Description

Steps to reproduce

Use the following code template to recreate the issue:

<br>
<br>
<br>
<br>
<br>
<table cellspacing="0" cellpadding="0">
<tr>
<td>test block html with 5 br tags in front of it</td>
</tr>
</table>

Currently it has 5 br tags in front of the table block. After saving what i believe is a underlaying problem in the HTML parser calling out to the cleanBogus() function which results in the HTML with only 4 br tags with the table following.

This only seems to happen with IE 9, IE 10 and IE 11 with the latest updates applied as of 2013-12-13 (not tested with IE 8 or IE 7 which might have the same issue as well).

Also tested with Safari 5.1.7, Firefox 26, Chrome 31.0.1650.63 m and Opera 18.0.1284.63 which do not seem to have the same problem. Each time this block of HTML is saved 1 br tag is lost.

Browser and OS

  • Windows 7 with full updates applied installed with IE 9 with all IE 9 specific updates applied
  • Windows 7 with full updates applied installed with IE 10 with all IE 10 specific updates applied
  • Windows 8.1 with full updates applied installed with IE 11 with all IE 11 specific updates applied

Used the following CKEditor versions for testing:

  • CKEditor 4.3.0 (live environment)
  • CKEditor 4.3.1 (development environment)
  • CKEditor V4 Nightly Build created on 2013-12-13 (mock-up test environment)

Note: all these versions where clean downloads without any additional plugins.

I used a restore from the full zip from these versions to exclude potential differences with original files and disabled custom configurations.

The only exception to custom specified settings where enter_br mode and closing tag ('>' instead of '/>') override settings. Also restarted the offending browsers and cleaned their cache in case it might have been caused by a caching issue.

Screenshot

Not applicable in this case

Sample data

Data added in codeblock above

Test case file

Data added in codeblock above

Build configuration

Problem persists in full edition, minimal edition as well as custom builds so it is not a build configuration specific problem but a general problem.

Additional notes

Please note that the ticket [dev.ckeditor.com/ticket/10146‎] seems similar however it has already been marked fixed while this issue still remains so i believe it is not the exact same problem.

Tried to find the exact problem lines by altering a few different locations where i thought the offending problem might be caused which handle br tags. However it did not have the desired result so i wont include these trials within this ticket other then this mentioning of my attempts. I have more experience with writing custom plugins and altering existing plugins then with modifying the core source that handles parsing and other generic internal editor handling.

Change History (4)

comment:1 Changed 5 years ago by thomb

Small update, it seems to happen with each block of br tags simultaneous as well.

So the following code:

<br>
<br>
<br>
<br>
<br>
<table cellspacing="0" cellpadding="0">
<tr>
<td>test block html with 5 br tags in front of it</td>
</tr>
</table>
<br>
<br>
<br>
<br>
<br>
<table cellspacing="0" cellpadding="0">
<tr>
<td>test block html with 5 br tags in front of it</td>
</tr>
</table>

Will have the same issue but instead of just losing one br tag it loses 2 br tags, 1 from each group of br tags.

Also i run the editor in strict mode with the following DTD (which is also a configuration option which i forgot to mention in the initial ticket body as this might matter as well):

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> 

I have tried to disable or alter each instance where i could find the editor interacting with br tags but was not able to change this behavior or find a culprit which was causing this.

Given it seems to only happen in combination with a table element following i am not excluding the possibility it might be caused by an regular expression or other function i may be unaware of that might interact with the HTML markup as well.

comment:2 Changed 5 years ago by thomb

Another small update after more testing.

I have missed one thing and that is when the br tags are wrapped in a paragrap tag this seems to happen. This is mostly a "legacy" IE issue from old code but IE still sometimes does this in certain cases.

so the code to test with should be updated to:

<p>
<br>
<br>
<br>
<br>
<br>
</p>
<table cellspacing="0" cellpadding="0">
<tr>
<td>test block html with 5 br tags in front of it</td>
</tr>
</table>
<p>
<br>
<br>
<br>
<br>
<br>
</p>
<table cellspacing="0" cellpadding="0">
<tr>
<td>test block html with 5 br tags in front of it</td>
</tr>
</table>

Other then this it randomly seems to work although it also happens occassionally on non paragraph wrapped br tags, which might be some other piece of code causing it. It seems to happen 100% on the paragraph wrapped br tags however.

comment:3 Changed 5 years ago by Jakub Ś

Version: 4.3.14.1.2

This issue looks like a duplicate of #10146. I get same results as in both tickets.

"After saving what i believe is a underlaying problem" Editor doesn't have anything to do with saving data. When you press submit button, getData() method is called and HTML is produced in a same manner as when you switch to Source mode.

I didn't get one by one br tags removal in browsers. In all cases this was at the most one br tag which is exchanged to &nbsp;.

Taking all that into account, this is a duplicate of #10146. I will however talk with my colleagues if this can't be improved a little bit more.

comment:4 Changed 5 years ago by Jakub Ś

Resolution: duplicate
Status: newclosed

@thomb I have reported issue #11392 which continues #10146

That ticket reports issues i have found. If you have other scenarios please report them in #11392 (saving data into DB is not a scenario).

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