Closed
Bug 451004
Opened 16 years ago
Closed 15 years ago
New video/audio tags don't trigger content policies
Categories
(Core :: Audio/Video, defect, P1)
Core
Audio/Video
Tracking
()
RESOLVED
FIXED
People
(Reporter: jwkbugzilla, Assigned: cpearce)
References
()
Details
(Keywords: verified1.9.1, Whiteboard: [sg:want P1])
The new video and audio tags don't allow content policies (like Adblock Plus) to block their content, unlike the usual embed tags. nsHTMLMediaElement::InitializeDecoder should be a good place for a content policies call. A new content type will need to be added as well, I think nsIContentPolicy.TYPE_HTML_MEDIA will be sufficient - no need to distinguish between audio and video.
Updated•16 years ago
|
Version: 1.9.0 Branch → Trunk
When fixing please avoid traps like Bug 425946 ie, user should be able to avoid Windows Content Policy checking thru about:config. PS: If you have concerns about pref locking for corporate environs Please see bug 425946 Comment #16 and http://kb.mozillazine.org/Locking_preferences
Reporter | ||
Comment 2•16 years ago
|
||
Windows Content Policies are entirely unrelated. This is about making extensions like Adblock Plus "see" the new tags.
Comment 3•16 years ago
|
||
While "adblock" may sound like an optional "nice-to-have", various internal security mechanisms also use content policies. This must be fixed before we ship this feature.
Flags: blocking1.9.1?
Whiteboard: [sg:want P1]
Bug 451958 has a fix for this.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Comment 5•15 years ago
|
||
Case in point: bug 474744 is a security problem caused by this lack of content policy checks.
Reporter | ||
Comment 6•15 years ago
|
||
Confirmed that Minefield build 20090125 (with bug 451958 fixed) triggers content policies correctly for video/audio tags. Unfortunately, it also crashes (closes without opening Breakpad) on each page with video/audio tags, and that at least since build 20090123.
Comment 7•15 years ago
|
||
What platform? If this is windows, the crash may be because of the landing of bug 462082 which was fixed via the landing of bug 474937.
Reporter | ||
Comment 8•15 years ago
|
||
Yes, platform is Windows so I guess these bugs are the reason. I wanted to wait for the next nightly anyway before reporting that bug but I guess it will be fixed there.
Fixed by 451958.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 10•15 years ago
|
||
Since I have no access to 451958 will this fix make it into b3?
Reporter | ||
Comment 11•15 years ago
|
||
Given that code freeze for b3 was two days ago yet this patch didn't land for 1.9.1 yet - no, I don't think so.
Comment 12•15 years ago
|
||
This is a P1 blocker, which means we can't ship b3 without it.
Whiteboard: [sg:want P1] → [sg:want P1][needs 451958 to land on 1.9.1]
Keywords: fixed1.9.1
Whiteboard: [sg:want P1][needs 451958 to land on 1.9.1] → [sg:want P1]
Reporter | ||
Comment 13•15 years ago
|
||
Confirmed, fixed in "Gecko/20090203 Shiretoko/3.1b3pre" nightly.
Updated•15 years ago
|
Flags: wanted1.9.0.x-
You need to log in
before you can comment on or make changes to this bug.
Description
•