RESOLVED FIXED 161424
Break pluginReplacementEnabled into youTubeFlashPluginReplacementEnabled and quickTimePluginReplacementEnabled
https://bugs.webkit.org/show_bug.cgi?id=161424
Summary Break pluginReplacementEnabled into youTubeFlashPluginReplacementEnabled and ...
Ricky Mondello
Reported 2016-08-30 22:09:29 PDT
Break pluginReplacementEnabled into youTubeFlashPluginReplacementEnabled and quickTimePluginReplacementEnabled
Attachments
First attempt (21.57 KB, patch)
2016-08-30 22:23 PDT, Ricky Mondello
eric.carlson: review+
Rename a member function, fix a *, hope it builds (21.54 KB, patch)
2016-08-31 11:25 PDT, Ricky Mondello
dino: review+
commit-queue: commit-queue-
Fix the contentSecurityPolicy tests (29.20 KB, patch)
2016-08-31 16:26 PDT, Ricky Mondello
no flags
Ricky Mondello
Comment 1 2016-08-30 22:23:35 PDT
Created attachment 287484 [details] First attempt
Tim Horton
Comment 2 2016-08-30 23:35:21 PDT
Comment on attachment 287484 [details] First attempt View in context: https://bugs.webkit.org/attachment.cgi?id=287484&action=review > Source/WebCore/Modules/plugins/QuickTimePluginReplacement.mm:118 > +bool QuickTimePluginReplacement::isEnabledForSettings(const Settings* settings) Should this be "isEnabledBySettings"? Not sure. > Source/WebCore/Modules/plugins/YouTubePluginReplacement.cpp:349 > +bool YouTubePluginReplacement::isEnabledForSettings(const WebCore::Settings *settings) Star's on the wrong side. > Source/WebCore/html/HTMLPlugInElement.cpp:378 > if (m_pluginReplacement) > return true; Not familiar with this code; is there any case where we'll take this path when we would have previously bailed because of the setting? > Source/WebCore/testing/InternalSettings.idl:61 > + [RaisesException] void setYouTubeFlashPluginReplacementEnabled(boolean enabled); I hope the next patch adds a layout test that exercises this!
Eric Carlson
Comment 3 2016-08-31 10:08:41 PDT
Comment on attachment 287484 [details] First attempt View in context: https://bugs.webkit.org/attachment.cgi?id=287484&action=review r=me as long as you get it to compile before submitting :-) >> Source/WebCore/html/HTMLPlugInElement.cpp:378 >> return true; > > Not familiar with this code; is there any case where we'll take this path when we would have previously bailed because of the setting? Maybe not a huge concern, but this change means that the setting can't turned off after a replacement has been created. Maybe something like this instead? if (m_pluginReplacement) return m_pluginReplacement->isEnabledForSettings(document().settings())
Ricky Mondello
Comment 4 2016-08-31 11:25:09 PDT
Created attachment 287523 [details] Rename a member function, fix a *, hope it builds It's not clear why my first attempt didn't build. Maybe due to generated code?
Ricky Mondello
Comment 5 2016-08-31 12:55:47 PDT
Dean and I think that the failure is an EWS issue. Dean said he's seen this before when changing Internal settings. I'm going to put the second patch up for review.
Dean Jackson
Comment 6 2016-08-31 12:58:21 PDT
(In reply to comment #5) > Dean and I think that the failure is an EWS issue. Dean said he's seen this > before when changing Internal settings. I'm going to put the second patch up > for review. Yeah. The build error is saying that JSInternalSettingsGenerated.cpp is still trying to compile something that is no longer in the IDL, so it looks like EWS isn't regenerating that file.
Tim Horton
Comment 7 2016-08-31 12:59:48 PDT
(In reply to comment #6) > (In reply to comment #5) > > Dean and I think that the failure is an EWS issue. Dean said he's seen this > > before when changing Internal settings. I'm going to put the second patch up > > for review. > > Yeah. The build error is saying that JSInternalSettingsGenerated.cpp is > still trying to compile something that is no longer in the IDL, so it looks > like EWS isn't regenerating that file. This is a longstanding problem with removing things from that file.
Ricky Mondello
Comment 8 2016-08-31 16:26:39 PDT
Created attachment 287557 [details] Fix the contentSecurityPolicy tests
WebKit Commit Bot
Comment 9 2016-08-31 17:00:54 PDT
Comment on attachment 287557 [details] Fix the contentSecurityPolicy tests Clearing flags on attachment: 287557 Committed r205271: <http://trac.webkit.org/changeset/205271>
WebKit Commit Bot
Comment 10 2016-08-31 17:03:38 PDT
Comment on attachment 287523 [details] Rename a member function, fix a *, hope it builds Rejecting attachment 287523 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'apply-attachment', '--no-update', '--non-interactive', 287523, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit Last 500 characters of output: esting/InternalSettings.h Hunk #1 FAILED at 91. Hunk #2 FAILED at 157. 2 out of 2 hunks FAILED -- saving rejects to file Source/WebCore/testing/InternalSettings.h.rej patching file Source/WebCore/testing/InternalSettings.idl Hunk #1 FAILED at 57. 1 out of 1 hunk FAILED -- saving rejects to file Source/WebCore/testing/InternalSettings.idl.rej Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force', '--reviewer', u'Dean Jackson']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit Full output: http://webkit-queues.webkit.org/results/1983339
Anne van Kesteren
Comment 11 2023-10-30 09:26:38 PDT
As per comment 9 the code landed here. Not sure all of it did, but at this point that's probably best tracked from a new report.
Radar WebKit Bug Importer
Comment 12 2023-10-30 09:27:14 PDT
Note You need to log in before you can comment on or make changes to this bug.