Hello,

this is still the case with 5.3.1, not just 5.2 branch.

(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.

(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?

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.

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.

(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

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.

Fixed long ago, OK in LO 6.1.