jPlayer 2.3.0

[Mark Panaghiston]

jPlayer 2.3.0 has been released on http://jplayer.org/

Download the latest version here:
http://jplayer.org/download/

The release notes for the changes from the previous release are here:
http://jplayer.org/latest/release-notes/

Upgrading is seamless. Simply add the new jquery.jplayer.min.js and Jplayer.SWF files to your site.

It is recommended that you update to this version to remove a security vulnerability with the Flash SWF that enabled Cross Site Scripting (XSS) on your domain. Remember to delete any old copies of the Jplayer.swf file you might have on your site to eliminate the vulnerability.

New features:

• True full screen support with full window fallback.
• Keyboard controls.
• Time display reviewed and now per instance.
• Progress bar smoothing.
• Along with numerous bug fixes documented in the release notes.

This thread continues on from the previous development log for jPlayer 2.2.0, found here:
https://groups.google.com/d/topic/jplayer/zpin4vMzBVw/discussion

The development log of jPlayer 2.3.0 will continue in this thread.

Please start a new thread for support requests.

[Mark Panaghiston]

Added a new demo purely to demonstrate what happens without the pauseOther command in the play event.
http://www.jplayer.org/latest/demo-03-together/

[Mark Panaghiston]

jPlayer development 2.3.1 released on GitHub.

[2.3.1] Security Fix: The Flash SWF had a minor security vulnerability that enabled XSS (Cross Site Scripting). Reported by Eugene Dokukin. Security reference CVE-2013-2023.

Additional:

See also GitHub issue #162 for more info.

This patch is to stop other JavaScript commands, such as 'confirm' and 'prompt' from being passed in.

Believe that the remaining security issues are now closed, with the possible exception of the jQuery parameter to the Flash. This is the point of vulnerability, where it would be more secure to hard-code it to a known value... Since JavaScript might expand to include new JavaScript commands, which are not included in the blacklist.

Bah! Now I remember what I was going to do to solve that. I think another push is incoming.

[Mark Panaghiston]

jPlayer development 2.3.2 released on GitHub.

[2.3.2] Security Fix: Closed Flash SWF security vulnerability that enabled XSS (Cross Site Scripting). Reported by Eugene Dokukin. Security reference CVE-2013-2023. The jPlayer noConflict option is now restricted to strings that contain the term jQuery.
For example: lib.jQuery or myjQueryRocks.

Additional:

This now closes the security hole to future changes in JavaScript... And uses the security best practice of whitelists.

See also GitHub issue #162 for more info.

[Pau Garcia i Quiles]

Mark,

Could you please make ZIP files available for patch releases? Or at least tag the release in git? It is very difficult to package jPlayer otherwise, there is no clear reference (the commit log does not even mention a new version has been made available!)

Thank you

--
You received this message because you are subscribed to the Google Groups "jPlayer: HTML5 Audio & Video for jQuery" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jplayer+u...@googlegroups.com.
To post to this group, send email to jpl...@googlegroups.com.
Visit this group at http://groups.google.com/group/jplayer?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

[Jonathan2]

I definitely second that; another good reason is that I try and use http://cdnjs.com/ which is a fantastic cdn from Cloudflare which hosts the missing libraries that others miss.

They minify and make everything lovely.

Except, I've been told that the lack of tagging makes it impossible to update.

So, basically, it's good for a week or so, and then becomes outdated when the new point release comes along.

So, having 2.3.2 tagged as such would mean everyone could be in sync and safe from any fixed vulnerabilities.

[Mark Panaghiston]

OK I hear you both...

I had been using the 3rd number purely to distinguish between commits and so there was a reference in the release notes to how things developed and in what order. In many ways, the 3rd number is just my development changes that have been made public. With a use with caution warning on them. Some of the 3rd number updates are simply changing a default true to a default false. While others can be the whole keyboard control system. The bleeding edge changes have often only been tested specifically to their change... While I run many more tests on the minor updates (2nd number).

I hear you both though and I will begin introducing other tags with appropriate levels. For example, I might start introducing the 3rd number changes tags and then remove them once the 2nd number update occurs.

While on that thought, I will be removing the older tags pre 2.3.0 soon, since they have a security hole in them. That way they can no longer be downloaded in error.

This is my explanation from the download page:

Player uses the version system of Major.Minor.Patch, where both Major and Minor versions are released on this site in a ZIP file with a compiled minimised (min) file of the JavaScript. Development Patch versions are only released on GitHub, along with the Major and Minor versions. This approach allows us to develop jPlayer in a transparent and flexible manor without constantly updating the entire support site for each step in the development.

While this may continue to affect the main site in this manor, I will start adding in the tags you've requested.

[Pau Garcia i Quiles]

On Mon, May 20, 2013 at 2:36 PM, Mark Panaghiston <mark.pan...@gmail.com> wrote:

OK I hear you both...

I had been using the 3rd number purely to distinguish between commits and so there was a reference in the release notes to how things developed and in what order. In many ways, the 3rd number is just my development changes that have been made public. With a use with caution warning on them. Some of the 3rd number updates are simply changing a default true to a default false. While others can be the whole keyboard control system. The bleeding edge changes have often only been tested specifically to their change... While I run many more tests on the minor updates (2nd number).

I would really prefer if you had a master branch where development occurs and branches for each minor version. Patch releases would only introduce fixes and it would be done on the branches for each minor version.

For instance, for the current development you'd have:

master -- new features, changes of behavior for non-security/non-bugfix reasons, etc happen here

v2.3 -- 2.3.1, 2.3.2, 2.3.3, etc happen here. They are tagged. Changes in this branch are merged into master immediately to make sure fixes are not lost.

v2.2 -- Same as v2.3 branch but months ago; in addition to that, bugfixes for security bugs in v2.2, if v2.2 is still supported when the security bug is discovered.

v2.1 ...

v2.0 ...

For instance, I have backported to jPlayer 2.1 your fixes for all the security issues that were discovered since 2.1.0 was released. Debian requires this in the stable distribution. If a v2.1 branch would exist, I would gladly maintain it by committing only security fixes for the issues that may be discovered in the future, while Debian Wheezy is still supported (which should be about 2 years from now). I am sure other distributions (Fedora, SuSe, etc) would gladly maintain other branches.

 

I hear you both though and I will begin introducing other tags with appropriate levels. For example, I might start introducing the 3rd number changes tags and then remove them once the 2nd number update occurs.

That's a very bad idea. Really bad. For instance, in Debian we need to be able to reproduce the build from scratch, including obtaining the original sources. If you remove the 3rd number tags, that's no longer possible. Other projects keep those tags, why would you want to remove them?

 

While on that thought, I will be removing the older tags pre 2.3.0 soon, since they have a security hole in them. That way they can no longer be downloaded in error.

IMHO that's a bad idea too. I would just add a warning to the website: "versions older than 2.3.2 are affected by a variety of security bugs". That's what other projects do.

[Mark Panaghiston]

OK, I'll try and setup the branches. While I have used GitHub for a few years now, I do not really do much with it other than commit, tag and push. So bear with me and cross your fingers that I do not screw it all up.

I'll create a branch for v2.3 from the current master on my local and remote repos. The way it pans out ATM, the current v2.3 is the same as the master... Otherwise I suppose I'd need to checkout 2.3.0 and then merge in specific commits or something else that am not experienced with.

On thing that I wonder about is the version system... Two things:

1) The flash version is checked in the JavaScript, so the version number is always changing in the code. When merging a v2.3 into the master those numbers might get confused... Which leads onto my next issue...

2) The version record. I'd like the master development to have a number record too. Any suggestions? Something like 2.4pre.1

[Jonathan2]

On Monday, May 20, 2013 2:47:50 PM UTC+1, Pau Garcia i Quiles wrote:

 

For instance, I have backported to jPlayer 2.1 your fixes for all the security issues that were discovered since 2.1.0 was released. Debian requires this in the stable distribution.

I know this isn't really the right thread and a bit off-topic, but you're a "maintainer", yes?

On thing that's always hugely frustrated me about Linux distributions is that you spend the first half hour googling around the web for repos which won't give you obsolete software.

For example, "out of the box" on Ubuntu, I remember getting versions of phpmyadmin, nginx, ffmpeg, php etc that were stupidly out of date and not supported.

From what you're saying above, does that mean there is actually a deliberate policy in Linux repos to serve obsolete software? (for example, jplayer 2.1 is from way back in 2011).

If so, I suppose the obvious question might be .... why?! What am I missing here?

[Mark Panaghiston]

OK, I've created the branch v2.3 and the tag 2.3.3 in the jPlayer repo.

Please let me know if you notice any issues with the way I setup the branch.
I did the following:

git checkout - b v2.3
git push -u origin v2.3
git tag -a 2.3.2 -m "jPlayer 2.3.2"
git push --tags

I already have some development changes to commit... I'm treating them as a bug fix for the time being, since it relates to the Flash player not generating events... It never did produce these events anywayz, but I'm not adding them so it feels more like a bug fix than a new feature to me. After all, the events should always have been emulated by the flash.

So, I'll commit those changes to the v2.3 branch, push them and then merge and push with the master.

(while in v2.3 branch)

git commit -a -m "I done fings"
git push
git tag -a 2.3.3 -m "jPlayer 2.3.3"
git push --tags
git checkout master
git merge v2.3
git push

I think that I can use the shorthand git push since the local and remove branches line up, but I will soon find out and advise if I got too cocky and needed the explicit commands.

Plus, I'm not sure if I need to push and then push the tags, or if I could do them both in 1... Maybe a gitHub guru could advise on that.

[Mark Panaghiston]

jPlayer development 2.3.3 released on GitHub:

[2.3.3] Bug Fix: Added the following event emulation to the Flash MP3 player: playing, waiting, canplay and canplaythrough.

Additional:

This only affects the MP3 player in the Flash solution. (I hope to implement the change in the MP4 player in the next week or so.)

These events are of most benefit when trying to determine whether the mp3 media is playing or waiting for a download. The canplay event is emulated and simply fires just before playing event. The waiting event fires when the MP3 stops playing in order to buffer, and during the initial connection. The canplaythrough event fires when the the static mp3 file has completely downloaded.

GitHub Changes:

We now employ a master and version branch arrangement.

Currently we have the master and v2.3, and the branches will grow in future as the releases occur. The v2.2 below is an example.

master -- new features, changes of behaviour for non-security/non-bugfix reasons, etc happen here

v2.3 -- 2.3.1, 2.3.2, 2.3.3, etc happen here. They are tagged. Changes in this branch are merged into master immediately to make sure fixes are not lost.

v2.2 -- Same as v2.3 branch but months ago; in addition to that, bugfixes for security bugs in v2.2, if v2.2 is still supported when the security bug is discovered.

Final note...

Now I think of it, while you could class these missing events as a bug fix, they are not really a bug. They were an omission. I expect that only actual bugs will be added to old branch lines in future.

[Pau Garcia i Quiles]

Hello,

This is excellent news! I am already using this for getting 2.3.3 in Debian.

Thank you

As for versions for the master branch, 2.4pre1 may not be the best choice because lexicographically 2.4pre1 > 2.4 (i. e. the string comparison operators in most programming languages will do the opposite of what you want). Try adding a ~ or _, i. e. 2.4~pre1.

[Mark]

From the docs (http://jplayer.org/latest/developer-guide/)

$(function() { // executed when $(document).ready()
  $("#jpId").jPlayer( {
    ready: function () {
      $(this).jPlayer("setMedia", {
        m4v: "/media/myVideo.m4v", // Defines the m4v url
        ogv: "/media/myVideo.ogv" // Defines the counterpart ogv url
      }).jPlayer("play"); // Attempts to Auto-Play the media
    },
    solution: "flash, html", // Flash with an HTML5 fallback.
    supplied: "m4v, ogv",
    swfPath: "/scripts"
  });
});

On 27 May 2013 01:48, Jim From SD <jimf...@san.rr.com> wrote:

I am relatively new to this. I am working on an audio player and I realize that you cannot autostart an audio player on a mobile device, but how about on a "regular" web page, i.e. one being viewed from a desktop/laptop? I have a client that has a slideshow with music and he would like to be able to view the slideshow with music starting automatically on the website and he is OK with having people click a play button on a mobile device. I have found other solutions that allow you to specify something along the lines of "autostart: true" and the player then starts on a PC but does not on a mobile device, however there were other issues with both of the solutions I found. I could not find anyplace to add this parameter to jPlayer 2.3.0. Any suggestions? Thanks.

--

[Mark Panaghiston]

jPlayer 2.3.4 released on GitHub:

[2.3.4] Bug Fix: In the Flash MP3 player, cleared the waiting event timer on setMedia. Thus fixing erroneous waiting event generation when setMedia, then play, then setMedia.

This commit has been tagged 2.3.4 in the v2.3 branch and has been merged with the master branch.

The bug was unlikely to cause sensible command chains any problem, but decided to fix it as the waiting event would not be generated correctly if the following play command was giving within about 3 seconds.

[Mark Panaghiston]

jPlayer 2.3.5 fix released on GitHub:

[2.3.5] Bug Fix: The links in the Flash Context Menu (right click menu) now work. The Flash plugin has a bug with context menus over a video player, so a transparent Sprite was put over it.

This commit has been tagged 2.3.5 in the v2.3 branch and has been merged with the master branch.

Bah! The package.json file was not correctly updated. It still says 2.3.3 in it. There are so many things to do now just to change 6 lines of code! i will correct that in the next update.

[Pau Garcia i Quiles]

On Thu, May 30, 2013 at 12:52 AM, Mark Panaghiston <mark.pan...@gmail.com> wrote:

Bah! The package.json file was not correctly updated. It still says 2.3.3 in it. There are so many things to do now just to change 6 lines of code! i will correct that in the next update.

 Maybe using a build system (e. g. grunt) to automate this would be a good idea?

[Mark Panaghiston]

I have played a bit with grunt and considered using it...

Part of the problem here though is that my GitHub repo is nothing to do with my normal development/working area. I have been thinking of ways to improve that... My working area in a localhost working with PHP files and so on which make up the jplayer website... Along with that annoying url rewritting so that it is pretty... So I sort of want to work with the demo zip demo files in the working area... Which would be a good thing since they are currently not in the repo.

[Mark Panaghiston]

jPlayer 2.3.6 fix released on Github:

[2.3.6] Bug Fix: Changing the cssSelectorAncestor after instancing now updates the GUI to the current state. Bug reported by kusch in Issue #83.

This commit has been tagged 2.3.6 in the v2.3 branch and has been merged with the master branch.

Fixes a niche case where you are swapping the GUI association around during playback... The state of all the GUI elements now transfers onto the new GUI as you change the option.

I also fixed the version in the package.json file.

[Mark Panaghiston]

@ Pau Garcia: I think I'm getting myself tied up in knots with the versions.

Up till now I have been able to treat all of the changes as bug fixes, but I have a (minor) new feature to add. Part of my problem is:
1) I put the version into the code as part of an error check with the flash.
2) I add the version to the comment to make it obvious when someone asks for support.

I will spend time resolving conflicts since these will always be conflicting when i update v2.3 and then merge with the master... And which is correct? Since the new merge we want, but really the new merge starts becoming some other version in the master. EG., it is the merge of 2.4_pre.10 and 2.3.27 and becomes erm... 2.4_pre.11 in the process. I thin part of my problem was that I treat ever little change as a version. Maybe I need to relax a bit and treat the master as dev to 2.4 feature and just record in the release notes the 2.4_pre.5 did XYZ.

I'm thinking, or dropping adding the version number to the master development branch in this manner.

I only added it to the code for the flash version check, since some people in the past thought the Flash was cast in stone and never changed and used new JavaScript with an old Flash and wondered why nothing worked.

[Mark Panaghiston]

jPlayer dev 2.3.7, 2.3.8 and 2.3.9 pushed to github:

• [2.3.7] Bug Fix: Corrected the GUI bars click handlers so only a single event is processed. Affected the play and volume bars when decreasing the value. ie., The click was captured by both the playBar and the seekBar as the event propagated up the DOM. (Introduced by the 2.2.21 change.)
• [2.3.8] New Feature: Added support for Zepto 1.0 compiled with optional data module. You will need to manually edit the code to enable Zepto. It requires switching in/out the jQuery and Zepto lines of code at the start. Submitted by nuria.
• [2.3.9] Bug Fix: Multiple GUI bars are now enabled. The click events are now handled by the bar container, seekBar or volumeBar, and the click refers to itself through the event.currentTarget.

Additional...

2.3.7 and 2.3.9 ended up overlapping each other and did the same thing in different ways... 2.3.9 is king though and boiled down to the last line of this old thread - yes I do keep track of this stuff - honest!
https://groups.google.com/d/msg/jplayer/OGvBzu3z_b8/BrCiDnZJMsAJ

Quote:

In some ways, if the playbar was not registered in the way it is (with that return false;) then the seekbar would be capturing the event during the bubble phase and there would not be an issue at all.

NB: The return false issue was changed in 2.2.21

...And it turned out that event.currentTarget was the way to go once propagation was enabled.

2.3.8 is for anyone interested in using Zepto. You can comment out and in the 2 sets of lines in at the top of the jPlayer code to switch to Zepto. You will need Zepto 1.0+ compiled with the data module for it to work.

Just in case my comments are not bleeding obvious enough, the top of the code looks like this:

/* Support for Zepto 1.0 compiled with optional data module.
 * You will need to manually switch the 2 sets of lines in the code below.
 * Search terms: "jQuery Switch" and "Zepto Switch"
 */

(function (root, factory) {
    if (typeof define === 'function' && define.amd) {
        // AMD. Register as an anonymous module.
        define(['jquery'], factory); // jQuery Switch
        // define(['zepto'], factory); // Zepto Switch
    } else {
        // Browser globals
        factory(root.jQuery); // jQuery Switch
        // factory(root.Zepto); // Zepto Switch
    }
}(this, function ($, undefined) {


I could not think of a way to do it harmoniously without the need for a code change... At least, not with the AMD module support and not without prioritizing Zepto over jQuery... Actually I'd have make jQuery used if present or use Zepto... Since if jQuery was there you might aswell use it in unlikely case of having both jQuery and zepto.. but i am wandering off on a tangent.

[Pau Garcia i Quiles]

On Thu, May 30, 2013 at 11:27 PM, Mark Panaghiston <mark.pan...@gmail.com> wrote:

I think part of my problem was that I treat ever little change as a version. Maybe I need to relax a bit and treat the master as dev to 2.4 feature and just record in the release notes the 2.4_pre.5 did XYZ.

I'm thinking, or dropping adding the version number to the master development branch in this manner.

Yes, treating every little change as a version is not a good idea. You are releasing new patch versions almost daily! 

IMHO it's OK to release a new patch version for a single change if that change is a security fix but if not, just relax and wait until you have some more changes to release a new version. I. e. commit to git and push to github but do not change the version number and do not tag until you have some more changes (or more important bugfixes), then release.

BTW, the new feature you introduced in 2.3.8 (Zepto) should have gone into master and not into the 2.3 branch (it's not a bugfix).

This is good reading about git branching:

http://nvie.com/posts/a-successful-git-branching-model/

(I use a modified version of that myself and at work, a bit more oriented towards enterprise use)

[Mark Panaghiston]

jPlayer 2.3.10 pushed to github:

• [2.3.10] Feature Change: Zepto support is now automatic, except when used as an AMD module. The AMD module continues to require the manual code change for the AMD dependency.

jPlayer has now been added to The jQuery Plugin Registry:
http://plugins.jquery.com/jplayer/

2.3.10 allows you to use the jPlayer code and simply add either Zepto or jQuery to the page to cause the use of the appropriate library.

• jQuery on page - jQuery used.
• Zepto on page - Zepto used.
• Both jQuery and Zepto on page - jQuery used.
• Neither used - The usual errors for missing library.

[Mark Panaghiston]

With the release of jPlayer 2.4.0, this discussion now continues in that thread:
https://groups.google.com/d/topic/jplayer/t33euuON_Lg/discussion

[laz.br...@gmail.com]

Just making sure the MP4 player implementation is not forgotten since it's almost 2 month now.