Bottom bar goes missing in Firefox, Gedit, Libreoffice (Was: Bring bugs here before Bugzilla?)

Two of us disagree. I reported bugs in three apps, in the apps’ bug trackers. The bugs are similar, so I thought the cause likely was upstream.

He said I should report to “a forum of your distribution” or to “an issue tracker of your distribution” (advising for the tracker twice). He says that Gnome is not at fault. That implies that reporting to the distro system is because the common problem is downstream, and that could implicate the kernel. The distro is Fedora and I did report, to Red Hat’s Bugzilla.

He objected to that and said that before reporting bugs I should be “first trying to find the underlying root cause”. I don’t have the programming knowledge or time to do that. If we all had to do that, few of us would ever report any bugs.

He then changed his mind and said that he meant a support forum only. However, the one at discussion-fedoraproject-org (I’m not allowed to post too many URLs so I’m rewriting some) “is for discussion of development and other work within the Fedora Project. For support and troubleshooting help, visit Ask Fedora.” At ask-fedoraproject-org the “Welcome to Ask Fedora! Please read me first!” says the forum is for “help with installing, using, customizing, and upgrading”. That does not sound like the support forum is equipped for uncovering programming internals to be reported to the Bugzilla. It looks to me like the bug reporting goes to the Bugzilla and not a support forum.

Is he right and I’m wrong? Should I describe the three apps’ bugs at ask-fedoraproject-org for cause analysis before followup at four bug trackers? Should ask-fedoraproject-org get a clarification or change in its purpose?

The three apps are LibreOffice, gedit, and Firefox. The Fedora bug report at 1916525 – is Fedora causing Firefox, gedit, & LibreOffice to lose bottom bar? has links to the other three reports.

4 Likes

Hi @nicklevinson

There’s no real exact science to bug-reporting. The general guidelines are that one should try to isolate the cause of the bug so that a bug can be filed against the right component. Bugzilla has one component each for each package, so ideally we need to first isolate the package that may be causing an issue and then file a bug against this package on Bugzilla. That’s what they mean when they say “root cause”. Also note that different packages in Fedora are maintained by different community members. There’s no one tech team that takes care of all packages. So if we file bugs against the wrong component, we don’t notify the right people.

There’s also no right answer to where the bug should be filed/discussed first. Some developers/maintainers may have the know how and/or time to help you find the right component, others may not. An initial discussion on the forum to collect information that will allow the maintainer/developer to fix the issue quickly is not a bad idea.

Here, given that you are seeing a similar issue in different tools that are provided by different packages, it suggests that a common package that all of these depend on is perhaps at fault. So we need to figure out which that is.

I had a look at your bug. It was filed against the general-purpose-preprocessor package, which I think is unlikely to be the cause. It doesn’t seem to be directly related to GUI applications:

$ sudo dnf info general-purpose-preprocessor
Available Packages
Name         : general-purpose-preprocessor
Version      : 2.24
Release      : 16.fc33
Architecture : x86_64
Size         : 67 k
Source       : general-purpose-preprocessor-2.24-16.fc33.src.rpm
Repository   : fedora
Summary      : Customizable language-agnostic preprocessor
URL          : http://www.nothingisreal.com/gpp/
License      : LGPLv2+
Description  : GPP is a general-purpose preprocessor with customizable syntax,
             : suitable for a wide range of preprocessing tasks. Its independence
             : from any one programming language makes it much more versatile than
             : the C preprocessor (cpp), while its syntax is lighter and more
             : flexible than that of GNU m4. There are built-in macros for use with
             : C/C++, LaTeX, HTML, XHTML, and Prolog files.

So, let’s try and debug the issue here and see where we get. First we need to be sure we’re on the same page with what the issue is. So, could we please have:

  • the versions of the different tools where you are seeing this (rpm -q <package name> will tell you that),
  • a screenshot or a screencast showing the issue if possible
  • steps to reproduce (which you’ve provided, so I’ll paste these here):

Steps to Reproduce:

  1. Run F33 with Gnome 3.38.2.
  2. Try one or more of the following apps:
    2a. For Firefox, open it and a Web page, maximize the window if not already the default, issue ctrl-f to get the Find bar, and use it a while.
    2b. For gedit, open it and a document, ensure Preferences has the statusbar on, maximize the window if not already the default, and use it a while.
    2c. For LibreOffice Writer, open it and a document, ensure View menu > Status Bar is on, maximize the window if not already the default, and use it a while

Can you give some idea of “a while”? A few minutes, or an hour? By maximise do you mean full-screen (as in when one watches videos), or just covering the full screen but with the title bar visible?

6 Likes

Also if you are running any gnome shell extensions or have any gnome tweaks enabled.

3 Likes

That was going to be the next step: create a new user and see if the issue persists on a vanilla Gnome instance :slight_smile:

I thought first we’d see if any of us could reproduce the issue. If yes, then it’s not limited to @nicklevinson and we could each debug independently. If we can’t, then we start looking at Nick’s installation in more detail.

3 Likes

I did provide app version information at the separate bug reports that are linked to in the Red Hat bug report. Since someone closed the Red Hat report and set it to Deferred, that commenter apparently prefers that it be handled as 3 separate bugs. A commenter on one of the 3 seems to have a similar view. The commenter I disagreed with in this thread has the opposite view. The 3 separate app bug reports are a bit more detailed.

I didn’t know which Fedora component to pick and I said so in the body of the Fedora report.

A screenshot in these cases would simply show what comes above the Find bar, the statusbar, or the status bar as being immediately above the Gnome desktop’s bottom panel, instead of having the bar in between the content and the panel. That would be the same for all 3.

A screencast could only be taken when I apply the kludge and would simply show what I’ve already described: click maximize/restore in the top right and the problem is cured for the time being. I can’t make a screencast when the problem begins because I don’t know when that will be or what I do that may cause it at the moment it happens. I only discover it when I want to see the bar and it’s not there.

Maximum window size is what you get with the Maximize button in the title bar, which is based oon the title bar being visible. The other mode you’re asking about is the Full Screen mode. I don’t use any of these apps in Full Screen mode, if that’s even an option.

A “while” is vague because I don’t know the interval. It might be minutes or hours. I think the Find bar has sometimes been immediately out of sight but the Find bar is something I command to show when I desire it and so I notice it’s out of sight. The statusbar or status bar is something I only look for when needed; it should always be present since that’s my pref or menu setting, so I don’t know the interval. Also, the behavior of each bug is inconsistent from day to day, so the interval may be inconsistent, too. With the Firefox bug, it happened twice during a single Firefox session. So something caused the bar that was already present to go out of sight.

All 3 clearly are bugs somewhere and not misuse or one-time glitches. Each of the 3 has occurred over and over.

As to Gnome extensions, I use Gnome as it comes with Fedora. Any tweaks are those offered with Gnome; I don’t do bit-level changes with a disk editor.

I appreciate all this input, but, to clarify, I wasn’t asking how to write a bug report. I was asking whether a bug report should be filed twice: first in a support forum and then in the bug tracker. Unless we don’t know whether it’s a bug, we normally don’t file twice. I filed in two bug trackers per bug in this case only on the request of a commenter and because maybe Red Hat was the right place, as he implied. For most bugs, I file once. I assume that’s normally the correct procedure.

What I read from this thread is, the main point is how to properly report bugs.

We have multiple places that might get involved:

  • distribution forum here, Ask
  • distribution bug trackers, bugzilla.redhat.com
  • upstream forums
  • upstream bug trackers

Fedora community should have an aligned understanding on how to do bug reports.

Bugs need to filed against the software that is the cause of the bug, since that’s the specific piece of code that needs to be fixed. The slight difference between bug trackers and forums is that whereas on forums we can discuss the issue at length to diagnose what’s causing it (what package in a Fedora context), bug trackers are generally limited to bugs—that is after the root cause has been identified. Forums are not divided/organised by software/package, but bug trackers are.

That is fine. But the issue here is that the maintainer for package A may not know package B well enough to help diagnose a bug with it. Sometimes if a maintainer does know a little, or there are clear indications that tell them what package may be causing the issue, they will be able to re-assign the bug to the right package. This was not the case here: I can’t reproduce your bug at all here, for example. So I cannot even start narrowing it down at the moment.

Here’s the general rule one follows:

  • you see something that shouldn’t happen, you first verify that it’s really a bug.
    • to do this, you should run a vanilla (unmodified) Fedora installation to see if the bug persists. If it does, it’s a software problem. If it doesn’t, it’s limited to your configuration.
    • if it’s a configuration problem, you start with a vanilla system and incrementally make your personalised tweaks, and after each tweak you see if the bug starts to occur. This tells you what particular tweak is causing the bug.
  • if it’s a system issue that occurs on a vanilla Fedora installation, you need to identify what package is causing the issue. This isn’t always trivial since GUI tools depend on lots of libraries.
    • If you do not know the code base well enough to identify what package may be causing it (which is the case for most of us) , discuss your issue on a forum where the combined knowledge of community members is generally able to identify the root cause, the package that has the bug. We even get maintainers involved sometimes to help if we can.
    • Once you’ve identified the package, you can proceed to filing the bug on bugzilla where the maintainer will be able to understand the issue and check how to fix it. Depending on how confident you are with your technical skills, you can also file a bug directly with upstream (maintainers are not always also developers of the software),
    • From this point on, you (the reporter) communicates with the maintainer. The maintainer may ask you to submit more information, and if you’re unsure how to provide it to them, you can request that they give you detailed steps and so on. Here, you are now helping the maintainer figure out exactly what particular part of the software source code is causing the bug.

Basically, we’re just narrowing down to what may be causing the issue. It isn’t sufficient to say “3 apps are seeing this”, because that doesn’t quite contain enough information—the 3 apps may be sharing 10s if not 100s of libraries.

So, a guideline would be: if you don’t know what exact software/package is causing the issue, discuss it in a forum to figure that out before filing a bug report.

Then you’ll agree that diagnosing the cause of the issue requires more work. Let’s focus on that.

Gnome does not maintain all shell extensions. This is documented here:

https://extensions.gnome.org/about/

I quote:

What are GNOME Shell Extensions?

GNOME Shell extensions are small pieces of code written by third party developers that modify the way GNOME works. (If you are familiar with Chrome Extensions or Firefox Addons, GNOME Shell extensions are similar to them.) You can find and install GNOME Shell extensions using this website.

Since extensions are created outside of the normal GNOME design and development process, they are supported by their authors, rather than by the GNOME community. Some features first implemented as extensions might find their way into future versions of GNOME.

We can file bugs for the “system extensions” that maintainers provide in Fedora. For extensions that are installed from the gnome-extension website etc., we need to contact their developers directly.

I hope my reply clarifies this. A bug generally needs to filed once, but then this bug needs to be filed at the correct place with the correct/necessary/sufficient information for it to be useful for the maintainer/developer. (Otherwise it’s just noise that the maintainer/developer cannot do anything useful with) Until this amount of information is known, you are still diagnosing the issue and a forum is a better place for that.

Now, to the issue at hand:

  • I left my firefox open for ~6 hours and the search bar did not go away.

Can you think of anything else you are doing that correlates with the issue. Are you using some short-cuts, or some keyboard combinations? Does it happen with a particular page or document? Anything that helps us get started with narrowing down the issue?

At the moment, we don’t know what is causing the issue—could be an extension but we don’t have information to say so. The first thing I’d do with anything Gnome related is to disable all extensions to see if the issue persists (or just create a brand new user and use that for a day—ensures that you get a vanilla gnome installation). Depending on how that goes, we decide on next steps.

5 Likes

We do. My post will hopefully clarify this.

2 Likes

It’s okay to have the support forum be a prereporting site for a bug, even though that creates a substantial extra step for reporters, but then the stated purpose of the forum needs to be amended to that end. This forum’s Welcome page’s statement is that it is for “installing, using, customizing, and upgrading” (welcome-to-ask-fedora-please-read-me-first (in URL)). That probably should be amended to conform to your larger understanding. Bug trackers generally do not suggest reporting bugs by filing them in support fora, so perhaps Red Hat’s introduction to its bug tracker needs amending; its home page says “. . . submit and review defects that have been found . . . .” and “please provide detailed information in your submission after you have queried Red Hat Bugzilla” without mentioning support fora. It also says “Red Hat Bugzilla is not an avenue for technical assistance or support”, so maybe the home page is ambiguous. But it should be clearer, if you’re right.

It also is not what I usually observe on both kinds of sites: support fora are generally for how to use software but bug trackers generally report analyses in comments on bugs that were reported there. I often do not know to what component to attribute a bug and, if forced to pick something, do so with an explanation, as I did here, after which someone, maybe a bot, often changes the component based on other people’s knowledge of which component is a likelier context.|
||||On Firefox: “Can you think of anything else you are doing that correlates with the issue. Are you using some short-cuts, or some keyboard combinations? Does it happen with a particular page or document? Anything that helps us get started with narrowing down the issue?” I wish I could have narrowed it down further than I reported. I use ctrl-f to get the Find bar, but I already said so. No, not a particular page or document. I have not noticed any predicate act.

I’ve also added to the Firefox report a new observation that may exonerate the Find bar and move the problem analysis to elsewhere (1686364 - Find bar disappears). I don’t know if that applies to gedit and LibreOffice Writer, but it may well.

If I use any Gnome extensions, they are extensions packaged with Fedora when I download or update Fedora. Here’s what Terminal told me (brackets so in original):

$ gsettings get org.gnome.shell enabled-extensions
[‘background-logo@fedorahosted.org’, ‘places-menu@gnome-shell-extensions.gcampax.github.com’, ‘window-list@gnome-shell-extensions.gcampax.github.com’]

“[Y]ou’ll agree that diagnosing . . . .” Yes, I do. Thank you. I wrote to that effect in my reports.

But I doubt I’ll set up a second installation or another account and do incremental changes. That’s an excellent method, but I don’t have the time and would simply not report (and would feel frustrated). When I report without that research being in the thread, it may be that no one else has the time either, but that’s just saying that it’s not a high-priority bug, and I respect that prioritization decision. I sometimes disagree, such as when usability is, in effect, downranked by commenters, but I don’t have the time to do those patches, and at least I told relevant people of the problem via a public channel. And some problems get cured.

2 Likes

You’re experiencing an issue while using Fedora, so it is within the scope of the forum. I don’t think we need to list every specific case in which someone should ask a question or start a topic here.

Yes, but bug trackers are for bugs—they’re not for technical assistance, even if sometimes maintainers/developers may provide it as part of the debugging/diagnosing process. As I’ve said in my post above an issue transforms into a bug when we’ve been able to pin point the piece of software that is responsible for the problem.

I’ve not seen a support forum that limits discussions to using software. They’re open to any questions related to the subject of the forum, and Ask Fedora follows this system too.

There is no bot on Bugzilla that auto-assigns components. It must be done manually. Either the reporter, you, can first discuss your issue at a forum to help narrow down what component to file the bug against, or the maintainer can do it. In this case, the maintainer could not. We’re happy to try to do it here, but at the moment, there’s not enough to go on.

Can you please take and upload a screenshot when one of the bars disappear so we can see what it looks like? That may give us some hints as to whether it’s the lower boundary of the app that’s moving, or if the whole screen is perhaps not fitting in your monitor, or is something else deactivating the bar?

it is unlikely that the problem will be fixed if others cannot reproduce it. There’s nothing to debug if there isn’t a way of making the bug occur. :confused:

We are still curious to see whether this happens on a virgin, non-extended Gnome. Please create a new user, not installing any extensions and let it run…

2 Likes

If other folks can’t reproduce for an app, that may end the matter for that app until someone does reproduce or I uncover more details, such as predicates. Meanwhile, nonreproducibility for only one app does not apply to the other apps of the 3.

The window fits in the screen with or without the bar. The title bar and the left and right edges remain present. I can read text from edge to edge of the viewport.

I got screenshots for Firefox, gedit, and LibreOffice Writer and posted them as single files at the respective bug reports. I posted them there for relevance and linked from here to there for nonredundancy.

If a configuration is the problem, that only narrows the bug. There probably is no configuration done through UI settings that should excuse these bugs. If I had used a third-party tool to tweak an app, then an explanation (so other users don’t do the same thing) would suffice, but I didn’t, so the problem is significant.

Hardware being the problem is hardly likely. I’ve had the same display since long before the bugs manifested themselves. I think I already pointed that out and no one disagreed.

Setting up another user is not trivial. I have to use my computer for work, and a vanilla setup is not useful for my usual work. For that, I need configurations, thus it wouldn’t stay vanilla. To use it without configuring, I may have to spend hours doing nonwork but just banging the keyboard until the problem replicates. There’s my time problem.

If my time is too limited to support a proper diagnosis, and no one else has the time either, we then effectively agree that it is not a high-priority bug and we can leave the affected reports open in case someone else wants to select an open issue that fits what they want to do. There are many low-priority issues that remain open until version EOL or until picked up for resolution.

The tech assistance is not for me. It is provided by commenters to each other for the benefit of whoever might write a patch or otherwise resolve a bug. That is why that analysis is done in the bug-reporting system, irrespective of where else it is done.

Support fora may be willing to discuss whatever, but bug sites discuss bugs and their causes and resolutions. Bugs are treated separately from support issues generally, because they’re characteristically different, needing more than just advice to users. There’s not much wrong with moving bug prereporting into a support forum, but that should be done explicitly, by removing essentially contradictory language from the website instructions. It probably does not seem contradictory to you and some others, but it would be to most readers.

I have seen that a bot reassigned a bug to a different component at a bug-reporting site. Whether it was at Red Hat’s, I don’t know, but I report on any such sites that are apropos and I have seen reassignment by bot more than once. Humans also reassign some. In most reports, only one reassignment occurs, it occurs early in the history of the bug report, and, based on subsequent commentary, it is to the right component the first time. Apparently, that system already works.

I didn’t just have a mere problem using Fedora. I discovered that each app was misbehaving and that it wasn’t my misuse or not understanding how to use. Also, it wasn’t a one-time event, but likely replicable. Thus, I discovered a bug. Given that, I had to find the right site to post to. Sites say what they accept. Skimming recent thread titles in either type of website shows what most people think each site is for and in Fedora’s case that’s largely consistent with the Welcome page and the Bugzilla home page. Specifically, I discovered bugs in apps that were part of Fedora and I had already reported the app bugs. Thus, I wouldn’t be looking for a website about using, but one about bugs, and most software has different websites for the two purposes.

If, in Fedora’s case, bug discoveries should first go into Ask FedoraProject, that’s specific enough and different enough that it needs to go onto the Welcome page and into the Red Hat Bugzilla home page. That may not be your responsibility; if I should suggest this to someone else, let me know. If it doesn’t appear on those two pages in a reasonable time, at least one, then the people responsible for either of those two don’t agree on that placement of prereports. Your idea may be a good proposal; that depends on who responds to threads on each type of website. Another distro used a site jointly for both purposes. But your idea is unexpected and contrary to normal expectations of how people should respond to posted instructions. That’s why instructions are posted. Please let me know who should get support for your proposal or custom, if you wish.

Screenshot revealed they having been using Window List - GNOME Shell Extensions this whole time (and this wasn’t mentioned in the bug report) from which it took me about 30 seconds to find Maximized window size slightly wrong when using "Window List" (#285) · Issues · GNOME / gnome-shell-extensions · GitLab

I’ve closed the gedit issue as dup of that

2 Likes

Thanks @zbrown . I’ll close this question here too, since your comment acts as an answer.

@nicklevinson : the bug is with the extension, please disable it for the time being, and work with upstream to help them fix it.

2 Likes

@zbrown : I’ve tweaked your response to indicate that the window-list extension was not mentioned in the bug-report. It was mentioned here in this thread.

1 Like