Bug 161730 - HTMLImageElement.width / height attributes should be unsigned
Summary: HTMLImageElement.width / height attributes should be unsigned
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL: https://html.spec.whatwg.org/#htmlima...
Keywords: WebExposed
Depends on:
Blocks:
 
Reported: 2016-09-07 19:57 PDT by Chris Dumez
Modified: 2016-09-08 12:48 PDT (History)
9 users (show)

See Also:


Attachments
Patch (15.93 KB, patch)
2016-09-07 21:00 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ews126 for ios-simulator-elcapitan-wk2 (8.92 MB, application/zip)
2016-09-07 22:11 PDT, Build Bot
no flags Details
Patch (18.68 KB, patch)
2016-09-08 10:07 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2016-09-07 19:57:07 PDT
HTMLImageElement.width / height attributes should be unsigned as per the HTML specification:
- https://html.spec.whatwg.org/#htmlimageelement

However, they are signed in WebKit. Firefox agrees with the specification.
Comment 1 Chris Dumez 2016-09-07 21:00:02 PDT
Created attachment 288238 [details]
Patch
Comment 2 Alex Christensen 2016-09-07 21:16:28 PDT
Comment on attachment 288238 [details]
Patch

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

> Source/WebCore/html/HTMLImageElement.cpp:408
> +        Optional<int> height = parseHTMLNonNegativeInteger(attributeWithoutSynchronization(heightAttr));

auto

> Source/WebCore/html/HTMLImageElement.h:42
> -    static Ref<HTMLImageElement> createForJSConstructor(Document&, const int* optionalWidth, const int* optionalHeight);
> +    static Ref<HTMLImageElement> createForJSConstructor(Document&, Optional<unsigned> width, Optional<unsigned> optionalHeight);

optionalHeight could just be height.
Comment 3 Build Bot 2016-09-07 22:11:09 PDT
Comment on attachment 288238 [details]
Patch

Attachment 288238 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/2031121

New failing tests:
imported/w3c/web-platform-tests/html/dom/reflection-embedded.html
Comment 4 Build Bot 2016-09-07 22:11:13 PDT
Created attachment 288246 [details]
Archive of layout-test-results from ews126 for ios-simulator-elcapitan-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews126  Port: ios-simulator-elcapitan-wk2  Platform: Mac OS X 10.11.5
Comment 5 Chris Dumez 2016-09-08 10:07:56 PDT
Created attachment 288272 [details]
Patch
Comment 6 Chris Dumez 2016-09-08 10:10:40 PDT
Comment on attachment 288238 [details]
Patch

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

>> Source/WebCore/html/HTMLImageElement.cpp:408
>> +        Optional<int> height = parseHTMLNonNegativeInteger(attributeWithoutSynchronization(heightAttr));
> 
> auto

I actually do not like using auto for Optional<> type because I find the resulting code a bit confusing:
auto height = parseHTMLNonNegativeInteger(attributeWithoutSynchronization(heightAttr));
if (height)
  // ...

It makes it look like you're checking if height is != 0, which is not the case. One way to work around this would be to keep 'optional' in the variable name:
auto optionalHeight = parseHTMLNonNegativeInteger(attributeWithoutSynchronization(heightAttr));
if (optionalHeight)
  // ...

But I don't think it is better than using an explicit Optional<> type and a shorter 'height' variable name.

>> Source/WebCore/html/HTMLImageElement.h:42
>> +    static Ref<HTMLImageElement> createForJSConstructor(Document&, Optional<unsigned> width, Optional<unsigned> optionalHeight);
> 
> optionalHeight could just be height.

Oops, fixed.
Comment 7 Chris Dumez 2016-09-08 12:48:12 PDT
Comment on attachment 288272 [details]
Patch

Clearing flags on attachment: 288272

Committed r205655: <http://trac.webkit.org/changeset/205655>
Comment 8 Chris Dumez 2016-09-08 12:48:17 PDT
All reviewed patches have been landed.  Closing bug.