RESOLVED FIXED Bug 155588
CachedResource::MediaResource types shouldn't be blocked due to mixed-content.
https://bugs.webkit.org/show_bug.cgi?id=155588
Summary CachedResource::MediaResource types shouldn't be blocked due to mixed-content.
Jer Noble
Reported 2016-03-17 10:52:16 PDT
CachedResource::MediaResource types shouldn't be blocked due to mixed-content.
Attachments
Patch (2.29 KB, patch)
2016-03-17 11:23 PDT, Jer Noble
dbates: review+
Patch for landing (2.32 KB, patch)
2016-03-17 11:46 PDT, Jer Noble
no flags
Follow-up patch (2.54 KB, patch)
2016-03-22 16:53 PDT, Jer Noble
no flags
Jer Noble
Comment 1 2016-03-17 11:23:22 PDT
Jer Noble
Comment 2 2016-03-17 11:24:47 PDT
Daniel Bates
Comment 3 2016-03-17 11:34:16 PDT
Comment on attachment 274302 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=274302&action=review > Source/WebCore/ChangeLog:10 > + The Mixed Content spec specifically allows (with certain restrictions) loads of <image>, > + <video>, and <audio> resources from mixed-content origins, albeit with warnings. For your consideration, I suggest that we explicitly provide either a versioned link to the Mixed Content spec or an unversioned link and explicitly mention the type of spec (Editor Draft/CR) and a date. This will make it straightforward to understand the state of the spec when we made this change should the spec change in the future. One example of a ChangeLog that references a spec is <http://trac.webkit.org/changeset/197944>. Another example is <http://trac.webkit.org/changeset/198115>. > Source/WebCore/loader/cache/CachedResourceLoader.cpp:291 > + // https://w3c.github.io/webappsec-mixed-content/#category-optionally-blockable Please add the date of this draft or use a versioned link and explicitly mention the section name.
Daniel Bates
Comment 4 2016-03-17 11:38:07 PDT
Comment on attachment 274302 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=274302&action=review > Source/WebCore/ChangeLog:12 > + No new tests, fixes existing test: http/tests/security/mixedContent/resources/frame-with-insecure-audio-video.html This is the not a test, it is a resource loaded by a test. The test that you are fixing is http/tests/security/mixedContent/insecure-audio-video-in-main-frame.html.
Jer Noble
Comment 5 2016-03-17 11:46:12 PDT
Created attachment 274304 [details] Patch for landing
WebKit Commit Bot
Comment 6 2016-03-18 12:05:03 PDT
Comment on attachment 274304 [details] Patch for landing Clearing flags on attachment: 274304 Committed r198436: <http://trac.webkit.org/changeset/198436>
Jer Noble
Comment 7 2016-03-22 16:53:51 PDT
Reopening to attach new patch.
Jer Noble
Comment 8 2016-03-22 16:53:54 PDT
Created attachment 274702 [details] Follow-up patch
Brent Fulgham
Comment 9 2016-03-22 16:57:31 PDT
Comment on attachment 274702 [details] Follow-up patch r=me.
WebKit Commit Bot
Comment 10 2016-03-22 17:47:43 PDT
Comment on attachment 274702 [details] Follow-up patch Clearing flags on attachment: 274702 Committed r198566: <http://trac.webkit.org/changeset/198566>
Michael Catanzaro
Comment 11 2016-03-23 14:35:56 PDT
How did we fail to notice the test was broken? :/ Why are there no changes to the test expectations?
Jer Noble
Comment 12 2016-03-23 15:24:43 PDT
(In reply to comment #11) > How did we fail to notice the test was broken? :/ Why are there no changes > to the test expectations? EFL and GTK both have that test marked as failing. If it now passes again, we should probably remove that TestExpectation.
Note You need to log in before you can comment on or make changes to this bug.