Opened 9 years ago
Closed 8 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.
Subtickets
Attachments (1)
Change History (11)
comment:1 Changed 8 years ago by
| Milestone: | → 0.8.0 |
|---|
Changed 8 years ago by
| Attachment: | videojs_recommending_proprietary_software.png added |
|---|
comment:3 Changed 8 years ago by
Well, egg on my face: looks like this is as simple as upgrading video.js.
comment:4 Changed 8 years ago by
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 Changed 8 years ago by
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 Changed 8 years ago by
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 Changed 8 years ago by
| Owner: | set to Christopher Allan Webber |
|---|---|
| Status: | new → in_progress |
Claiming this one.... workin' on it.
comment:8 Changed 8 years ago by
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 Changed 8 years ago by
| Parent Tickets: | → 1095 |
|---|
comment:10 Changed 8 years ago by
| Owner: | Christopher Allan Webber deleted |
|---|---|
| Resolution: | → fixed |
| Status: | in_progress → closed |
This is closed out via #1095
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!