Summary: | REGRESSION: plugins/plugin-remove-readystatechange.html is failing on debug bots | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||
Component: | Plug-ins | Assignee: | Alexey Proskuryakov <ap> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | commit-queue, darin, koivisto | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=130653 | ||||||
Attachments: |
|
Description
Alexey Proskuryakov
2013-12-23 11:27:47 PST
Darin had a related fix for this test in bug 130653, but that got rolled out. I'm going to tweak the test to make it non-flaky, but it looks like a real bug in rendering code (that I have no idea how to fix). When embed is the last rendered element in a document, and there is a newline after it, we create a renderer for the newline, and don't remove it when the embed is removed. But when there is no embed by the time the first layout occurs, the newline is ignored. So, we get different render trees for the same DOM, depending on its history. It's unfortunate that this bug hasn't been looked into in more than a year, even though the culprit was immediately identified. Created attachment 243934 [details]
proposed fix
(In reply to comment #1) > It's unfortunate that this bug hasn't been looked into in more than a year, > even though the culprit was immediately identified. What was the culprit? Comment on attachment 243934 [details] proposed fix > What was the culprit? Not a specific culprit in code, but circumstantial evidence was pointing to <http://trac.webkit.org/changeset/160908>. Comment on attachment 243934 [details] proposed fix Clearing flags on attachment: 243934 Committed r177879: <http://trac.webkit.org/changeset/177879> All reviewed patches have been landed. Closing bug. |