Opened 15 years ago
Closed 15 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 15 years ago by
| Attachment: | small_html_ckeditor_bug.html added |
|---|
comment:1 Changed 15 years ago by
| Keywords: | Confirmed added |
|---|---|
| Milestone: | → CKEditor 3.4 |
| Priority: | High → Normal |
Changed 15 years ago by
| Attachment: | 5626.patch added |
|---|
comment:2 Changed 15 years ago by
| Owner: | set to Garry Yao |
|---|---|
| Status: | new → assigned |
Ticket Test added:
run OR view source.
comment:3 Changed 15 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 15 years ago by
| Owner: | Garry Yao deleted |
|---|---|
| Status: | assigned → new |
comment:5 Changed 15 years ago by
| Keywords: | Confirmed removed |
|---|---|
| Status: | new → confirmed |
comment:6 Changed 15 years ago by
| Owner: | set to Tobiasz Cudnik |
|---|---|
| Status: | confirmed → assigned |
comment:7 Changed 15 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 15 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 15 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 15 years ago by
| Owner: | changed from Tobiasz Cudnik to Paweł Horzela |
|---|---|
| Status: | review_failed → review |
comment:11 Changed 15 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 15 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 15 years ago by
| Status: | review_failed → review |
|---|
comment:14 Changed 15 years ago by
| Status: | review → review_passed |
|---|
comment:16 Changed 15 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | review_passed → closed |
Fixed with [5990].

Reproduced in fullpage mode.