HTMLAreaElement's coords attributes parsing does not comply with the HTML specification: - https://html.spec.whatwg.org/#attr-area-coords
Created attachment 287028 [details] Patch
Comment on attachment 287028 [details] Patch r=me
Comment on attachment 287028 [details] Patch Clearing flags on attachment: 287028 Committed r205030: <http://trac.webkit.org/changeset/205030>
All reviewed patches have been landed. Closing bug.
Reopening to attach new patch.
Created attachment 287128 [details] Patch
Comment on attachment 287128 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=287128&action=review > Source/WebCore/html/parser/HTMLParserIdioms.cpp:229 > +template <typename CharacterType> > +static inline bool isHTMLSpaceOrDelimiter(CharacterType character) > +{ > + return isHTMLSpace(character) || character == ',' || character == ';'; > +} > + > +template <typename CharacterType> > +static inline bool isNumberStart(CharacterType character) > +{ > + return isASCIIDigit(character) || character == '.' || character == '-'; > +} Is a template really needed? I think these could be be written to work on UChar and should work fine for LChar too. > Source/WebCore/html/parser/HTMLParserIdioms.cpp:262 > +Vector<double> parseHTMLListOfOfFloatingPointNumberValues(const String& input) Should take a StringView rather than a String. > Source/WebCore/html/parser/HTMLParserIdioms.cpp:266 > + unsigned length = input.length(); > + if (!length) > + return { }; This won’t be needed if the argument is a StringView.
Created attachment 287220 [details] Follow-up fixes Patch to take Darin's feedback into consideration.
Comment on attachment 287220 [details] Follow-up fixes Clearing flags on attachment: 287220 Committed r205095: <http://trac.webkit.org/changeset/205095>
*** Bug 153124 has been marked as a duplicate of this bug. ***
*** Bug 155516 has been marked as a duplicate of this bug. ***