Everything <track>-related should now be runtime enabled and off by default. Now we just need to turn ENABLE_VIDEO_TRACK on in order to enable it at runtime.
Created attachment 109866 [details] Patch
Comment on attachment 109866 [details] Patch Attachment 109866 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/9968043
Created attachment 109875 [details] fix for compiler () preferences
Comment on attachment 109875 [details] fix for compiler () preferences View in context: https://bugs.webkit.org/attachment.cgi?id=109875&action=review > Source/WebCore/html/track/WebVTTParser.cpp:343 > + || (m_token.name().size() == 1 && m_token.name()[0] == 'v')) Since the "then" has multiple lines, it should have braces around it.
Created attachment 109979 [details] Patch for landing
Comment on attachment 109979 [details] Patch for landing Rejecting attachment 109979 [details] from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 1 Last 500 characters of output: 877f0e7382b9b559f111f171bba375520ef5248d r96838 = a273abdc68360bbc95238d521de6d2973adc9a65 Done rebuilding .git/svn/refs/remotes/origin/master/.rev_map.268f45cc-cd09-0410-ab3c-d52691b4dbfc First, rewinding head to replay your work on top of it... Fast-forwarded master to refs/remotes/origin/master. Updating chromium port dependencies using gclient... ________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium' Updating webkit projects from gyp files... Full output: http://queues.webkit.org/results/9968314
Created attachment 109989 [details] Patch
Apparently 'webkit-patch land' doesn't work well with '--git-commit' because it changes the reviewer in the logs locally but not for the uploaded patch. Once the r+ was gone, there was nothing else I could do to land by hand. Requesting one more r+. Thanks!!
Comment on attachment 109989 [details] Patch Clearing flags on attachment: 109989 Committed r96861: <http://trac.webkit.org/changeset/96861>
All reviewed patches have been landed. Closing bug.
Why would you title a patch that enables a new feature "Adding parens in WebVTTParser.cpp to appease compiler preferences."? That's extremely confusing to people looking at the commit log to try to figure out why they can't compile.
I see - the WebKit/chromium/ChangeLog entry had the feature bit on top, but in the commit message it was buried under the WebCore/ChangeLog entry. A bit unfortunate - maybe it would have been better to land the compile fix on its own, then the feature flip?
Sorry about that. I figured that's all that was happening under that ChangeLog, but you are right. I'll be sure to change it once I figure out why the Windows release didn't like it.
We'll try this again after fixing some errors found.
Created attachment 110094 [details] Patch
Comment on attachment 110094 [details] Patch Attachment 110094 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10005126
Comment on attachment 110094 [details] Patch Clearing flags on attachment: 110094 Committed r96923: <http://trac.webkit.org/changeset/96923>