Summary: | REGRESSION(r84311): WebKit copies too much styles when copying | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> | ||||||||||
Component: | HTML Editing | Assignee: | Ryosuke Niwa <rniwa> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | adele, ademar, darin, dglazkov, enrica, komoroske, morrita, ojan, rniwa, tkent, tony, webkit.review.bot | ||||||||||
Priority: | P1 | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Bug Depends on: | 60920, 60923, 60988 | ||||||||||||
Bug Blocks: | |||||||||||||
Attachments: |
|
Description
Ryosuke Niwa
2011-05-16 12:41:29 PDT
Created attachment 93693 [details]
work in progress
New approach is that we'll add text decoration property in the wrapping span instead of cloning the node that has this property as a special common ancestor.
I spent whole day debugging this bug but haven't found a solution yet. The problem is that if I add background color property like I'm doing in the work-in-progress patch, then string comparison in handleStyleSpansBeforeInsertion fail and we end up leaving style spans in paste. 592 // FIXME: This string comparison is a naive way of comparing two styles. 593 // We should be taking the diff and check that the diff is empty. 594 if (styleText == static_cast<Element*>(sourceDocumentStyleSpan)->getAttribute(styleAttr)) { 595 fragment.removeNodePreservingChildren(sourceDocumentStyleSpan); 596 if (!isStyleSpan(copiedRangeStyleSpan.get())) 597 return true; 598 } 599 600 if (isStyleSpan(copiedRangeStyleSpan.get()) && styleText == static_cast<Element*>(copiedRangeStyleSpan.get())->getAttribute(styleAttr)) { 601 fragment.removeNodePreservingChildren(copiedRangeStyleSpan.get()); 602 return true; 603 } We can't change these two style diffs either because the second diff must be done against the insertion position after sourceDocumentStyleSpan has been inserted. Resolving this bug properly may require fixing the bug 34564 first. Created attachment 94303 [details]
fixes the bug
Comment on attachment 94303 [details] fixes the bug Attachment 94303 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/8722324 Created attachment 94305 [details]
Archive of layout-test-results from ec2-cr-linux-02
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-02 Port: Chromium Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Ugh... git is screwing me up. I'll upload new patch using svn. Created attachment 94315 [details]
patch made by svn
Comment on attachment 94315 [details]
patch made by svn
Looks good to me.
Committed r87082: <http://trac.webkit.org/changeset/87082> Revision r87082 cherry-picked into qtwebkit-2.2 with commit ca2dab5 <http://gitorious.org/webkit/qtwebkit/commit/ca2dab5> |