Opened 9 years ago
Closed 8 years ago
#5626 closed Bug (fixed)
CKeditor 3.2.1 : html content attached makes ckeditor crash the browser FF/IE
| Reported by: | Alex Medina | Owned by: | Paweł Horzela |
|---|---|---|---|
| Priority: | Normal | Milestone: | CKEditor 3.4.2 |
| Component: | General | Version: | 3.2.1 |
| Keywords: | Cc: | alex@… |
Description
Tested in Ckeditor 3.2.1 demo site. I tested mostly with FF but it was also reported with IE.
The content in the file attached causes FF and IE to utilize tons of memory and the browser reports a script not responding alert error ("unresponsive script" in FF). If you click on "Continue" in the browser alert window, the browser crashes.
The attached small_html_ckeditor_bug.html web page causes this error with very little html code.
Notes/observations:
- If you only remove the the center tags, the problem goes away.
- If you only remove the last li tags, the problem goes away.
- if you only remove the inner table, the problem goes away.
Attachments (4)
Change History (20)
Changed 9 years ago by
| Attachment: | small_html_ckeditor_bug.html added |
|---|
comment:1 Changed 9 years ago by
| Keywords: | Confirmed added |
|---|---|
| Milestone: | → CKEditor 3.4 |
| Priority: | High → Normal |
Changed 9 years ago by
| Attachment: | 5626.patch added |
|---|
comment:2 Changed 9 years ago by
| Owner: | set to Garry Yao |
|---|---|
| Status: | new → assigned |
Ticket Test added:
run OR view source.
comment:3 Changed 9 years ago by
| Milestone: | CKEditor 3.4 → CKEditor 3.5 |
|---|
I think the idea behind the patch, as well as the tests are wrong. Leaving those <li>s as is could give unexpected results on the editor operations.
comment:4 Changed 9 years ago by
| Owner: | Garry Yao deleted |
|---|---|
| Status: | assigned → new |
comment:5 Changed 9 years ago by
| Keywords: | Confirmed removed |
|---|---|
| Status: | new → confirmed |
comment:6 Changed 9 years ago by
| Owner: | set to Tobiasz Cudnik |
|---|---|
| Status: | confirmed → assigned |
comment:7 Changed 9 years ago by
| Status: | assigned → review |
|---|
After deeper checking, i think that Garry's solution is fine, as all LIs are still fixed by a code executed before the new one.
I'm opting for another review.
comment:8 Changed 9 years ago by
| Status: | review → review_failed |
|---|
I tend to agree with Fred. We should opt to fix this code (gather this items in lists etc.) and not leaving it as is. For example now we can not use the list properties dialog on the list items.
comment:9 Changed 8 years ago by
If there is <LI> inside <TD> it's not allowed in DTD. We create new element <UL> between <TD> and <LI> to have <TD><UL><LI>.
comment:10 Changed 8 years ago by
| Owner: | changed from Tobiasz Cudnik to Paweł Horzela |
|---|---|
| Status: | review_failed → review |
comment:11 Changed 8 years ago by
| Status: | review → review_failed |
|---|
The idea is good, but why you're moving the children? Test case:
<div> text <li>item</li> </div>
produces
<div> <ul> text <li> item</li> </ul> </div>
comment:12 Changed 8 years ago by
Also, we must also not add the 'ul' directly, the <ul> might not fit in position as well, it should be something like:
parser.onTagOpen( 'ul', {} );
comment:13 Changed 8 years ago by
| Status: | review_failed → review |
|---|
comment:14 Changed 8 years ago by
| Status: | review → review_passed |
|---|
comment:16 Changed 8 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | review_passed → closed |
Fixed with [5990].

Reproduced in fullpage mode.