Bug 1764712 - Desktop panel placed vertically has rendering issues, makes application icons menu inaccessible
Summary: Desktop panel placed vertically has rendering issues, makes application icons...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-desktop
Version: 31
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: KDE SIG
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-23 15:25 UTC by Lukas Ruzicka
Modified: 2020-11-24 16:54 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-24 16:54:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
bug demonstration video (1.34 MB, video/webm)
2019-10-23 17:18 UTC, Kamil Páral
no flags Details

Description Lukas Ruzicka 2019-10-23 15:25:47 UTC
Description of problem:

When I move the desktop panel to the right side of the desktop, the launcher loses its function and no applications can be launched using it. Seen in a VM.
Putting the panel on the left edge is fine and the functionality is not broken.

Version-Release number of selected component (if applicable):
plasma-desktop-5.16.5-1.fc31.x86_64

How reproducible:

Always (VM)

Steps to Reproduce:
1. Place the Desktop panel on the right edge of the screen and try to launch launcher.

Actual results:

No apps cannot be launched when the panel is on the right edge.

Expected results:

Panel is usable on all edges.

Additional info:

Comment 1 Fedora Blocker Bugs Application 2019-10-23 15:28:43 UTC
Proposed as a Blocker for 31-final by Fedora user lruzicka using the blocker tracking app because:

 I am proposing this as a blocker because it violates the functionality of the panel on a blocking desktop.

Comment 2 Stephen Gallagher 2019-10-23 15:32:59 UTC
Assuming that the panel works in its default configuration, I'm -1 blocker on this. It can be fixed with an update. I'd also be +1 FE if we end up respinning the release candidate.

Comment 3 Adam Williamson 2019-10-23 16:07:53 UTC
So, the text of the criterion is:

"All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."

That is a bit open to interpretation, but I think I'd agree with sgallagh, I'd say it requires the things that are on the panel *in its default state* to work, it doesn't require the panel to keep working if you change its default state...

Comment 4 Kamil Páral 2019-10-23 17:18:10 UTC
Created attachment 1628564 [details]
bug demonstration video

This is what I see when I try this. Once I move the panel right (or left!), the categories occupy whole space and you can't select any application. That's fixed once you type anything into the search bar, the rendering is then fixed.
Also, if I move the panel right, all the "systray" icons disappear from the panel. It is fixed when you move the panel left and then back to right.

I worked just with KDE Live, so I didn't try whether the problem only occurs once, or whether it affects each boot.

Comment 5 Kamil Páral 2019-10-23 17:19:34 UTC
(In reply to Adam Williamson from comment #3)
> That is a bit open to interpretation, but I think I'd agree with sgallagh,
> I'd say it requires the things that are on the panel *in its default state*
> to work, it doesn't require the panel to keep working if you change its
> default state...

That's a slippery slope, because one could use your wording to say that a language switcher in GNOME doesn't need to work because it's not part of the panel by default. I'd rather focus on the "typical use" part. While adding a language switcher in GNOME is most probably a typical use for a large portion (maybe majority) of our user base, putting the KDE panel to the right corner of the screen is most probably not very typical. Of course I'm just guessing because I don't remember ever seeing anyone using such a layout. With this reasoning, and with the fact from comment 4 that this is just a temporary error that can be fixed by activating search, I'm comfortable with -1 blocker.

Comment 6 Lukas Ruzicka 2019-10-23 17:55:41 UTC
I did not use KDE Live, but installed the Live onto the hdd. For me, it only caused problems when being on the right, I did not have any problems with left position. Other icons were doing fine even on the right side. I have seen set-ups with panel on the right.
However, I do not terribly need to block on this. An update fix is probably fine. I just wanted to stay on the safe side, that's why I proposed it.

Comment 7 Adam Williamson 2019-10-23 18:38:10 UTC
@Kamil: well, if you install in Russian (for e.g.) a layout switcher *will* be included in the panel by default. So that's not cut and dried.

Taking this as a blocker on the basis of the panel criterion would be a slippery slope in the *other direction*, arguably. I already find the criterion a bit uncomfortably broad, tbh - my recollection is that its intent is really in the "things mustn't be obviously broken out of the box" category, and it was written to the gnome2 panel, which had *relatively* limited functionality. These days we push that definition somewhat by including stuff like the overview and absolutely anything you can get to via the panel, and when you apply that to KDE it *really* gets broad, because if you try hard enough you can claim that just about anything in KDE is 'in the panel' in some sense. If we're then gonna extend the criterion to cover anything you can do *to* the panel as well, then jeez, I bet if you poke the KDE panel hard enough in every release we've shipped for the last ten years, you can make *something* broken fall out...

The 'typical use' clause does help a bit as you say, but anyhow. Yeah. It's an awkward criterion.

Comment 8 Rex Dieter 2019-10-23 19:10:26 UTC
-1 blocker from me, it's not the default configuration (and can reasonably be fixed by an update)

Comment 9 Rex Dieter 2019-10-23 19:12:55 UTC
(and... makes me wonder if at least the live image ought to default to 'lock widgets' to prevent this kind of thing from happening accidentally)

Comment 10 Michael Catanzaro 2019-10-23 20:08:45 UTC
I don't think we necessarily need to decide based on the severity of the issue itself. This is a last-minute blocker (reported five days or fewer before the scheduled go/no-go meeting, actually only one day) so at this point it's fair to reject bugs even if they match a criterion, right?

Comment 11 František Zatloukal 2019-10-23 20:20:25 UTC
Michael, that was the first thing to come to my mind when I've discussed this bug earlier today with Lukas. I am -1 Blocker, I think last-minute reasoning makes sense here.

Comment 12 Adam Williamson 2019-10-23 20:27:45 UTC
The last-minute thing was not intended to be used willy-nilly, we didn't write it in just so we can wave off *every* blocker that's found late. And the process design is that we decide whether the bug is a blocker on its merits and *then* decide whether to waive it under the 'late blocker' policy, if someone invokes it - the evaluation on the merits of the bug has to happen first.

Comment 13 Adam Williamson 2019-10-23 20:43:02 UTC
We have about -5 at this point, so regardless of the rationale that's enough votes to reject this as a blocker.

Comment 14 Kamil Páral 2019-10-24 02:51:15 UTC
(In reply to Lukas Ruzicka from comment #6)
> For me, it only
> caused problems when being on the right, I did not have any problems with
> left position. Other icons were doing fine even on the right side.

I have tried several times and I can replicate the issue visible in the video on both sides. The important thing is that it happens only the first time. Once you fix the rendering by searching, you can move the panel to the other side and it renders fine.

Comment 15 Ben Cotton 2020-11-03 16:54:18 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 16 Ben Cotton 2020-11-24 16:54:07 UTC
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.