RESOLVED FIXED 106256
HTMLTreeBuilder should not depend on Frame
https://bugs.webkit.org/show_bug.cgi?id=106256
Summary HTMLTreeBuilder should not depend on Frame
Adam Barth
Reported 2013-01-07 14:32:52 PST
HTMLTreeBuilder should not depend on Frame
Attachments
Patch (22.48 KB, patch)
2013-01-07 14:37 PST, Adam Barth
no flags
Patch for landing (21.08 KB, patch)
2013-01-07 16:38 PST, Adam Barth
no flags
Adam Barth
Comment 1 2013-01-07 14:37:58 PST
Eric Seidel (no email)
Comment 2 2013-01-07 14:46:20 PST
Comment on attachment 181569 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=181569&action=review I'm slightly confused as to why you changed the test. But otherwise this looks fine. I think you should move to a more explicit method name for getting the right options before landing. > Source/WebCore/html/parser/HTMLMetaCharsetParser.cpp:44 > + : m_tokenizer(HTMLTokenizer::create(HTMLParserOptions())) // No pre-HTML5 parser quirks. This feels a bit odd. Maybe we should give it a better name? Like HTMLParserOptions::defaultOptions()? or HTMLParserOptions::allOptionsDisabled()? > Source/WebCore/html/parser/HTMLParserOptions.h:44 > , maximumDOMTreeDepth(0) Is 0 the value you want for "default" in my previous comment? That's part of where my confusion comes from. It's not clear what the empty/default constructor is supposed to return there.
Adam Barth
Comment 3 2013-01-07 14:54:34 PST
> I'm slightly confused as to why you changed the test. Previously, the HTMLTreeBuilder would pull the "is scripting enabled" bit from the Frame. Now, we push the information when we start parsing. That means if the Frame changes its mind between when it starts parsing and when the <noscript> tag gets processed, we'll parse the <noscript> tag differently. In this specific case, the overridePreference API on testRunner is twiddling the "is scripting enabled" bit on the Frame (really on the Frame's Page's Settings). > > Source/WebCore/html/parser/HTMLMetaCharsetParser.cpp:44 > > + : m_tokenizer(HTMLTokenizer::create(HTMLParserOptions())) // No pre-HTML5 parser quirks. > > This feels a bit odd. Maybe we should give it a better name? Like HTMLParserOptions::defaultOptions()? or HTMLParserOptions::allOptionsDisabled()? Good idea. > > Source/WebCore/html/parser/HTMLParserOptions.h:44 > > , maximumDOMTreeDepth(0) > > Is 0 the value you want for "default" in my previous comment? That's part of where my confusion comes from. It's not clear what the empty/default constructor is supposed to return there. Yeah, we should probably use the default value from Settings. I'll fix that before landing too.
Eric Seidel (no email)
Comment 4 2013-01-07 14:55:59 PST
(In reply to comment #3) > > > Source/WebCore/html/parser/HTMLMetaCharsetParser.cpp:44 > > > + : m_tokenizer(HTMLTokenizer::create(HTMLParserOptions())) // No pre-HTML5 parser quirks. > > > > This feels a bit odd. Maybe we should give it a better name? Like HTMLParserOptions::defaultOptions()? or HTMLParserOptions::allOptionsDisabled()? > > Good idea. You could also just construct a HTMLParserOptions as normal here, and then twiddle the one bit you care about. That would also be clearer.
Eric Seidel (no email)
Comment 5 2013-01-07 14:56:18 PST
In general I'm not a big fan of HTMLParserOptions have a default constructor or any smarts of its own. :)
Adam Barth
Comment 6 2013-01-07 15:18:16 PST
> In general I'm not a big fan of HTMLParserOptions have a default constructor or any smarts of its own. :) Ok, I'll remove the default constructor. I agree that it's likely to be misused.
Adam Barth
Comment 7 2013-01-07 16:38:15 PST
Created attachment 181597 [details] Patch for landing
WebKit Review Bot
Comment 8 2013-01-07 17:23:04 PST
Comment on attachment 181597 [details] Patch for landing Clearing flags on attachment: 181597 Committed r139020: <http://trac.webkit.org/changeset/139020>
WebKit Review Bot
Comment 9 2013-01-07 17:23:08 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.