Provide options to allow panelmultiview height to shrink when opening subviews
Categories
(Firefox :: Menus, enhancement)
Tracking
()
People
(Reporter: emilio, Unassigned)
References
Details
The panel view transitions currently fix the height of the "transitioned to" subview to the height of the "transitioned from" view.
This in general makes sense and prevents flickering, but it might make sense to provide a way of transitioning to the "right" height. The initial patches in bug 1852340 contained some code to achieve this for a particular subview.
In general, these transitions use flexbox and which has caused problems in the past (see bug 1822819 for example). A lot of the complexity around this was IIRC due to XUL not supporting absolute positioning and so on. Maybe nowadays we can simplify a bit how these work while at it?
Comment 1•1 year ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #0)
The panel view transitions currently fix the height of the "transitioned to" subview to the height of the "transitioned from" view.
I'm confused because purely from this phrasing I don't think this is generally true? E.g. if I add the library button to my toolbar and open any of the subviews, the height of the panel increases.
We deliberately do not decrease the height when opening subviews, because it feels weird to do that. Is that the thing that we're wanting to change here?
Comment 2•1 year ago
|
||
@Gijs, yes, for our project in the dependent bug, it's a case where there is a panel which can be opened from three places; the main menu, the app menu, and the protections panel. It is also a bit weird for it to appear in different sizes in all three cases, and have a lot of empty space. But we do want it to behave like a subview (for the animations/back button/etc). I'm not sure how to reconcile that kind of tension :)
Comment 4•1 year ago
|
||
(In reply to Thomas Wisniewski [:twisniewski] from comment #2)
@Gijs, yes, for our project in the dependent bug, it's a case where there is a panel which can be opened from three places; the main menu, the app menu, and the protections panel. It is also a bit weird for it to appear in different sizes in all three cases, and have a lot of empty space. But we do want it to behave like a subview (for the animations/back button/etc). I'm not sure how to reconcile that kind of tension :)
I guess I don't see it as weird... but also, off-hand I think you could use CSS allow the big textarea to expand to fill whatever size the subview becomes (while giving it a minimum size)?
Comment 5•1 year ago
|
||
I think you could use CSS allow the big textarea to expand to fill whatever size the subview becomes (while giving it a minimum size)?
Yes, but that's just one of the two panels we have. The other is a brief "thank you for sending your report" panel, which has nothing we could expand to fill the size, so it will be mostly empty (and honestly, seeing a needlessly gigantic textarea may be a bit silly too). So it's a bit iffy either way (at least to me).
Comment 6•1 year ago
|
||
When bug 1877814 lands, this will probably not be worth doing for the sake of the Report Broken Site feature.
Description
•