ENABLE(NEW_XML) isn't used by anyone and no one is actively working on it
Created attachment 171333 [details] Patch
Last time we discussed this on webkit-dev, the conclusion was: "There's no urgency in removing it. If you're serious about working on it, perhaps we should keep it around for another six months." <http://lists.webkit.org/pipermail/webkit-dev/2012-August/022088.html> Has something changed to make it more urgent to remove this code faster?
Oh, I didn't realize that was the conclusion of the thread. I'm happy to wait until the end of February to remove this code.
(In reply to comment #3) > Oh, I didn't realize that was the conclusion of the thread. I'm happy to wait until the end of February to remove this code. I'd assumed it was your conclusion and did not comment further because it seemed like a fine approach.
I'm fine with doing this now and not waiting til February.
Reopening based on previous comment.
Comment on attachment 171333 [details] Patch Wow. So much code. This is obviously only the added files, and none of the abstractions which make the HTML parser so ugly. ;(
(In reply to comment #7) > (From update of attachment 171333 [details]) > Wow. So much code. This is obviously only the added files, and none of the abstractions which make the HTML parser so ugly. ;( Note that a number of these abstractions are used by WebVTT too, so let's not be too hasty in getting rid of them.
> Note that a number of these abstractions are used by WebVTT too, so let's not be too hasty in getting rid of them. Yes, we'll need to refactor the VTT parser a bit as we continue to untangle things. The good news is that the VTT parser doesn't really require all this machinery. We just used it because it was convenient at the time.
Created attachment 183901 [details] Patch for landing
Comment on attachment 183901 [details] Patch for landing Attachment 183901 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/16031463
Comment on attachment 183901 [details] Patch for landing Attachment 183901 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/16036443
Created attachment 183906 [details] Patch for landing
Comment on attachment 183906 [details] Patch for landing Rejecting attachment 183906 [details] from commit-queue. New failing tests: fast/forms/formmethod-attribute-input-html.html Full output: http://queues.webkit.org/results/16045425
Comment on attachment 183906 [details] Patch for landing Clearing flags on attachment: 183906 Committed r140399: <http://trac.webkit.org/changeset/140399>
All reviewed patches have been landed. Closing bug.
r140399: <http://trac.webkit.org/changeset/140399> broke mac builds (depending on the environment set up on the bot). See: http://build.webkit.org/builders/Apple%20Lion%20Debug%20%28Build%29/builds/10816 The breakage is due to a change in the path for finding CharacterReferenceParserInlines.h in the Xcode project file. The entry for CharacterReferenceParserInlines.h was removed and readied with a different path that cause the breakage. I'm now doing a local build to verify the fix (i.e. to restore the path before the change in r140399). Once verified, I'll land it to green the bots.
Build breakage fix landed in r140410: <http://trac.webkit.org/changeset/140410>.
Sorry about the breakage. I must have messed up the xcodeproj file when I was trying to remove these files. Thanks for fixing my mess...
Thank you Mark.