see patch
Created attachment 74765 [details] Patch
Attachment 74765 [details] did not build on win: Build output: http://queues.webkit.org/results/6296043
Created attachment 74772 [details] Patch
Comment on attachment 74772 [details] Patch Seems like eventually we should switch to using ::PathRemoveFileSpecW.
(In reply to comment #4) > (From update of attachment 74772 [details]) > Seems like eventually we should switch to using ::PathRemoveFileSpecW. PathRemoveFileSpecW wants to work in a buffer. So we would need to copy the path first into the buffer and then out of if. I like the current version more, but I can change if you like the other one more.
(In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 74772 [details] [details]) > > Seems like eventually we should switch to using ::PathRemoveFileSpecW. > PathRemoveFileSpecW wants to work in a buffer. So we would need to copy the path first into the buffer and then out of if. I like the current version more, but I can change if you like the other one more. I think if we used StringBuffer or Vector<UniChar> we could get away with only a single copy, which is probably even better than the current implementation. But making this change I think would warrant a separate patch.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (From update of attachment 74772 [details] [details] [details]) > > > Seems like eventually we should switch to using ::PathRemoveFileSpecW. > > PathRemoveFileSpecW wants to work in a buffer. So we would need to copy the path first into the buffer and then out of if. I like the current version more, but I can change if you like the other one more. > > I think if we used StringBuffer or Vector<UniChar> we could get away with only a single copy, which is probably even better than the current implementation. But making this change I think would warrant a separate patch. OK, I'll create a new patch in the next days.
Comment on attachment 74772 [details] Patch Rejecting patch 74772 from commit-queue. Failed to run "['./WebKitTools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=eseidel-cq-sl', 'build', '--no-clean', '--no-update', '--build-style=both']" exit_code: 2 Last 500 characters of output: g/RenderDataGrid.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2 CompileC /Projects/CommitQueue/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/RenderLayer.o /Projects/CommitQueue/WebCore/rendering/RenderLayer.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2 CompileC /Projects/CommitQueue/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/Frame.o /Projects/CommitQueue/WebCore/page/Frame.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2 (6 failures) Full output: http://queues.webkit.org/results/6387099
The commit-queue encountered the following flaky tests while processing attachment 74772 [details]: fast/workers/storage/use-same-database-in-page-and-workers.html inspector/timeline-event-dispatch.html Please file bugs against the tests. These tests were authored by beidson@apple.com, dumi@chromium.org, and yurys@chromium.org. The commit-queue is continuing to process your patch.
Comment on attachment 74772 [details] Patch Clearing flags on attachment: 74772 Committed r72808: <http://trac.webkit.org/changeset/72808>
All reviewed patches have been landed. Closing bug.