1686364 - Find bar disappears

Status: RESOLVED INVALID

(Toolkit :: Find Toolbar, defect)

Description

[Nick Levinson]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Unknown, except you open a browser and a Web page.

Actual results:

The window is maximized, which is how I like to work. I'm on a Web page. I type ctrl-f and get a Find bar. I use it and keep the bar open. Eventually, sometimes, I realize the bar has disappeared. I don't know exactly when it disappeared. Searching via ctrl-f still works but I can't see the search string or anything else that's displayed in the bar. I do not remember the predicate, what I did that may have caused the problem. If I start a second instance when the first instance has the problem, the second one may not show the problem, but the first one will continue to have the problem; I had the same page (https://bugs.documentfoundation.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&field0-0-0=product&field0-0-1=component&field0-0-2=alias&field0-0-3=short_desc&field0-0-4=status_whiteboard&field0-0-5=content&field1-0-0=product&field1-0-1=component&field1-0-2=alias&field1-0-3=short_desc&field1-0-4=status_whiteboard&field1-0-5=content&limit=0&order=priority%2Cbug_severity&query_format=advanced&type0-0-0=substring&type0-0-1=substring&type0-0-2=substring&type0-0-3=substring&type0-0-4=substring&type0-0-5=matches&type1-0-0=substring&type1-0-1=substring&type1-0-2=substring&type1-0-3=substring&type1-0-4=substring&type1-0-5=matches&value0-0-0=status&value0-0-1=status&value0-0-2=status&value0-0-3=status&value0-0-4=status&value0-0-5=%22status%22&value1-0-0=bar&value1-0-1=bar&value1-0-2=bar&value1-0-3=bar&value1-0-4=bar&value1-0-5=%22bar%22) open in two instances, one with the problem and one without; I don't know if two instances can have the problem at the same time.

(I wish the URL weren't almost the length of an airport runway, but it's the only example I have.)

Another symptom: I couldn't find the vertical scroll bar at the bottom of a long page, because it was hidden behind the Gnome desktop environment's bottom panel. I then tried ctrl-f and couldn't see the Find bar. I had to click the maximize/restore button twice to expose the scroll bar.

Expected results:

The Find bar should remain visible whenever it's operational.

Additional info:

Among solutions, the easier but still kludgy one is to click the maximize/restore top-right button twice. The worse one is to exit and restart the browser, because merely closing the Web page and, if the browser still stays open, revisiting the page doesn't make a difference.

I suspect the problem is from either the Find bar or the maximize/restore functionality. If the bar coding is at fault, the Find bar may be auto-disappearing despite its presence having been commanded (by ctrl-f) by the user. If the maximize/restore functionality is at fault, it may be executing a demaximization that retains full window width and similar window height so that the demaximization is not obvious to the user.

FF is version 84.0.1 or 84.0.2 (both 64-bit) on Fedora 33 Linux, kept evergreen.

I have virtually the same problem with the LibreOffice Writer status bar and the gedit statusbar. The problem began only recently on all three apps, but I don't remember exactly when. The three apps likely have the same code from somewhere upstream.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Nick Levinson]

This is almost certainly an upstream problem, but I don't know where upstream. See also:

For LibreOffice: https://bugs.documentfoundation.org/show_bug.cgi?id=139572

For gedit: https://gitlab.gnome.org/GNOME/gedit/-/issues/399

Comment 3

[Andre Klapper]

As I wrote in https://gitlab.gnome.org/GNOME/gedit/-/issues/399 , I'd recommend to first report this problem in a forum of your distribution to track down the actual reason, or an issue tracker of your distribution, as it seems that random applications shipped by your distribution share the same underlying (!) problem, instead of create lots of tickets in (likely unrelated) application issue trackers.

Comment 4

[Nick Levinson]

I took your suggestion (https://bugzilla.redhat.com/show_bug.cgi?id=1916525), but it's common programming practice to reuse code that does a desired job well enough and likely has already been tested. Thus, they're not "likely unrelated" and I don't see a reason to presume randomness of apps. I didn't file "lots"; I filed exactly three because three apps had almost the same problem. Unless the kernel or the desktop environment causes the problem, and I doubt it and you don't say it, the distro is not likely at fault. We'll see their response.

Comment 5

[Andre Klapper]

I am copying my comment from the GNOME issue tracker, as you decided to post the very same issue in at least four different places by now, so anyone looking into this might spend time to duplicate efforts as this was not initially filed in a forum first to track down the underlying root cause:

"Correct. And extremely unlikely given the different designs, approaches, the different organizational history of projects which you listed to be affected.
So I'd say that they are very likely unrelated and that it makes no sense to create lots of bug reports everywhere for random applications, instead of first trying to find the underlying root cause, in a forum of your distribution if this problem happens in your distribution."

Comment 6

[Nick Levinson]

I am copying my response, except that I added this and the penultimate paragraph. I hope this is helpful.

No, not "extremely unlikely". Perhaps you are intimately familiar with the practices of all three organizations and are aware that code is not reused there. Fine. But differences in design, approach, and organizational history together are not enough. You'd need policy, resources, and enforcement to prevent reuse permitted by intellectual property law and the cost of resources over time could make any of the three projects too expensive to sustain. Free open-source software (FOSS) is well known and is a source that I think most of the experienced programmers will be loathe to avoid especially when it's high in quality. Even Microsoft has been using Linux and I think Microsoft has a pretty good bank account.

You say "it makes no sense to create lots of bug reports everywhere for random applications". I hope by now you have read the reports and my response to your other comments to realize that this statement is in error. "[E]verywhere" is factually wrong. "[R]andom" is contradicted by the fact that the problem occurred in each and every one of the apps I reported on. If the problem had occurred in 20 apps and I had reported on exactly 20, that would not be "random". I will concede, however, that at least one major office serving Federal courts of the U.S., when I checked its website (http://lawslip.com/serious/law-enforcement-problems/trials/judges-biases-can-be-balanced-by-random-assignment-but-randomness-is-uncommon.html), did not know what randomness is and that office was doubtless not alone. That office may still be in error. "[L]ots" is an exaggeration or an obfuscation; the exact quantity is three and there is evidence that you knew that; and I filed three because the three apps in question are where the problem was found.

You say "if this problem happens in your distribution". What you mean by "if" is unclear. I don't know how else someone would discover the problem. You'd need an operating system from somewhere. Maybe you meant an OS that doesn't come with a Linux distro.

You suggest trying a "forum of your distribution". Yes; I already did that, at Red Hat's Bugzilla instance, as you know. That's not strictly a forum but is a bug tracking system, and that's apropos.

You suggest "first trying to find the underlying root cause". Trying to find it is what I was doing by raising upstream sourcing as a possible cause and you were doing by implying downstream sourcing. Doing it "first" would mean that I'd likely have to study source code and I don't have the time or expertise to do that in any short time frame, whereas there are people on these fora and bug trackers who do and offer to do so, depending on priorities. Support forums, which are essentially help desks for users, don't generally go to that level of depth and don't offer to. If anyone finding a bug had to study source code for an underlying cause before reporting, most of the bugs would never get fixed.

I posted in three of the four because those three bug trackers were the three for the three apps that had the three respective bugs. I posted in the fourth because it was the bug tracker for the distro that had the three apps and you had suggested that I post about them with respect to the distro, although you apparently didn't recognize it. Posting a bug report in a support forum is not appropriate and posting in a bug tracker is appropriate, as explained above.

If you are not intimately familiar with all three apps and how they are programmed, even though you likely have more knowledge about something relevant than I do, you and I might learn something from other people who know something about what we're probably both trying to find out. If the problems are indeed unrelated to each other, maybe we're about to find out, with some detail.

Comment 7

[Nick Levinson]

Also noteworthy: What you describe as "the very same issue" had small differences, which I should and did distinguish in the app bug reports. In the distro report, I treated that in a way that lets readers more easily understand the similarities and the differences. Doing all of that and cross-referencing the other reports means that, contrary to your view that "anyone looking into this might spend time to duplicate efforts", they would likely find more quickly a common cause, perhaps upstream or downstream, and thus preclude duplicating effort. To take it elsewhere first to find someone else to do an analysis and then bring it to a bug reporting system where programmers would probably have to reanalyze the problem would be duplication. Should a programmer need to consult someone else, they'd likely do so without my delaying the reporting. Should someone identify an upstream problem, we might report there with the new information.

Comment 8

[Nick Levinson]

More symptoms:

--- The problem arose twice in one FF session. The second time was after I had kludgily fixed it the first time.

--- A different variant of the problem was without the Find bar. The window was partly behind the Gnome bottom panel even without a Find bar, so that the Yahoo page email Send button was too low. I could still use it but it was positioned a little higher on the page and is taller than the Find bar, so it was only partly out of sight behind the panel. Perhaps this exonerates the bar, and the bars in the two similar bugs in the two other apps, and shifts the problem to elsewhere.

Comment 9

[Nick Levinson]

Attachment: Screenshots of problem and kludge in 6 steps.

Comment 10

[Nick Levinson]

For a plausible explanation pending possible repair, see https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/issues/285 .

Comment 11

[Nick Levinson]

The problem was solved by a fix in Gnome 40 affecting how it interacats with FF and other apps. Probably relevant: https://gitlab.gnome.org/GNOME/mutter/-/issues/1627 .