I am experiencing issues galore with 5.8 as it pertains to the html5 mode.
IF it wasn't for the fact that there was an issue in 5.7 regarding the mp4's I would not use 5.8
In fact 2 days before 5.8 was released I observed an issue with skins as well only to be told a band-aid fix(which works) and that the bug was slated to be fixed for v5.9. (see ticket #1495). I truly hope that this isn't true
The most serious issue, IMHO, with html5 is that when using JUST the html5 mode and not grouped with the flashmode it breaks in Safari
bc.. This doesn't work modes: [ {type: "html5"} ]
This works modes: [ {type: "html5"}, {type: "flash", src: "player.swf"} ]
I am testing now to see IF removing the [ ] in the first will make any changes. Just my luck that my client uses Safari and wants just html5mode
I've looked in to this further and the problem is the width of the timeSlider and timeSliderRail not being set correctly when the player is initialised in html5 mode.
Then when the player is resized, it works it out correctly. I guess a quick fix is to force a resize when loading.
We’ll be looking into these shortly. Obviously, these issues didn’t crop up in our testing. No need to submit a formal bug report; I’ve created a bug ticket to keep track of the issues.
I tested out Opera 11 with this page – http://developer.longtailvideo.com/player/trunk/fl5/js/test/examples/custom_skin.html , and none of the skins broke like this for me. Can you guys provide links to where you are having the issues?
Ethan, the bug happens on my side in Opera when controlbar.position is set to "bottom" or "top".
The reason the bug does not show up in your test page is that all of the jwplayers on the page do not have that property set, so they take the default value of "over".
Sorry, I can't seem to find the player.swf used on the page you linked to see if I can get something working in jsFiddle, and I am developing my project locally right now so I don't have a server I can throw a test page up to.
Hopefully this isn't too much of a hindrance to your efforts to squash the bug
You might want to edit that ticket. It also occurs when controlbar.position is set to "top" (in this case the shifted control elements just dissapear if there is no space above to display them). See here:
The same issue is also present in IE9(and Opera). The skin breaks in HTML5 mode. BTW i have set the conrtolbar.position to over, yet the skins break! (i have a somewhat modified version of bekle skin). I checked the link given by Ethan in his first post, and the first skin in that - Beelden broke for me. The volume and full screen buttons were coming below the controlbar's elapsed time text. I also have a test page here - http://61.246.241.36/jwp/jw58/t1.html You can see the skins would break in IE9 and OPERA, but not in CHROME, FIREFOX or SAFARI. In IE9, as i observed, the skins breaks everytime when you perform a seek. (i wonder how is it that a call to seek() is triggering, maybe a skin reload ?!). But that does not happen in Opera. I was so happy using 5.7, until i found out a little problem(among a few others) with the skins in HTML5 mode(the progress thumb would always stay a little behind the actual playback progress bar, so I updated to 5.8, and yay it was fixed! But wait ! Now i see issues with IE and Opera, Jesus!) Looking forward to read a reply to this. Rahul :)
@Pablo, maybe you should update the ticket to include IE9 as well, and that the position of cotrol-bar does not make any difference to the occurrence of this issue.
Hiding the controlbar with bc.. jwplayer().getPlugin('controlbar').hide(); at the onPlay-event and showing it again while moving the mouse, the timeslider of the controlbar is moved below. After resizing the browser window the controlbar is calculated correct again.
In http://www.ricosonntag.de/jwplayer/videoplayer.js is a method called "showControls" which unhides all controls and the js-playlist in case of some mouse-action or on some events.
If you start the video the controlbar and playlist gets hidden. If you move the mouse the controlbar is shown again but now its broken. The call to resize() (currently commented out) fixes this but may be not the right solution.
