autoHide shorthand behaves differently as full syntax

[GoogleCodeExporter]

Demo:
http://flowplayer.blacktrash.org/test/autohide-shorthand.html

controls: {autoHide: {enabled: false}}: controlbar overlays screen

controls: {autoHide: false}: controlbar is placed below screen but still 
overlays canvas

controls: {autoHide: "never"}: controlbar overlays screen

So issue485 is not really fixed.

See also issue492.

The whole "new" autoHide implementation is seriously buggy, unreliable and 
yields constant nasty surprises.

Original issue reported on code.google.com by blacktrashproduct on 2 Jun 2012 at 9:13

[GoogleCodeExporter]

After taking a look into this :
- On your sample page I don't see any difference between the different options
- On local sample pages, none of the options work and the controlbar always 
behave as if autoHide:true was specified.

I will look more deeply into it today.
Kevin

Original comment by kevin.ma...@gmail.com on 4 Jun 2012 at 9:30

[GoogleCodeExporter]

You would have after hitting play. I have configured a red canvas and set 
autoBuffering to true, to make it more obvious. The problem is that you now 
would have to wait longer for all clips to start buffering (not all 3 start 
buffering synchroneously) - but I minimized it via clip.duration: 5.

Original comment by blacktrashproduct on 4 Jun 2012 at 12:02

[GoogleCodeExporter]

A custom label for the controlbar plugin changes the behaviour yet again:

controls: null,
TheControlbar: {
  url: '/path/to/flowplayer.controls-3.2.11.swf',
  autoHide: false
}

differs from:

controls: {
  autoHide: false
}

See: http://flowplayer.blacktrash.org/test/autohide-shorthand.html#player4

Original comment by blacktrashproduct on 4 Jun 2012 at 7:34

[GoogleCodeExporter]

"controls: {autoHide: false}" causes the same problem that "controls: 
{autoHide: 'fullscreen'}". The video is repositionated because the controls 
will always be displayed instead of behing able to hide. So, with fit scaling 
and no autoHide, the clip has less height to fill and we can see the canvas 
appear.

It is definately not a defect but a normal behaviour. I believe it's always 
been this way, however if it appears like a non-wanted behaviour to you we can 
make the change.

Original comment by kevin.ma...@gmail.com on 7 Jun 2012 at 1:47

[GoogleCodeExporter]

I don't want to change anything. I'm trying to make sense of the autoHide 
properties and their shorthands.

imho

autoHide: {enabled: false}
autoHide: false
autoHide: 'never'

should do the same thing - but they don't. Same for a customized controlbar 
label. Otherwise why have the shortcuts? I would not call inconsistent behavior 
"normal", unless it's meant as snide remark on the quality of the project ;-)

First of all it would be good to to establish what the desired behavior 
_should_ be. It would be nice if Anssi could make a decision - perhaps next 
year? ;-)

Original comment by blacktrashproduct on 7 Jun 2012 at 6:10

[GoogleCodeExporter]

Quite complex one, the default autohide config which works across multiple 
features is

when you set the state, enabled property is set to true if the value is not 
"never". fullscreenOnly property is activated if the state value is "fullscreen"

upon obtaining the state value for internal purposes, if enabled is set to 
false, the value is "never", if fullscreenOnly is activated its state is 
"fullscreen" otherwise it will return "always"

in the controlbar its custom autohide config works as such

if the value of audihide is a string value set the state value to this, 
therefore "never", "always", "fullscreen"
if the value is true or false, set the enabled value to either true or false, 
however the fullscreenOnly values are inverted so false when autohide is true, 
and true if autohide is false however that wont have any effect. 

basically setting the properties at the top level sets the state, enabled and 
fullscreenOnly properties internally. for the sake of confusion, id just set 
the configs directly. 

make sense ? 

Original comment by electrot...@gmail.com on 18 Jun 2012 at 4:03

[GoogleCodeExporter]

It makes sense as a possible technical explanation of a bug. And then it does 
not. I can deduct the (currently undocumented) enabled logic, but:

At the very least autoHide: "never" and autoHide: false should do the same 
thing, but they don't. Plus the behavior differs when you relabel the plugin. 
This is not related to `enabled'. These are direct shorthands. The bug 
manifests itself not in the controlbar's autoHiding behavior but how the 
container space is handled. Please check the demos.

And the consistency of the plugins API is broken anyway, since autoHide was 
"globalized" (in itself a good idea) for other stuff than the controlbar plugin 
- issue492.

From the UI perspective this looks completely haphazard and inconsistent.

Original comment by blacktrashproduct on 19 Jun 2012 at 3:23

[GoogleCodeExporter]

I know what the issue is and its regards to the fullscreenonly property being 
used to know where to position the screen. unfortunately there is no way to 
update fullscreenonly when setting the enabled property. and only one of those 
options leaves fullscreenonly to true. Its checking if fullscreenonly is false 
to resize the screen. 

Original comment by electrot...@gmail.com on 20 Jun 2012 at 2:12

[GoogleCodeExporter]

fixed in these versions

https://dl.dropbox.com/u/3394987/flowplayer-3.2.11.zip
https://dl.dropbox.com/u/3394987/flowplayer.controls-3.2.11.zip

it needed to handle the fullscreenOnly property better which is deterimined for 
screen positioning. 

Original comment by electrot...@gmail.com on 20 Jun 2012 at 9:01

[GoogleCodeExporter]

this might have affected the dock, let me test ;)

Original comment by electrot...@gmail.com on 21 Jun 2012 at 7:38

[GoogleCodeExporter]

dock is fine so all good to go

Original comment by electrot...@gmail.com on 21 Jun 2012 at 8:37

[GoogleCodeExporter]

dock is fine so all good to go

Original comment by electrot...@gmail.com on 21 Jun 2012 at 8:37

[GoogleCodeExporter]

closing this for now. 

Original comment by dani...@electroteque.org on 22 Jun 2012 at 5:17

• Changed state: Fixed

[GoogleCodeExporter]

The fix is buggy: see issue605

Original comment by blacktrashproduct on 3 Jul 2012 at 8:07