Open Bug 1724454 Opened 3 years ago Updated 3 years ago

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

Categories

(Thunderbird :: Message Reader UI, defect)

x86_64
Windows 10
defect

Tracking

(Not tracked)

People

(Reporter: richard.leger, Unassigned)

References

Details

Attachments

(3 files)

Attached image find_in_page.png (deleted) —

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...

Flags: needinfo?(alessandro)
Blocks: tb91found

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.

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

Severity: -- → S4
Summary: "Find in page" panel is not responsive, it does note adjust its content to the preview pane area width when 3-pane-view is set vertically → "Find in page" panel is not responsive to preview pane width.

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

Indeed - quite old bug 1222710

No longer blocks: tb91found
Depends on: 1222710
Flags: needinfo?(alessandro)
Version: Thunderbird 91 → 68

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

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 :-(

(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

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.

Summary: "Find in page" panel is not responsive to preview pane width. → "Find in page" panel is not responsive to preview pane width. When pane width is less than length of the text on the bar
Depends on: 1727263
Attached patch 1724454-findbar-flex.patch (deleted) — Splinter Review

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.

Assignee: nobody → richard.marti
Status: NEW → ASSIGNED
Attachment #9237768 - Flags: review?(alessandro)
Attached image screenshot-with-patch.png (deleted) —

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.

(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...

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 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.
Attachment #9237768 - Flags: review?(alessandro) → feedback+

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.

(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...

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

Assignee: richard.marti → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: