User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170715185315 Steps to reproduce: I really have no idea why we're truncating device names here but it's not helpful and totally unnecessary.

Uhhh... how about a screenshot? Do you see the same truncation if you use the context menu item on a tab?

There should be ellipses for long names that don't fit (rather than wrapping which doesn't really work with menuitems), but tooltips should show the entire name of a device, as of bug 1368194 being fixed. Not clear what you're seeing without a screenshot.

Screenshot of how confusing it is.

Screenshot showing devices from context menu proving that the device names aren't long, just over eagerly truncated in the page action panel.

(In reply to Paul [pwd] from comment #4) > Created attachment 8887156 [details] > Screenshot from 2017-07-17 18-57-49.png > > Screenshot showing devices from context menu proving that the device names > aren't long, just over eagerly truncated in the page action panel. Well, there isn't space in the width that the panel has. It's unfortunate that the device names are only "just" too long, but if we make the panel wider (which will also affect the main popup's width), we'll have exactly the same problem for devices that are "just" too long for the new size.

That's what I don't get. Why is the size of the panel constrained? The user deciding to open the Send-to-Device panel is a very deliberate action. Why would Firefox then decide to encumber that decision by hiding information from them. At the point the panel is opened, the panel should expand to fit the content.

(In reply to Paul [pwd] from comment #6) > That's what I don't get. Why is the size of the panel constrained? The user > deciding to open the Send-to-Device panel is a very deliberate action. Why > would Firefox then decide to encumber that decision by hiding information > from them. At the point the panel is opened, the panel should expand to fit > the content. The panel expands vertically to accommodate the content. Expanding horizontally is almost impossible while also: - keeping the anchoring (ie the arrow on the panel) in the same place - sliding in the new content - expanding vertically so right now the panel is fixed-width. This goes for all the panels, and was also the case in the pre-Photon panels.

It's a shame that the anchor couldn't be moved to the left as then you'd have the ability to really have the panels adapt to content given all of the extra real estate that would be opened up. Thanks for taking the time to discuss this with me Gijs :)

Goal is to make both the Page Action menu and the main Menu Panel to be 276px. It's enough to set that width for the main panelview only and the others will adhere to it.

Morphing based on bug 1388174 and taking. Aaron, you filed that bug with: (In reply to Aaron Benson from bug 1388174 comment #0) > Page Action Menu, Library Menu, Bookmarks Menu, Overflow Menu widths should > be set to 320px wide so that the sub-panel views are able to display more > content. Can you clarify what you meant by "bookmarks menu" here? The menu that opens from the bookmarks menu button is already ~320px wide for me, if (!) long-enough bookmarks are included in the menu. On a default clean nightly profile, the bookmark titles are shorter and so the menu doesn't expand. The bookmarks view that opens in the library panel will take its width from the panel it's opened in. So I assume that if I update the page action, library and overflow menus, we should be good here. Is that right?

Yep, that's all right. I called out the Bookmarks Menu specifically because it's wider than 320px (looks to be closer to 330px for me on macOS) and I was shooting for more consistency across these menu sizes since they're similar/related. I wouldn't be heartbroken if that one stayed the way it is, though. Sorry for the confusion.

Comment on attachment 8895360 [details] Bug 1381556 - adjust panel widths to accommodate longer/wider content, https://reviewboard.mozilla.org/r/166554/#review172250 Kewl! One question, not blocking landing. ::: browser/themes/shared/customizableui/panelUI.inc.css:1592 (Diff revision 2) > display: none; > } > > #search-container[cui-areatype="menu-panel"], > #wrapper-search-container[place="panel"] { > - width: @menuPanelWidth@; > + width: 100%; Out of curiosity, why is specifying a width still necessary? Doesn't it stretch already?

Comment on attachment 8895360 [details] Bug 1381556 - adjust panel widths to accommodate longer/wider content, https://reviewboard.mozilla.org/r/166554/#review172250 > Out of curiosity, why is specifying a width still necessary? Doesn't it stretch already? You're right, we can just drop this. I thought the fixed width (if you use the resizer between the navbar and the search bar) would interfere with this, but I can't get that to happen, so I've just removed it.

Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/7cb7c61a7b8c adjust panel widths to accommodate longer/wider content, r=mikedeboer

I'm confirming that bug is fixed, starting in Mozilla Firefox Nightly 57.0a1 (2017-08-11), so I'm marking this bug as VERIFIED. Thanks.