Bug 58078 - dump-as-markup conversion: editing/pasteboard/paste-text-001.html and paste-text-011.html
Summary: dump-as-markup conversion: editing/pasteboard/paste-text-001.html and paste-t...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Enhancement
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 57743
  Show dependency treegraph
 
Reported: 2011-04-07 14:10 PDT by Ryosuke Niwa
Modified: 2011-04-08 11:08 PDT (History)
6 users (show)

See Also:


Attachments
Patch (40.82 KB, patch)
2011-04-07 14:31 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2011-04-07 14:10:36 PDT
The following tests should be converted to dump-as-markup tests so that their outputs are easily understood:
editing/pasteboard/paste-text-001.html
editing/pasteboard/paste-text-011.html
Comment 1 Ryosuke Niwa 2011-04-07 14:31:10 PDT
Created attachment 88700 [details]
Patch
Comment 2 Eric Seidel (no email) 2011-04-07 15:00:50 PDT
Comment on attachment 88700 [details]
Patch

LGTM.
Comment 3 WebKit Commit Bot 2011-04-07 21:02:31 PDT
Comment on attachment 88700 [details]
Patch

Clearing flags on attachment: 88700

Committed r83246: <http://trac.webkit.org/changeset/83246>
Comment 4 WebKit Commit Bot 2011-04-07 21:02:39 PDT
All reviewed patches have been landed.  Closing bug.
Comment 6 Ryosuke Niwa 2011-04-07 23:35:20 PDT
(In reply to comment #5)
> paste-text-011 doesn't pass on Chromium-win and Chromium-linux.
> http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=editing%2Fpasteboard%2Fpaste-text-011.html&showExpectations=true&showLargeExpectations=true&group=%40ToT%20-%20chromium.org
> 
> 
> Is it expected?

No.  That seems like a bug in Chromium's DRT or font resolution since all other ports are passing the test.  But I don't really care. That's such an insignificant difference I'd just rebaseline it.
Comment 7 Kent Tamura 2011-04-07 23:50:02 PDT
The DRT standard font of these platforms is 'times new roman' intentionally.  So, the test result should have the standard font name, shouldn't it?
Comment 8 Ryosuke Niwa 2011-04-07 23:51:23 PDT
(In reply to comment #7)
> The DRT standard font of these platforms is 'times new roman' intentionally.  So, the test result should have the standard font name, shouldn't it?

I don't know why we' do that.  That's different from all other platforms.  They all use Times.
Comment 9 Tony Chang 2011-04-08 09:22:15 PDT
(In reply to comment #8)
> (In reply to comment #7)
> > The DRT standard font of these platforms is 'times new roman' intentionally.  So, the test result should have the standard font name, shouldn't it?
> 
> I don't know why we'd do that.  That's different from all other platforms.  They all use Times.

Chromium Win and Linux try to match IE's font rendering as closely as possible.
Comment 10 Ryosuke Niwa 2011-04-08 09:58:07 PDT
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > The DRT standard font of these platforms is 'times new roman' intentionally.  So, the test result should have the standard font name, shouldn't it?
> > 
> > I don't know why we'd do that.  That's different from all other platforms.  They all use Times.
> 
> Chromium Win and Linux try to match IE's font rendering as closely as possible.

But we don't have to use that on DRT, do we?
Comment 11 Tony Chang 2011-04-08 10:04:17 PDT
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > The DRT standard font of these platforms is 'times new roman' intentionally.  So, the test result should have the standard font name, shouldn't it?
> > > 
> > > I don't know why we'd do that.  That's different from all other platforms.  They all use Times.
> > 
> > Chromium Win and Linux try to match IE's font rendering as closely as possible.
> 
> But we don't have to use that on DRT, do we?

We don't have to, but it would be nice to test what we ship.  For example, the whitespace behavior is different when you paste on Win/Linux so we have expected results for those tests that reflect the platform behavior.
Comment 12 Darin Adler 2011-04-08 10:14:55 PDT
DumpRenderTree does many things to make tests sharable across platforms.

I don’t think that “test what you ship” should override that for the vast majority of tests.
Comment 13 Ryosuke Niwa 2011-04-08 10:51:08 PDT
(In reply to comment #11)
> We don't have to, but it would be nice to test what we ship.  For example, the whitespace behavior is different when you paste on Win/Linux so we have expected results for those tests that reflect the platform behavior.

Sure, I understand the whitespace behavior but is there some behavioral difference between Times and Times New Roman besides the rendering and the name?
Comment 14 Tony Chang 2011-04-08 11:08:10 PDT
(In reply to comment #12)
> DumpRenderTree does many things to make tests sharable across platforms.
> 
> I don’t think that “test what you ship” should override that for the vast majority of tests.

I agree, but I don't think this difference accounts for a vast majority of tests unless you're including render tree tests.

(In reply to comment #13)
> Sure, I understand the whitespace behavior but is there some behavioral difference between Times and Times New Roman besides the rendering and the name?

The rendering difference is a behavioral difference that shows up in render trees.  I think if we switched the default font to Times in Chromium Win/Linux's DRT, we'd have to rebaseline most of the render tree tests.

It's a behavioral change in the same way that getting the exact right form button sizes as IE is a behavioral change.