Closed Bug 451004 Opened 11 years ago Closed 11 years ago
New video/audio tags don't trigger content policies
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.
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
Windows Content Policies are entirely unrelated. This is about making extensions like Adblock Plus "see" the new tags.
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.
Whiteboard: [sg:want P1]
Assignee: nobody → chris
Depends on: 451958
Bug 451958 has a fix for this.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Case in point: bug 474744 is a security problem caused by this lack of content policy checks.
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.
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.
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: 11 years ago
Resolution: --- → FIXED
Since I have no access to 451958 will this fix make it into b3?
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.
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]
Whiteboard: [sg:want P1][needs 451958 to land on 1.9.1] → [sg:want P1]
Confirmed, fixed in "Gecko/20090203 Shiretoko/3.1b3pre" nightly.
You need to log in before you can comment on or make changes to this bug.