| This bug describes changes to the version of the downloads panel and | indicator that is currently present in the UX branch, more specifically: | * Bug 564934, attachment 558500 [details] [diff] [review] | * Bug 663772, attachment 558504 [details] [diff] [review] | | Patches for this bug should apply on top of the two mentioned patches. * The panel's width should be fixed but larger than the current, maybe depending on the browser's current UI language. At present, the label for blocked downloads is always larger than the panel width, and sometimes also the remaining time indication in download items. * The panel's height should be less than the full screen height, so that part of the current page in full screen mode would be visible below it, even if a scrollbar would appear. Currently, when there are many items, sometimes the panel deanchors and loses the arrow rather than just shrinking below. [Implementing this might depend on adding platform support.] * The panel's arrow should point to the center of the button even if the button is near to the edge of the screen. It might be compatible that the border of the panel goes slightly off-screen in this case. [Implementing this might depend on adding platform support.] * The "Show Downloads History" link should have a slightly different styling and hover (see the UI mockup in the bug's URL). * Rename "Show Downloads History" to "Show All Downloads".

(In reply to Paolo Amadini from comment #0) > * The panel's width should be fixed but larger than the current, maybe > depending on the browser's current UI language. At present, the label > for blocked downloads is always larger than the panel width, and sometimes > also the remaining time indication in download items. likely localizable width expressed in ch units. > * The panel's height should be less than the full screen height, so that part > of the current page in full screen mode would be visible below it, even if > a scrollbar would appear. Currently, when there are many items, sometimes > the panel deanchors and loses the arrow rather than just shrinking below. > [Implementing this might depend on adding platform support.] I think ux suggested to come with a fixed amount of entries, like about 7 entries > * The panel's arrow should point to the center of the button even if the > button is near to the edge of the screen. It might be compatible that the > border of the panel goes slightly off-screen in this case. > [Implementing this might depend on adding platform support.] I think we should asap file a platform bug on this and cc Enn. Even if may just be a widget theming issue

(In reply to Marco Bonardo [:mak] from comment #1) > > * The panel's arrow should point to the center of the button even if the > > button is near to the edge of the screen. It might be compatible that the > > border of the panel goes slightly off-screen in this case. > > [Implementing this might depend on adding platform support.] > > I think we should asap file a platform bug on this and cc Enn. Even if may > just be a widget theming issue Actually I'd like a patch for bug 697683 to be available before asking Enn, because, with the final indicator styles, we'll know if we just need the border to go slightly off-screen or if we need a new type of arrow (asymmetric or just smaller), and Enn can test with a real case.

Sure, but still the fact you can't use the arrow panel on the first or last button of the toolbar is a bug. Btw, I thought the problem was mostly on the border on the right on the arrow, than the arrow itself, without all that space on the right of the arrow, it may still point to the button (maybe not perfectly centered, but we'd survive that).

I moved the open issues outlined here to bug 726447, together with all the other visual design feedback that was scattered in various places. It makes sense to keep all the known issues listed in a single place, at least until we understand what is blocking for release and what is not.