RESOLVED FIXED 106251
Introduce HTMLParserOptions to encapsulate HTML parser options 
https://bugs.webkit.org/show_bug.cgi?id=106251
Summary Introduce HTMLParserOptions to encapsulate HTML parser options
Adam Barth
Reported 2013-01-07 13:55:22 PST
Introduce HTMLParserOptions to encapsulate HTML parser options
Attachments
Patch (no xcodeproj changes yet) (23.14 KB, patch)
2013-01-07 13:59 PST, Adam Barth 		eric: review+
buildbot: commit-queue-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Adam Barth
Comment 1 2013-01-07 13:59:51 PST
Created attachment 181558 [details] Patch (no xcodeproj changes yet)
Build Bot
Comment 2 2013-01-07 14:08:20 PST
Comment on attachment 181558 [details] Patch (no xcodeproj changes yet) Attachment 181558 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/15734861
Adam Barth
Comment 3 2013-01-07 14:18:23 PST
(The apple-mac failure is expected because I need to add HTMLParserOptions to the xcodeproj file.)
Eric Seidel (no email)
Comment 4 2013-01-07 14:28:58 PST
Comment on attachment 181558 [details] Patch (no xcodeproj changes yet) View in context: https://bugs.webkit.org/attachment.cgi?id=181558&action=review This is a fantastic change. This breaks these options from being "dynamic" if they're supposed to be by being "Settings". r=me if you make Mac build. > Source/WebCore/html/parser/HTMLParserOptions.h:36 > +class HTMLParserOptions { > +public: > + bool usePreHTML5ParserQuirks; > + unsigned maximumDOMTreeDepth; I find structs rarely stay that way for long... but OK.
Adam Barth
Comment 5 2013-01-07 14:31:17 PST
> I find structs rarely stay that way for long... but OK. The idea is that we'll end up copying this data structure from the main thread to the parser thread, which means we'll need to keep it simple enough to copy.
Adam Barth
Comment 6 2013-01-07 16:21:32 PST
Committed r139008: <http://trac.webkit.org/changeset/139008>
Note You need to log in before you can comment on or make changes to this bug.