Make page action panel, library, and overflow panels wider (larger min-width) to make them accommodate longer content

VERIFIED FIXED in Firefox 57

Status

()

P1
normal
VERIFIED FIXED
a year ago
a year ago

People

(Reporter: pwd.mozilla, Assigned: Gijs)

Tracking

(Blocks: 1 bug)

Trunk
Firefox 57
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 verified)

Details

(Whiteboard: [photon-structure])

Attachments

(3 attachments)

(Reporter)

Description

a year ago
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.
(Reporter)

Updated

a year ago
Blocks: 1363182
Component: Untriaged → Location Bar
(Assignee)

Comment 1

a year ago
Uhhh... how about a screenshot? Do you see the same truncation if you use the context menu item on a tab?
Flags: needinfo?(pwd.mozilla)
Whiteboard: [photon-structure][triage]
(Assignee)

Comment 2

a year ago
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.
Blocks: 1368194
(Reporter)

Comment 3

a year ago
Created attachment 8887153 [details]
Screenshot from 2017-07-17 18-39-39.png

Screenshot of how confusing it is.
Flags: needinfo?(pwd.mozilla)
(Reporter)

Comment 4

a year ago
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.
(Assignee)

Comment 5

a year ago
(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.
Summary: Do not truncate device names in Send-to-device page action panel subview → Make page action panel wider (larger min-width) to make it feel less cramped and accommodate longer device names in the 'send to device' menu
(Reporter)

Comment 6

a year ago
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.
(Assignee)

Comment 7

a year ago
(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.
(Reporter)

Comment 8

a year ago
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.
Flags: qe-verify+
Whiteboard: [photon-structure][triage] → [photon-structure]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
QA Contact: gwimberly
(Assignee)

Updated

a year ago
Duplicate of this bug: 1384229
(Assignee)

Updated

a year ago
Duplicate of this bug: 1387417
(Assignee)

Updated

a year ago
Duplicate of this bug: 1388174
(Assignee)

Comment 13

a year ago
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?
Assignee: nobody → gijskruitbosch+bugs
Flags: needinfo?(abenson)
Priority: P2 → P1
Summary: Make page action panel wider (larger min-width) to make it feel less cramped and accommodate longer device names in the 'send to device' menu → Make page action panel, library, and overflow panels wider (larger min-width) to make them accommodate longer content
(Assignee)

Updated

a year ago
Iteration: --- → 57.1 - Aug 15
Status: NEW → ASSIGNED
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)

Comment 16

a year ago
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.
Flags: needinfo?(abenson)

Comment 17

a year ago
mozreview-review
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?
Attachment #8895360 - Flags: review?(mdeboer) → review+
(Assignee)

Comment 18

a year ago
mozreview-review-reply
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.
Comment hidden (mozreview-request)

Comment 20

a year ago
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/7cb7c61a7b8c
adjust panel widths to accommodate longer/wider content, r=mikedeboer
https://hg.mozilla.org/mozilla-central/rev/7cb7c61a7b8c
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
(Assignee)

Updated

a year ago
Depends on: 1389853
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.
Status: RESOLVED → VERIFIED
QA Contact: gwimberly → Virtual
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.