1222710 - In many locales, the Find Toolbar's Close button is missing when notifications like WrappedToTop are too long to fit

Status: RESOLVED DUPLICATE of bug 1724194

(Toolkit :: Find Toolbar, defect, P3)

Description

[Axel]

Attachment: Find-No-Close-Button.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20151014143721

Steps to reproduce:

Searching for a term using the Find panel and having passed that last occurance of a search term, the Close button is hidden, i.e. unavailable.


Actual results:

* Search for an existing term using <CTRL>+<F>
* Hit <F3> until the last occurance of the term has been found.
=> The Close button of the Find panel is covered by the notification message (see attachment).


Expected results:

The Close button should always be visible.

Proposal: Notification messages should be put into a separate line, below the input elements

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0
20151105030433

This was reported with the German locale, which has a string that's 65 characters long. Many other locales have strings even longer than that:
http://mxr.mozilla.org/l10n-central/search?string=WrappedToTop

Comment 2

[j.j.]

This affects any locale, if your screen is small or you narrow the window small enough.

Furthermore, even while regular searching (WrappedToTop message not displayed) the X button gets cropped if innerWidth < 600px (german locale).
IMHO hat's wrong by design.

Comment 3

[Gingerbread Man]

(In reply to j.j. from comment #2)
> This affects any locale, if your screen is small or you narrow the window
> small enough.

If you shrink the window to the minimum allowed, most of the Find Bar controls aren't visible.

Comment 4

[j.j.]

> If you shrink the window to the minimum allowed, most of the Find Bar
> controls aren't visible.

sure,

(In reply to j.j. from comment #2)
> Furthermore, even while regular searching (WrappedToTop message not
> displayed) the X button gets cropped if innerWidth < 600px (german locale).
> IMHO hat's wrong by design.

but 600px is by far not the "minimum allowd" for reasonable using a window.

And shouldn't the closing X be the last survivor even in the real "minimum allowed" case? (seems currently somehing like 300px)

Comment 5

[Thorsten Huber]

Attachment: Find bar even larger now with "whole words" option.

I hope this gets fixed eventually. Minimum browser window width I use is approx. 860px, but the problem already occurs with a width of 1077px.

My use case is two browser windows side-by-side on a common 1920x1080 monitor. But I have to move the separation between the browser windows because one website requires a larger width. So I have 860 and 1060 pixels width for the two browser windows.

Comment 6

[Axel]

This issue still exists.

Anyone who wants to fix this?

Comment 7

[Gingerbread Man]

(In reply to Axel from comment #6)
> Anyone who wants to fix this?

This has been set to P5, which is the lowest possible priority [a]. It's almost certainly not going to get fixed, unless a volunteer provides a patch for a developer to review.

I suggest you use either of the following workarounds:
1. Close the Find Bar by pressing the Escape key.
2. Move the Close button to the left edge by adding the following style to userChrome.css [b]

.findbar-closebutton { -moz-box-ordinal-group: 0 !important; }

3. It might also be possible to keep the Close button on the right and visible at all times with userChrome.css. Someone on a site like Reddit might have some ideas [c].

[a] https://wiki.mozilla.org/Bugzilla:Priority_System
[b] https://luke-baker.github.io/#usage
[c] https://www.reddit.com/r/firefoxCSS/

Comment 8

[Thorsten Huber]

Duplicate: Bug 1466346 with P3. Might best to keep the one with higher priority?

Comment 10

[j.j.]

Bug 1466346 is a duplicate, align priority with that bug.

Comment 12

[Thorsten Huber]

From one of the closed bug reports:

Gingerbread Man's work-around could be added here to make it a bug fix:

https://github.com/mozilla/gecko-dev/blob/master/toolkit/themes/shared/findBar.inc.css
(Already contains an attribute for ".findbar-closebutton".)

Another (better) option might be adjusting the order of elements inside "MozXULElement.parseXULToFragment":

https://github.com/mozilla/gecko-dev/blob/master/toolkit/content/widgets/findbar.js
(The "toolbarbutton" with anonid="find-closebutton" could be moved to the top of the "MozXULElement".)

Above solutions move the close button back to the left side, where it originally was AFAIK. If it absolutely must stay at the right side for consistency (although all the other control elements of the find bar are at the far left), then maybe a CSS style could attach it (make it float) at the right border.

Comment 13

[Thorsten Huber]

I was sceptical about the latter (CSS for making it float), and indeed it doesn't work this way.

Comment 14

[Thorsten Huber]

In the bug report it says "trunk" for tracking / version. Should this be set to "40 branch" instead (Firefox 41) because the bug field guide says it's "the version of the software the bug was found in".

Though considering that the "60 branch" is current, and that the bug is still there, maybe it should be set to "60 branch" instead.

Comment 16

[j.j.]

FWIW, I have a computer with upright monitor (1024px width) and avoid using Firefox there just due this single bug
(there are other minor problems, seems UI designers assume 1024px isn't a real-world screen width)

Comment 20

[j.j.]

This works for me now, likely a duplicate of bug 1724194. (Please correct if I'm wrong)