RESOLVED FIXED 155413
<attachment> should be a runtime-enabled feature
https://bugs.webkit.org/show_bug.cgi?id=155413
Summary <attachment> should be a runtime-enabled feature
Dean Jackson
Reported 2016-03-13 16:20:29 PDT
<attachment> should be a runtime-enabled feature
Attachments
Patch (12.35 KB, patch)
2016-03-13 16:43 PDT, Dean Jackson
no flags
Patch (27.35 KB, patch)
2016-03-13 17:21 PDT, Dean Jackson
sam: review+
buildbot: commit-queue-
Patch (26.82 KB, patch)
2016-03-13 17:49 PDT, Dean Jackson
no flags
Patch (28.29 KB, patch)
2016-03-13 17:55 PDT, Dean Jackson
no flags
Patch (28.32 KB, patch)
2016-03-13 18:01 PDT, Dean Jackson
no flags
Archive of layout-test-results from ews101 for mac-yosemite (763.64 KB, application/zip)
2016-03-13 18:07 PDT, Build Bot
no flags
Dean Jackson
Comment 1 2016-03-13 16:38:23 PDT
Dean Jackson
Comment 2 2016-03-13 16:43:59 PDT
Tim Horton
Comment 3 2016-03-13 16:50:14 PDT
Comment on attachment 273906 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=273906&action=review Should we have a test for the default behavior of each of these flags? (and to make sure that it actually disables it? since surely we have tests that enable it). Also, are you planning on writing the code to make the existing tests tests turn it on when you switch the default to NO? > Source/WebKit/mac/WebView/WebView.mm:2518 > + settings.setAttachmentElementEnabled([preferences attachmentElementEnabled]); So there was already a WebCore setting? I wonder how well it works!
Dean Jackson
Comment 4 2016-03-13 17:18:36 PDT
Comment on attachment 273906 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=273906&action=review >> Source/WebKit/mac/WebView/WebView.mm:2518 >> + settings.setAttachmentElementEnabled([preferences attachmentElementEnabled]); > > So there was already a WebCore setting? I wonder how well it works! It works in my testing :)
Dean Jackson
Comment 5 2016-03-13 17:19:36 PDT
(In reply to comment #3) > Comment on attachment 273906 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=273906&action=review > > Should we have a test for the default behavior of each of these flags? (and > to make sure that it actually disables it? since surely we have tests that > enable it). > > Also, are you planning on writing the code to make the existing tests tests > turn it on when you switch the default to NO? Actually a new patch is coming that does both of these. You already wrote a test to exercise disabling. That's just now the default. Watch this space.
Dean Jackson
Comment 6 2016-03-13 17:21:22 PDT
Dean Jackson
Comment 7 2016-03-13 17:49:41 PDT
Dean Jackson
Comment 8 2016-03-13 17:55:17 PDT
Dean Jackson
Comment 9 2016-03-13 18:01:01 PDT
Build Bot
Comment 10 2016-03-13 18:06:58 PDT
Comment on attachment 273908 [details] Patch Attachment 273908 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/973748 New failing tests: editing/pasteboard/copy-paste-attachment.html editing/pasteboard/drag-and-drop-attachment-contenteditable.html
Build Bot
Comment 11 2016-03-13 18:07:01 PDT
Created attachment 273914 [details] Archive of layout-test-results from ews101 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-yosemite Platform: Mac OS X 10.10.5
Dean Jackson
Comment 12 2016-03-13 18:09:31 PDT
Csaba Osztrogonác
Comment 13 2016-03-17 06:01:22 PDT
(In reply to comment #12) > Committed r198088: <http://trac.webkit.org/changeset/198088> It broke the Apple Mac cmake build: /Volumes/Data/slave/elcapitan-cmake-debug/build/Source/WebKit/mac/WebView/WebView.mm:2515:14: error: no member named 'setAttachmentElementEnabled' in 'WebCore::Settings' settings.setAttachmentElementEnabled([preferences attachmentElementEnabled]); ~~~~~~~~ ^
Csaba Osztrogonác
Comment 14 2016-03-17 06:01:51 PDT
Note You need to log in before you can comment on or make changes to this bug.