Showing all the bookmarks has very little to do with staring, yet when bookmarks button on clicked, also star button is highlighted. And, if star is hovered, also the bookmarks button is. It is hard to understand the combination and what is tried to be achieved with the combined button.

Moving the star button back to the URL bar (where it belongs, IMO) would solve problem. ;) Though I understand the reasoning behind moving the star next to the toolbar button, I don't think the case is strong enough to justify the confusion caused by this move. So please, consider moving it back.

(In reply to Olli Pettay [:smaug] from comment #0) > Showing all the bookmarks has very little to do with staring, yet when > bookmarks button on clicked, also star button is highlighted. There's a bug filed about this already, it's clearly not the expected behavior. > And, if star is hovered, also the bookmarks button is. yes, this is very likely related to how split menu buttons are implemented, though it has the advantage to show that it's a single widget. Personally I don't think it's a very good idea to move back the star to the urlbar, it was very out of place there, it's related to the tab contents you are seeing, if you edit the url it shows a bogus information. And it's nice to coalesce all related functionality into a single widget. Though clearly this stuff still needs a lot of cleanup, and globally all bookmarking needs an overhaul.

and let alone the fact in the urlbar the star was not customizable at all.

(In reply to Marco Bonardo [:mak] from comment #2) > And it's nice > to coalesce all related functionality into a single widget. Well, staring and showing all the bookmarks don't have much to do with each others.

The idea is that at a certain point you will star the bookmark the that menu will show you where it was added, something you have to guess now. So soon or later those two widgets will be much more bound.

The star button combined with the bookmark button was a deliberate design decision. Future work will hopefully make the relationship between the star button and the bookmark button more clear (see http://people.mozilla.org/~shorlander/mockups-interactive/australis-interactive-mockups/windows8.html for example). I also agree with mak that one of the primary advantages of this change is an increase in customizability.

just as an additional note, it's usually wrong to design for future changes, though in this case it has the benefit to cause less omgchange harm when we'll actually change bookmarks interaction, whatever change we do, users will be acquainted to have a single target of interaction. That's wiser than keep changing their target and splitting them around. If you need anything bookmarks you go to the bookmarks widget. The other very contingent reason is that having the buttons separated is expensive, we don't want magic buttons merging when close since we figured very well how many headaches they cause in code and how much confusion they may cause to users. And especially with the bookmarks button we saw the cost to keep the magic code working. Third, the bookmarks menu is, by our own user studies, a hot click target. So it looks dangerous to provide users an easy way to "lose" it. While it may sound harsh, I think users in need to hide the panel button are more than able to use an userChrome or a simple restartless add-on. The benefits of having it undetachable are bigger than this little annoyance.

Well, this should receive more thought in my opinion. For example I am quite sure that in past version of firefox (or maybe it was an addon) you could place together the stop and reload button next to each other and they would fuse in a single button. It would be nice that the star button and the bookmark button were detachable and merged as the user wishes.

(In reply to Vittorio Giovara from comment #10) > For example I am quite sure that in past version of firefox (or maybe it was > an addon) you could place together the stop and reload button next to each > other and they would fuse in a single button. That setup created a lot of bugs and maintenability headaches, we are explicitly trying to avoid magic stuff like that, since the code ends up being far more robust and scalable.

(In reply to Marco Bonardo [:mak] from comment #11) > (In reply to Vittorio Giovara from comment #10) > That setup created a lot of bugs and maintenability headaches, we are > explicitly trying to avoid magic stuff like that, since the code ends up > being far more robust and scalable. I see your point, but the magic of appearing/disappearing buttons is still present in FF29: for example the Forward button only appears when you hit Back at least once. That makes sense, as a grayed out button is wasted space; however for users who don't click bookmarks button often (or at all) this can be effectively considered wasted space too. Moreover when you drag the bookmarks button from the bar to the menu, there is visually no way to bookmark a page, as the button changes behaviour and only shows bookmarks; and while at it it changes icons too, using the star shape that on the bar is used to add bookmarks (and not list them). I personally find this confusing.

(In reply to Vittorio Giovara from comment #13) > I see your point, but the magic of appearing/disappearing buttons is still > present in FF29: for example the Forward button only appears when you hit Yes, but it's not actually hidden just to "save space", it is cause it would be totally useless for _any_ user. > Moreover when you drag the bookmarks button from the bar to the menu, there > is visually no way to bookmark a page, as the button changes behaviour and > only shows bookmarks The idea is that if you move the star to the menu, you are less likely to care about bookmarks or starring featyres, you likely use bookmarks just sometimes. Moreover the first entry when you click on the star button in the menu is Bookmark this page. (note: it's possible this will change with a new bookmarking experience) > and while at it it changes icons too, using the star > shape that on the bar is used to add bookmarks (and not list them). I > personally find this confusing. It's subjective, it may be confusing for someone but you are not going to damage anything if you do the wrong thing and it will be mostly clarified after first use (again, this interaction may change) While I totally understand the will to reduce "wasted" space as far as possible, the "wasted" concept differs from user to user. Complicating code (with risk of introducing bugs) to satisfy every possible request sounds like a no-go. Luckily Firefox has userStyle.css and add-ons, and hiding a dropdown button (with the former) or adding new buttons (with the latter) is very trivial. This is what we should care about, provide a basic experience that is very good for most, but still allow anyone to optimize it for himself, with just a small effort. Supporting every option in the core product would make it a bloated product with no greater benefit over the current situation but far more bugs.