Opened 10 years ago

Closed 10 years ago

#918 closed defect (fixed)

video.js recommending Adobe Flash and Chrome in some browsers

Reported by: Christopher Allan Webber Owned by:
Priority: critical Milestone: 0.8.0
Component: programming Keywords:
Cc: Parent Tickets: 1095

Description

Even though we have our own fallback message (recommending FireFox at the moment), it looks like on OSX with Safari users are seeing video.js' own recommendation, which seems to be to recommend Flash and Chrome.

That is absolutely unacceptable. We need to figure out a way to prevent that recommendation.

Attachments (1)

videojs_recommending_proprietary_software.png (122.0 KB ) - added by Christopher Allan Webber 10 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 by Christopher Allan Webber, 10 years ago

Milestone: 0.8.0

by Christopher Allan Webber, 10 years ago

comment:2 by Christopher Allan Webber, 10 years ago

I've attached a screenshot (thanks Jessica for taking) above.

I'm going to file an issue on their tracker... hopefully they can respond nicely! But I suppose, worst comes to worst, it would not be hard to maintain a fork that just removes that text. I would really prefer not to do that though. Hopefully we can get this resolved upstream!

Last edited 10 years ago by Christopher Allan Webber (previous) (diff)

comment:3 by Christopher Allan Webber, 10 years ago

Well, egg on my face: looks like this is as simple as [upgrading video.js](https://github.com/videojs/video.js/issues/1579).

Version 0, edited 10 years ago by Christopher Allan Webber (next)

comment:4 by Christopher Allan Webber, 10 years ago

Part of the problem is that this isn't a git submodule, it's actually checked into git (which sucks, we shouldn't be doing this). Seeing what I can do to fix this.

comment:5 by Christopher Allan Webber, 10 years ago

There's no way to make this a git submodule either; the source isn't "simply javascript", it requires some complex node.js dependencies that we cannot possibly expect MediaGoblin users to have to wade through.

It would be good to have a script that populates extlib/ related projects like this from tarballs if they are complicated for the user to build... that seems a prerequisite to close this out.

comment:6 by Christopher Allan Webber, 10 years ago

An easier way to do that would be to use the Makefile to populate extlib... that would make the makefile mandatory though.

Another way would be to add a devtools/update_extlib.sh script.

comment:7 by Christopher Allan Webber, 10 years ago

Owner: set to Christopher Allan Webber
Status: newin_progress

Claiming this one.... workin' on it.

comment:8 by Christopher Allan Webber, 10 years ago

Another way to do it would be recursive makefiles, where the secondary extlib-populating makefile is simple and does not rely on the former make or automake at all.

Then again, some would say that recursive makes should be considered harmful... I'm not sure that's such a problem in our case though.

comment:9 by Christopher Allan Webber, 10 years ago

Parent Tickets: 1095

comment:10 by Christopher Allan Webber, 10 years ago

Owner: Christopher Allan Webber removed
Resolution: fixed
Status: in_progressclosed

This is closed out via #1095

Note: See TracTickets for help on using tickets.