Closed Bug 542889 Opened 15 years ago Closed 14 years ago

Planet.mozilla.org does not support open video

Categories

(Websites :: planet.mozilla.org, defect)

Product:
Websites
Component:
planet.mozilla.org
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: sarah, Assigned: reed)

References

(
URL
)

Details

Planet doesn't support open video content.  We are using open video on the mozilla blog so we need to have this compatible on planet.  This needs to be fixed.
Assignee: server-ops → nobody
Component: Server Operations → planet.mozilla.org
Product: mozilla.org → Websites
QA Contact: mrz → planet-mozilla-org
This used to work -- I think the planet software got updated, and the update suddenly stopped recognizing "unknown" elements.  It's not just the video element; I've noticed <figure> in some of my recent posts getting plaintext-splatted into Planet as well.
How quickly can we get this fixed?
It also might be <video> + <source> that's causing issues.
It mangles mine, and I use <video src>.
You mean <video src="..."></video> or <video><source src="..."></video>?  The latter is what we use so we can have mp4 fallbacks for lame (safari) browsers.
I specifically use <video src="..."></video>, no <source> at all.  Fallback behavior for no video support directs them to download a better browser.  :-)  I haven't yet spent time to make Safari et al. without the Xiph codecs installed do anything sensible.
We've been doing openvideo + codec fallback + flash fallbacks - most people don't notice.

Anyway...
It would be great to get this fixed ASAP -- I'm not actually sure who currently has access to update Planet stuff.  Reed, any hints?
Took a quick look around myself and not sure where that is actually done.
Sanitization is done in the feed parser.  But in any case, if you can gather up one or more test case, I'll fix it.
Thanks Sam... I was looking through config and filters.
Sam -

You can pull this feed as a test case if you want:

http://www.0xdeadbeef.com/weblog/feed/

I always have tons of <video> elements with <source> elements in it.  I don't use the raw <video src=""></video> way, but Jeff does.

Also I thought this was fixed once before in feedparser.py.
http://whereswalden.com/feed/atom/

for <video src=""></video> examples, as well as examples using <figure> as well that have been subjected to text-splatting.
Cam this be fixed?
I've pushed a fix to Planet Venus.  Let me know if there are still problems with it.

http://intertwingly.net/blog/2010/05/11/Venus-and-HTML5-Video
Do you know if that included support for <video><source/><fallback/></video>?  That's a lot of our use case.
I specifically tried it with the 0xdeadbeef and whereswalden feeds mentioned above, looking for video, source, and figure elements.  Yes, those work.

The feedparser is also a HTML sanitizer, and operates on a "whitelist" principle.  video, source, and figure are now whitelisted.  fallback is not. :-)

For the curious, search for _HTMLSanitizer in http://intertwingly.net/code/venus/planet/vendor/feedparser.py

If you are using escaped HTML (most Atom feeds, and virtually all RSS feeds), there may be a second sanitization performed:

http://intertwingly.net/code/venus/planet/vendor/html5lib/sanitizer.py

If you have specific things you need whitelisted, and have an example feed demonstrating what you want, let me know and I can add it to the list.
That's fantastic, thanks Sam!
r67252
Assignee: nobody → reed
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.