3.2 breaks ability to specify in settings: Click toggles visibility, while at same time, Hover temp shows (if hidden).

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Enable "Toggle the toolbar with the mouse" checkbox.

2. Hover mouse pointer over button (bookmarks toolbar appears). Move pointer 
away from button (bookmarks toolbar disappears). So far so good.

3. Hover pointer over button (toolbar appears). Actually click button. Move 
pointer away from button.

What is the expected output? What do you see instead?

Expected output: Toolbar state gets toggled - i.e. it's now visible, whereas 
before it wasn't. Or vice versa

Instead I see: Toolbar state doesn't get toggled. It stays off.

What version of the product are you using? On what operating system?

Hide BookmarksBar 3.2 (downloaded xpi from this site); Mac OS X 10.6.7; Firefox 
4.0.1

Please provide any additional information below.

I miss the old behavior. I'd like to be able to both:

- Hover the mouse pointer over the button when I want to see the bookmarks 
toolbar for a moment; moving it away to dismiss.

and, at the same time, whenever I wish

- Click the button, to change the state of the bookmarks toolbar, and have it 
become visible (until further notice), or hide (again, until further notice).

Please restore this functionality.

Thanks.

Original issue reported on code.google.com by e...@mechem.org on 19 May 2011 at 8:06

[GoogleCodeExporter]

In fact, this was a bug in previous versions. When hover mode was enabled, you 
could still toggle the toolbar with the button, but if you switched the toolbar 
to be visible, it would never hide, even when the mouse left the toolbox. 
(toolbox --> the area consisting of all toolbars, including menubar and tabbar)
You could not even see if you toggled it to be visible or hidden because while 
you clicked, you were hovering the button which forced the toolbar to be 
visible.
This behavior distracted some people and it wasn't clear to them how to fix 
this. Therefore, in recent versions, clicking the button is ignored in hover 
mode.

If I understand you right, you want to switch between temporary (i.e. while 
hovering) and permanent display. Maybe I can introduce a new preference, but 
I'm fixing some other issues atm.

Original comment by felix.kl...@gmail.com on 20 May 2011 at 10:06

• Changed state: Accepted
• Added labels: Component-Logic, Priority-Low, Type-Enhancement, Usability
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Huh!! And here I thought it was a feature :)   just goes to show.

No, not switch between -- have both at the same time.

I.e. -- I hover, and - bar shows, if not already showing.
and, if I click, it toggles state -- that is, new state *that will become 
evident as soon as I move mouse away* (if current state is visible).

Yeah, real confusing.   Not!   (for me)

Best of both worlds:

Hover - always available
at the same time as
Click to Toggle - always available

'twould be awesome to get that back.

Soon as you can, I understand the juggling prioritization :)

Original comment by e...@mechem.org on 20 May 2011 at 8:23

[GoogleCodeExporter]

It is really a bit confusing. Even if I know the code and the logic behind.

In previous versions, there was:
- "normal" mode, where you could trigger the toolbar with the button or the 
shortcut
- hover mode, where the toolbar got triggered by moving the mouse over the 
button
The bug was that normal mode wasn't disabled when you activated hover mode.
If I am not mistaken, this would mean:
- Toolbar is hidden
- You hovered the button --> toolbar is shown because of hover mode
- You clicked the button --> normal mode set toolbar to "visible", even it was 
already visible
- You left the button --> toolbar is still displayed because you switched in 
normal mode.
-------
- Toolbar is visible
- You hovered the button --> toolbar is shown because of hover mode, even if it 
was before
- You clicked the button --> normal mode tried to hide the toolbar, but it was 
still visible because the mouse is about the button
- You left the button --> toolbar is now hidden

Is this the effect you want to have? To me (and all the people that complained 
about this) it was more a bug than a feature. The toolbar didn't react directly 
to the click.
As the bug was fixed in one of the recent versions, I'm not sure how easy it is 
to reimplement this.

Original comment by felix.kl...@gmail.com on 20 May 2011 at 11:34

[GoogleCodeExporter]

Absolutely!

OK - the reason it's not confusing at all to me is -- I'm not "the button". I'm 
not 'the code'.

I'm me. I'm the active agent, I'm the one moving the mouse.

Most of the time -- the mouse is nowhere near that button.

It only gets there when *I* move it there.

With intention.

Intention to either:

A.)   'peek at' the bookmarks bar briefly - or quickly click a link that's 
there --- and then have it disappear back into invisibility, when I move the 
mouse away, and get back to browsing. Right?

Or --- because I've moved it there

B.)   *with the intent* to _make it visible_ for a little while. So that I can 
-- well, re-arrange things. Or click a few links - if I know I want to be 
exploring a few of them. Etc. etc.

It can only be 'confusing' for a short split second -- when I'm in mode 'B' - 
and I've either just clicked the button (but not pulled back away yet), or I'm 
just about to click the button. And in either case, only if I've *also* slowed 
down enough that -- the visual feedback my eyes are giving me about:
- the toolbar's visibility
- the button's (temporary) depressed (clicked) state
is somehow *more* in the forefront of my mind, than -- my actual intention, to 
*change for a while* the state of toolbar.

I.e. only with intention B.)  I'd have to both be *slow* _and_ *forgetful*, of 
my intention to either:
-- "make it stay visible for a while"
or
-- "make it go back to being hidden, like it normally is"

for me to get/be somehow, 'confused'.

See, this is perfect.

It actually *was* a bug, initially, but me? Heck, I thought -- Hey, *cool 
feature* :) :) :)

So. The imperfection of reality, synchronicity, serendipity, random stochastic 
whatever -- it brought about a condition where, here I am -- writing to you -- 
explaining *how* -- that bug, was actually a feature for me.

So --- I'd be most appreciative if you could - when you have some time -- think 
on a clean way to refactor your logic so that --- all the intended behaviors 
you have operating now, _plus_  this (to my mind, awesome, completely sensical) 
behavior is *also* available.

I've thought on the UI, while looking at it, and here's what I've come up with:

First, perhaps change the label on the checkbox, to say "Toggle toolbar on 
mouse hover".

And then, instead of switching out the entire set of Settings options below 
that, you could perhaps always have both groups of setttings UI controls 
present, but just dim the appropriate ones (one, the other, or neither (my 
mode)).

Like:

when "Toggle toolbar on mouse hover" is unchecked:

- the options right below it (and indented slightly), are dimmed - these being: 
radio button 'the "Bookmarks" button' vs. 'a toolbar', Delay in milliseconds 
field, and (*new*) checkbox "Also toggle toolbar automatically"  (with optional 
label 'may be confusing at first...' ;)

- all the other settings below all that, are not dimmed. These being: Toggle 
automatically checkboxes, At startup radio buttons, On opening anther window, 
and Enable Hotkey section

when "Toggle toolbar on mouse hover" is checked:

- options right below it become available, undimmed.
- all other settings below, are now dimmed.

-------   except (new 'both' mode) if "Also toggle toolbar automatically" 
checkbox is checked, then:
                                     - all other settings below, are now enabled (again).

Groovy? :)

cool.

lemme know what u think.....

Original comment by e...@mechem.org on 21 May 2011 at 1:14

[GoogleCodeExporter]

Ok, I think I got it.

All these changes to the options interface are similar to what I thought how to 
change it. But as I'm about to introduce some small new features, I wanted to 
reorganize the interface anyway. I'll have to see how to combine all these 
preferences.

Original comment by felix.kl...@gmail.com on 21 May 2011 at 11:09

[GoogleCodeExporter]

Cool, glad we're reasonably close to on the same page.

I'd be happy to test any dev versions - let me know.

Original comment by e...@mechem.org on 21 May 2011 at 6:07