Bug 103656 - Read-only bar is unreadable when using dark theme
Summary: Read-only bar is unreadable when using dark theme
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: UI-Theming Infobar-UX
  Show dependency treegraph
 
Reported: 2016-11-02 16:16 UTC by Rimas Kudelis (only watching bugs where I'm in CC list)
Modified: 2022-06-13 03:26 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screenshot (37.45 KB, image/png)
2016-11-02 16:16 UTC, Rimas Kudelis (only watching bugs where I'm in CC list)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rimas Kudelis (only watching bugs where I'm in CC list) 2016-11-02 16:16:19 UTC
Created attachment 128444 [details]
Screenshot

At least on Linux, when using dark theme and opening a read-only document, the notification about it being read-only appears as white text on yellow background, thus is practically unreadable.

An obvious solution is to always specify foreground color as well, when specifying background color.

Attaching a screenshot. The theme I'm using is called Add-Waiter, which is same as Adwaita (in fact, it includes Adwaita's CSS), but without the light version.
Comment 1 Buovjaga 2016-11-17 12:01:04 UTC
Is it true for version 5.2.x as well?

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Comment 2 QA Administrators 2017-05-31 10:50:38 UTC Comment hidden (obsolete)
Comment 3 Rimas Kudelis (only watching bugs where I'm in CC list) 2017-06-25 12:20:00 UTC
Hello,

this is still the case with 5.3.1, not just 5.2 branch.
Comment 4 Rimas Kudelis (only watching bugs where I'm in CC list) 2017-06-25 12:51:28 UTC
Thank you for marking this bug UNCONFIRMED.

Of course, the original reporter confirming it over multiple versions doesn't count. Noo, why would it count, really?

And of course, the LibreOffice QA team does not have resources of even one person to confirm this really trivial bug (all you have to do is switch on a dark GTK theme, even if just for a little while, and open a document from your e-mail, which triggers it being seen as read-only).

What I don't understand is why you ask the original reporter to revisit the issues they file and "confirm" them by marking them UNCONFIRMED. Why should I be putting more effort into this than the QA team is putting?
Comment 5 Buovjaga 2017-06-25 13:01:42 UTC
(In reply to Rimas Kudelis from comment #4)
> Thank you for marking this bug UNCONFIRMED.
> 
> Of course, the original reporter confirming it over multiple versions
> doesn't count. Noo, why would it count, really?

You are absolutely right, it does not count.

(In reply to Rimas Kudelis from comment #4)
> And of course, the LibreOffice QA team does not have resources of even one
> person to confirm this really trivial bug (all you have to do is switch on a
> dark GTK theme, even if just for a little while, and open a document from
> your e-mail, which triggers it being seen as read-only).
> 
> What I don't understand is why you ask the original reporter to revisit the
> issues they file and "confirm" them by marking them UNCONFIRMED. Why should
> I be putting more effort into this than the QA team is putting?

This sounds like you think we are getting paid for this. You should be putting in as much effort as you can because we are peers. The border between QA team and anyone else is nearly nonexistent. It is merely a question of how much extra work one bothers to do.
Comment 6 Rimas Kudelis (only watching bugs where I'm in CC list) 2017-06-25 14:00:54 UTC
(In reply to Buovjaga from comment #5)
> (In reply to Rimas Kudelis from comment #4)
> > And of course, the LibreOffice QA team does not have resources of even one
> > person to confirm this really trivial bug (all you have to do is switch on a
> > dark GTK theme, even if just for a little while, and open a document from
> > your e-mail, which triggers it being seen as read-only).
> > 
> > What I don't understand is why you ask the original reporter to revisit the
> > issues they file and "confirm" them by marking them UNCONFIRMED. Why should
> > I be putting more effort into this than the QA team is putting?
> 
> This sounds like you think we are getting paid for this. You should be
> putting in as much effort as you can because we are peers. The border
> between QA team and anyone else is nearly nonexistent. It is merely a
> question of how much extra work one bothers to do.

I'm making it sound like you're supposed to care a bit more than a casual user like me, since *you* are a member of the QA team, not me.

I know quite well what open source is, but this mentality within LibreOffice QA team of some idealistic QA process being above everything else has annoyed me more than once already.

I mean, if I wouldn't burst out like this, you (the LibreOffice QA and developers) would probably just ignore this bug until 4.4 is released, then ask me to confirm that the issue is still there, then ignore it again, then ask me to confirm that it's still there in 5.0, and so on and so forth. What is that supposed to tell me?

If you don't think a particular bug deserves attention (low traffic, etc.), that's fine. But what's the point of asking submitters to re-test their bugs with each new release, if these bugs hadn't even been worked on?
Comment 7 Rimas Kudelis (only watching bugs where I'm in CC list) 2017-06-25 14:16:41 UTC
Here, took me like 5 minutes to find where these infobar colors are hardcoded:

http://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/infobar.cxx#GetInfoBarColors

which is called from here:

http://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/infobar.cxx#appendInfoBar

This does specify colors in pairs though, so it's strange that rForegroundColor ends up not being used. But I'm sure the developers would figure this out relatively quickly (certainly quicker than myself), if only this bug went past the QA team filter.
Comment 8 Buovjaga 2017-06-25 14:34:22 UTC
I launched a VM with GNOME and changed the theme to a dark one and I confirm the problem.

Version: 5.3.4.2
Build ID: 5.3.4-1
CPU Threads: 1; OS Version: Linux 4.11; UI Render: default; VCL: gtk3; Layout Engine: new; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group

(In reply to Rimas Kudelis from comment #6)
> I'm making it sound like you're supposed to care a bit more than a casual
> user like me, since *you* are a member of the QA team, not me.

Quit trying to build walls. I can't believe you are writing such absurd statements.

(In reply to Rimas Kudelis from comment #6)
> I know quite well what open source is, but this mentality within LibreOffice
> QA team of some idealistic QA process being above everything else has
> annoyed me more than once already.

There is nothing idealistic about it. It is very realistic. The point is that scarce developer resources need to be focused on investigating known bugs. Even with this system of independent confirmation, developers are regularly having to close reports due to some misunderstanding or whatever and thus wasting their time.

(In reply to Rimas Kudelis from comment #6)
> I mean, if I wouldn't burst out like this, you (the LibreOffice QA and
> developers) would probably just ignore this bug until 4.4 is released, then
> ask me to confirm that the issue is still there, then ignore it again, then
> ask me to confirm that it's still there in 5.0, and so on and so forth. What
> is that supposed to tell me?

On the contrary, you are not helping yourself, but making it harder as no one wants to help a person with such a disgusting attitude. People reading your comments will whip out their shitlists and write "note: never help this Rimas guy".

(In reply to Rimas Kudelis from comment #6)
> If you don't think a particular bug deserves attention (low traffic, etc.),
> that's fine. But what's the point of asking submitters to re-test their bugs
> with each new release, if these bugs hadn't even been worked on?

You are twisting things around and assuming motives. Apparently it did not occur to you that only a minority of testers at any given point in time will be running GNOME desktops.

The point of asking for a re-test is that we are seeing 20-30% WORKSFORME closing rates for mass re-test requests for bugs older than 1 year. We don't do it to annoy reporters, but because there is a real chance something is working in a newer release.
Comment 9 QA Administrators 2018-08-03 02:51:20 UTC Comment hidden (obsolete)
Comment 10 Heiko Tietze 2019-12-03 07:24:57 UTC
(In reply to Buovjaga from comment #8)
> I launched a VM with GNOME and changed the theme to a dark one and I confirm
> the problem.

Please try again with 6.x
Comment 11 Mihkel Tõnnov 2020-06-12 13:14:11 UTC
Using Breeze Dark theme on KDE5, I cannot reproduce this using 6.4: the infobar has light-blue background and black text. However, for me it's legible also in 5.3 when I tried now (albeit with dark blue text, not black; running in same KDE5 environment but with GTK3 VCL backend, as KDE5 VCL plugin is not included in that bibisect repo). So possibly this is GNOME (or theme) specific and my not being able to repro this on KDE is irrelevant.
Comment 12 QA Administrators 2022-06-13 03:26:08 UTC
Dear Rimas Kudelis (only watching bugs where I'm in CC list),

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug