Bug 100710 – ENABLE(NEW_XML) isn't used by anyone and no one is actively working on it

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Adam Barth]

ENABLE(NEW_XML) isn't used by anyone and no one is actively working on it

[Adam Barth]

Created attachment 171333 [details]
Patch

[Maciej Stachowiak]

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?

[Adam Barth]

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.

[Maciej Stachowiak]

(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.

[Maciej Stachowiak]

I'm fine with doing this now and not waiting til February.

[Maciej Stachowiak]

Reopening based on previous comment.

[Eric Seidel (no email)]

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. ;(

[Maciej Stachowiak]

(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.

[Adam Barth]

> 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.

[Adam Barth]

Created attachment 183901 [details]
Patch for landing

[Build Bot]

Comment on attachment 183901 [details]
Patch for landing

Attachment 183901 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/16031463

[EFL EWS Bot]

Comment on attachment 183901 [details]
Patch for landing

Attachment 183901 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/16036443

[Adam Barth]

Created attachment 183906 [details]
Patch for landing

[WebKit Review Bot]

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

[WebKit Review Bot]

Comment on attachment 183906 [details]
Patch for landing

Clearing flags on attachment: 183906

Committed r140399: <http://trac.webkit.org/changeset/140399>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Mark Lam]

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.

[Mark Lam]

Build breakage fix landed in r140410: <http://trac.webkit.org/changeset/140410>.

[Adam Barth]

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...

[Eric Seidel (no email)]

Thank you Mark.