Summary: | editing/pasteboard/paste-noscript-xhtml.xhtml crashes in chromium's content_shell | ||
---|---|---|---|
Product: | WebKit | Reporter: | jochen |
Component: | HTML Editing | Assignee: | Adam Klein <adamk> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | adamk, esprehn, leviw, ojan, rniwa |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | 99880 | ||
Bug Blocks: |
Description
jochen
2012-10-17 10:11:40 PDT
Most likely reason for this is that we're passing an empty DocumentFragment to ContainerNode::takeAllChildrenFrom(), which assumes (but doesn't check) that oldParent is non-null. Will look into it. I'm running into a bit of a problem trying to track this down, in that I can't figure out how to attach gdb to the renderer. jochen, any tips? (In reply to comment #2) > I'm running into a bit of a problem trying to track this down, in that I can't figure out how to attach gdb to the renderer. jochen, any tips? I would try echo /path/to/editing/pasteboard/paste-noscript-xhtml.xhtml | out/Debug/content_shell --dump-render-tree --no-timeout --no-sandbox --renderer-cmd-prefix='xterm -title renderer -e gdb --eval-command=run --args' That should start each renderer in a gdb in a new xterm Thanks, used printfs for now. It looks like the problem is that the selected content can't be parsed, likely due to a leading <meta charset='UTF-8'> tag in the selected markup. Still digging to figure out how that's ending up in the selection, and only in ContentShell. (In reply to comment #4) > Thanks, used printfs for now. It looks like the problem is that the selected content can't be parsed, likely due to a leading <meta charset='UTF-8'> tag in the selected markup. Still digging to figure out how that's ending up in the selection, and only in ContentShell. Correction, that's "<meta charset='utf-8'>" to be precise, and at least on Mac it looks like we add that to the selection. Last of updates for now, I think I've got a bead on it. Okay, I lied, one more question for jochen: I take it you were running this on Linux? I'm not able to reproduce there, only on Mac, and the <meta> tag insertion I mentioned before seems to be Mac-specific. (In reply to comment #6) > Okay, I lied, one more question for jochen: I take it you were running this on Linux? I'm not able to reproduce there, only on Mac, and the <meta> tag insertion I mentioned before seems to be Mac-specific. Yes, sorry for not mentioning this. I can repro on 64bit lucid and precise (In reply to comment #7) > (In reply to comment #6) > > Okay, I lied, one more question for jochen: I take it you were running this on Linux? I'm not able to reproduce there, only on Mac, and the <meta> tag insertion I mentioned before seems to be Mac-specific. > > Yes, sorry for not mentioning this. > > I can repro on 64bit lucid and precise Hmm, I can't on precise (the test fails to run properly instead, looks like perhaps the paste never happens?). Anyway, the <meta> thing looks like a real bug (http://crbug.com/136218). (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > Okay, I lied, one more question for jochen: I take it you were running this on Linux? I'm not able to reproduce there, only on Mac, and the <meta> tag insertion I mentioned before seems to be Mac-specific. > > > > Yes, sorry for not mentioning this. > > > > I can repro on 64bit lucid and precise > > Hmm, I can't on precise (the test fails to run properly instead, looks like perhaps the paste never happens?). Anyway, the <meta> thing looks like a real bug (http://crbug.com/136218). Are you building after chromium r161834 ? Should be fixed by http://trac.webkit.org/changeset/132211 |