1724454 - "Find in page" panel is not responsive to preview pane width. When pane width is less than length of the text on the bar

Status: NEW

(Thunderbird :: Message Reader UI, defect)

Description

[Richard Leger]

Attachment: find_in_page.png

In the main Mail tab of TB, when reading email in 3-pane view set vertically (folder|list|preview) the "Find in page" panel (activated via CTRL+F) is not responsive and its content does not adjust to the width of the message preview pane. See attached.

This make it impossible to close it or access some of its options which are hidden.

Workaround is to enlarge the preview pane by sliding its left border far to the left... but not the most convenient...

Comment 1

[Arthur K. (he/him)]

I can confirm this happens when >not< in full screen. However, the search field box it is responsive for me. But yes, the Close Find Bar" [X] disappears when TB is windowed.

Comment 2

[Wayne Mery (:wsmwk)]

Good find. This happens in classic view also. Just drag the folder pane splitter to the right.

Comment 3

[Richard Marti (:Paenglab)]

No regression. This happens on TB 78 too. The find bar is provided by toolkit.

Comment 4

[Wayne Mery (:wsmwk)]

Indeed - quite old bug 1222710

Comment 5

[Matt]

Ok am unable to reproduce this using a non localised build. Reading bug 1222710 it appears only some locales are affected and in fact German is the only one actually mentioned by name.

It is also apparent that there is no intention to fix the issue.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

Comment 6

[Richard Leger]

I very likely installed TB en-GB originally...so maybe that is why I am affected. How can I verify my locales?
Sad to hear it may not be fixed :-(

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to Matt from comment #5)

Ok am unable to reproduce this using a non localised build.

I easily reproduce on Mac and Windows with en-US, and I don't see how en-GB would matter, so I think some of the analysis in bug 1222710 is not completely accurate. Using en-US Just drag the folder pane splitter to the right using any of the pane views, or a standalone message window. The rightmost toolbar eventuality disappears.

It is also apparent that there is no intention to fix the issue.

Well, the impact to Firefox is apparently low - as judged by the number of Firefox duplicates and people CC on the bugs in a six year period*. And almost zero Thunderbird users reporting it*. Perhaps very few firefox users reduce their window to less than 1/2 or 1/4 width of their screen?

• I no longer have the bug query, but I did an exhaustive search for duplicates. What you see in bug 1222710 is the result.

This make it impossible to close it

escape key

Comment 8

[Matt]

Ok I missed the part about having to reduce the pane width to less that 25% of screen width. Once I got that part it is easy to reproduce, but I don't think it is 25% of the screen that is relevant. I use a 2 screen setup and dragging the Thunderbird window across both resulted in the issue at the same point as when it was displayed on one screen.

Further observation. The find panel stops resizing when the length of the displayed text string (ending with "Words") exceeds the available space to display it. ie in the English version, the update appears to break about the time the length of text on the bar runs into the close (including a little extra for buffering). From the discussion in bug 1222710 German is mentioned as having 63 characters, where English used some 45, so the issue should appear sooner in the German locales but s not locale specific.

Once the bar stops shrinking it is pushed off the right side of the page.

Comment 9

[Richard Marti (:Paenglab)]

Attachment: 1724454-findbar-flex.patch

Together with bug 1727263 (and the m-c bug 1724194) we can now make the find bar flex a bit to improve the situation. It has some downsides like text that overflows on top and bottom when there isn't enough horizontal space. But this happens later than without the patch which overflows on the end very early.

Comment 10

[Richard Marti (:Paenglab)]

Attachment: screenshot-with-patch.png

Screenshot that shows how it looks with the patch. Note that on the right the text begins to overflow below the close button which is a lot later than before.

Comment 11

[Richard Leger]

(In reply to Richard Marti (:Paenglab) from comment #10)

Created attachment 9237772 [details]
screenshot-with-patch.png

Screenshot that shows how it looks with the patch. Note that on the right the text begins to overflow below the close button which is a lot later than before.

What happens if you reduce the width of column even more? Would the selection boxes move below the search field?
Using TB on a 14" screen with vertical preview pane means the width available would be smaller, therefore content would need to adjust and.likely spread over a higher height...

Comment 12

[Richard Leger]

Richard,

(In reply to Richard Leger from comment #11)

What happens if you reduce the width of column even more? Would the selection boxes move below the search field?

Maybe achievable by adding a wrap directive to your patch, something like:

.findbar-container {
display: flex;
flex-wrap: wrap;
align-items: center;
}

Regards,

Comment 13

[Alessandro Castellani [:aleca]]

Comment on attachment 9237768 [details] [diff] [review]
1724454-findbar-flex.patch

Review of attachment 9237768 [details] [diff] [review]:
-----------------------------------------------------------------

Good improvement, but not complete.
We should indeed allow those element to wrap when there's not enough space, but we should restructure the HTML a little bit in order to always keep the search, next/prev icons, and close icon on the same row, while the checkboxes should stack on the second row.

We could also consider collapsing all those checkboxes into a menupopup with toggable menuitems.

Comment 14

[Richard Marti (:Paenglab)]

Wrapping doesn't work as the height is fixed and this could reduce the message display too much especially in vertical view. And it isn't our code as it sits in toolkit.

Comment 15

[Richard Leger]

(In reply to Richard Marti (:Paenglab) from comment #14)

Wrapping doesn't work as the height is fixed and this could reduce the message display too much especially in vertical view. And it isn't our code as it sits in toolkit.

Does the height need to be fixed?
On a 14" screen with vertical view I can see largely enough space to double the heigh and allow wrap... it would not hide much of the message, in any case the panel could easily be closed...

Collapsing into a menu popup may be a good idea as well... it could allow to keep current height... and if solution works well it could be proposed for implementation upstream...

Comment 16

[Richard Marti (:Paenglab)]

I don't get it working that it grows when it wraps.
Maybe another has more luck.