Bug 140256 – [Win] DumpRenderTree always using 800x600 size even if test needs other size

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Brent Fulgham]

Several SVG tests are failing because DumpRenderTree started using 800x600 dimensions regardless of the test settings.

svg/W3C-SVG-1.1-SE/color-prop-05-t.svg
svg/W3C-SVG-1.1-SE/coords-dom-01-f.svg
svg/W3C-SVG-1.1-SE/coords-dom-02-f.svg
svg/W3C-SVG-1.1-SE/coords-dom-03-f.svg
svg/W3C-SVG-1.1-SE/coords-dom-04-f.svg
svg/W3C-SVG-1.1-SE/coords-units-03-b.svg
svg/W3C-SVG-1.1-SE/filters-felem-01-b.svg
svg/W3C-SVG-1.1-SE/filters-image-03-f.svg
svg/W3C-SVG-1.1-SE/filters-image-05-f.svg
svg/W3C-SVG-1.1-SE/interact-pointer-03-t.svg
svg/W3C-SVG-1.1-SE/painting-marker-05-f.svg
svg/W3C-SVG-1.1-SE/painting-marker-06-f.svg
svg/W3C-SVG-1.1-SE/painting-marker-07-f.svg
svg/W3C-SVG-1.1-SE/paths-dom-02-f.svg
svg/W3C-SVG-1.1-SE/pservers-grad-17-b.svg
svg/W3C-SVG-1.1-SE/pservers-grad-20-b.svg
svg/W3C-SVG-1.1-SE/pservers-pattern-03-f.svg
svg/W3C-SVG-1.1-SE/pservers-pattern-04-f.svg
svg/W3C-SVG-1.1-SE/struct-dom-11-f.svg
svg/W3C-SVG-1.1-SE/struct-use-11-f.svg
svg/W3C-SVG-1.1-SE/struct-use-14-f.svg
svg/W3C-SVG-1.1-SE/styling-css-04-f.svg
svg/W3C-SVG-1.1-SE/styling-pres-02-f.svg
svg/W3C-SVG-1.1-SE/svgdom-over-01-f.svg
svg/W3C-SVG-1.1-SE/text-tref-03-b.svg
svg/W3C-SVG-1.1-SE/text-tspan-02-b.svg
svg/W3C-SVG-1.1-SE/types-dom-02-f.svg
svg/W3C-SVG-1.1-SE/types-dom-03-b.svg
svg/W3C-SVG-1.1-SE/types-dom-04-b.svg
svg/W3C-SVG-1.1-SE/types-dom-05-b.svg
svg/W3C-SVG-1.1-SE/types-dom-06-f.svg
svg/W3C-SVG-1.1-SE/types-dom-07-f.svg
svg/W3C-SVG-1.1/animate-elem-64-t.svg
svg/W3C-SVG-1.1/animate-elem-65-t.svg

[Brent Fulgham]

The problem was actually a bug in how we identify when to use the special W3C screen size of 480x360. Depending on how the code is run (i.e., from a Windows Shell versus a Cygwin shell) the path separator can be different, and the naive path test will fail.

Correction is to test both path types for a match.

[Brent Fulgham]

Created attachment 244302 [details]
Patch

[Brent Fulgham]

Created attachment 244303 [details]
Patch

[Anders Carlsson]

Comment on attachment 244303 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=244303&action=review

> Tools/DumpRenderTree/win/DumpRenderTree.cpp:827
> +        Vector<UniChar> urlCharacters(stringLength + 1, 0);

Do you really need stringLength + 1 here? IIRC BSTRs aren't null-terminated.

[Brent Fulgham]

(In reply to comment #4)
> Comment on attachment 244303 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=244303&action=review
> 
> > Tools/DumpRenderTree/win/DumpRenderTree.cpp:827
> > +        Vector<UniChar> urlCharacters(stringLength + 1, 0);
> 
> Do you really need stringLength + 1 here? IIRC BSTRs aren't null-terminated.

Right! But, the _bstr_t template expects to receive a null-terminated input string, which it converts to a BSTR.

If this was in WebCore I'd just use our BString class, but it's outside of WebCore/WebKit so I'm trying to use _bstr_t instead.

[Brent Fulgham]

Committed r178139: <http://trac.webkit.org/changeset/178139>

[Csaba Osztrogonác]

*** Bug 139972 has been marked as a duplicate of this bug. ***