WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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+
Details
Formatted Diff
Diff
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-
Details
Formatted Diff
Diff
Fix the contentSecurityPolicy tests
(29.20 KB, patch)
2016-08-31 16:26 PDT
,
Ricky Mondello
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/117690334
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug