Bug 103568

Summary: [mac] WebHTMLConverter should maintain font size even when there is no related NSFont
Product: WebKit Reporter: Tim Horton <thorton>
Component: HTML EditingAssignee: Tim Horton <thorton>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, enrica, mitz, rniwa
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 103496    
Attachments:
Description Flags
patch ap: review+

Tim Horton
Reported 2012-11-28 15:42:22 PST
If WebHTMLConverter is faced with a Web font within a range in editingAttributedStringFromRange, it drops the style on the floor. It should instead substitute a default font of the appropriate size.
Attachments
patch (2.27 KB, patch)
2012-11-28 15:44 PST, Tim Horton 		ap: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Tim Horton
Comment 1 2012-11-28 15:44:33 PST
Created attachment 176592 [details] patch Looking into how to test, but it seems potentially quite tricky.
Alexey Proskuryakov
Comment 2 2012-11-28 15:55:48 PST
Comment on attachment 176592 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=176592&action=review > Source/WebCore/ChangeLog:12 > + (+[WebHTMLConverter editingAttributedStringFromRange:]): Do we have the same issue in non-editing version?
Tim Horton
Comment 3 2012-11-28 16:07:10 PST
(In reply to comment #2) > (From update of attachment 176592 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=176592&action=review > > > Source/WebCore/ChangeLog:12 > > + (+[WebHTMLConverter editingAttributedStringFromRange:]): > > Do we have the same issue in non-editing version? From code inspection it looks to me like the non-editing path does the right thing, actually!
Tim Horton
Comment 4 2012-11-28 16:15:42 PST
http://trac.webkit.org/changeset/136073
Note You need to log in before you can comment on or make changes to this bug.