Opened 15 years ago
Closed 14 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 14 years ago by
Owner: | set to Tobiasz Cudnik |
---|---|
Status: | confirmed → assigned |
comment:7 Changed 14 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 14 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 14 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 14 years ago by
Owner: | changed from Tobiasz Cudnik to Paweł Horzela |
---|---|
Status: | review_failed → review |
comment:11 Changed 14 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 14 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 14 years ago by
Status: | review_failed → review |
---|
comment:14 Changed 14 years ago by
Status: | review → review_passed |
---|
comment:16 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | review_passed → closed |
Fixed with [5990].
Reproduced in fullpage mode.