Closed Bug 1222710 Opened 7 years ago Closed 1 year ago

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

Categories

(Toolkit :: Find Toolbar, defect, P3)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1724194
Tracking Status
firefox70 --- affected
firefox71 --- ?
firefox72 --- ?

People

(Reporter: brille1, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: l12y)

Attachments

(2 files)

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
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
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Component: Untriaged → Find Toolbar
Ever confirmed: true
Product: Firefox → Toolkit
Summary: Close button missing in Find panel → In many locales, the Find Toolbar's Close button is missing when notifications like WrappedToTop are too long to fit
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.
Version: 41 Branch → Trunk
(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.
> 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)
Keywords: l12y
Priority: -- → P5
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.
This issue still exists.

Anyone who wants to fix this?
(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/

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

Duplicate of this bug: 1466346

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

Priority: P5 → P3
Duplicate of this bug: 1464382

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.

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

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.

Severity: normal → S3
Duplicate of this bug: 1619129

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)

Duplicate of this bug: 1644042
Blocks: 1724454
Duplicate of this bug: 1666109
Duplicate of this bug: 1709921
See Also: → 998364

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

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1724194
You need to log in before you can comment on or make changes to this bug.