986509 - On Linux GTK/KDE with zebra striping for trees and menulists when focus is lost the selected row highlight is also lost

Status: RESOLVED DUPLICATE of bug 1016063

(Core :: CSS Parsing and Computation, defect)

Description

[long]

Attachment: before.png

User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 (Beta/Release)
Build ID: 20140318183150

Steps to reproduce:

I have my MailNews view set to Wide View.  If I click a message subject in my mail list it becomes highlighted.  If I then click in the body of that mail message the highlight is lost.  


Actual results:

The highlighting of the mail subject is lost


Expected results:

The hightlighting of the mail subject is retained so I can tell what the current message is.   I don't believe this happened before SM 2.25

Comment 1

[long]

Attachment: after.png

Comment 2

[Philip Chee]

Your threadpane is striped. Do you have a userChrome.css or a Stylish userstyle? It may be interfering with the highlight styles for the threadpane tree.

Comment 3

[long]

Ugh, I should have tested with safe mode first.  Doing that the striped GUI still shows and I still have the same problem.  I also discovered that this problem only happens when I have one of the darker rows active.  If I have one of the lighter rows active and then click in the message body the highlighting does not disappear.  I do not have a userChrome.css or a Stylish userstyle.  Since I also see the same striped effect in Firefox list boxes I suspect I have some KDE/GTK setting somewhere doing the striping.  I will have to see if I can figure out how to get rid of that it appears.

Comment 4

[long]

The zebra striping is apparently something from KDE.  I just went back and tested seamonkey 2.24 and I do not lose any of the highlighting, no matter which row was selected.  I have discovered though that if I go through KDE System Settings -> Application Appearance -> Colors -> Options and turn off "Inactive selection changes color" then I still get some loss of highlighting in SM 2.25 but it is not the same as before.  I'll attach a new pic to show this new effect.

Comment 5

[long]

Attachment: shows partial loss of highlighting in SM 2.25 when KDE change made

Comment 6

[Philip Chee]

Hang on, I'm going to move this bug to Core::Widget GTK

Comment 7

[u347682]

Mozilla/5.0 (X11; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25

I can confirm this bug. I see exactly the same thing: only the dark rows are affected, resultig in unreadable white on light grey text when focus is lost. Tried changing GTK themes, but didn't help.

Comment 8

[Philip Chee]

(In reply to swedishchef from comment #7)
> I can confirm this bug.
Thanks. UNCONFIRMED -> NEW
This is the SeaMonkey version of Thunderbird Bug 811920 (Message list highlight bar - insufficient contrast when list is blurred) We could do what Thunderbird did:
https://hg.mozilla.org/comm-central/rev/226011df6278
Back to SeaMonkey. Sorry about the churn.

Comment 11

[Andrew Poth]

Attachment: SM_2.25_MailNews_Bug_986509_all messages_selected.png

SeaMonkey 2.25, Ubuntu 10.04.1, GNOME 2.30.2, using Clearlooks Theme.

These two screenshots illustrate another effect of the bug.  All the messages in the Thread Pane are selected with Ctrl+A, causing them all to be uniformly highlighted.  That's expected, and the way SeaMonkey behaved prior to release 2.25.  Then, when one clicks on the folder and the focus changes to the Folder Pane, the message highlighting goes "zebra stripe".  All messages are still selected, but every SECOND line gets the wrong foreground/background color; they should all have stayed white text on blue background in my desktop theme.  (Regardless of desktop theme, the colors should not have changed with focus changing from one pane to the other.)  Moreover, with white text on light gray, the text is almost unreadable on my computer.

Comment 12

[Andrew Poth]

The problem also exists in the Data Manager.  For example, select a URL with many cookies, then select all the cookies.  At first, all the lines are uniformly highlighted.  Press the "Remove" button.  When the confirmation dialog box comes up, the list of cookies becomes zebra-striped.

Comment 13

[Dan Stillman]

I think this actually is a Core issue and not specific to SeaMonkey — on OS X I see the same thing in Thunderbird 29 Beta (20140424045348) and in the items list in Zotero (Firefox extension). (The behavior doesn't happen for me in Firefox in Places, which appears to use its own special styling, but it happens in Zotero's unadorned XUL <tree>.)

The regression period was http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d22b3851aff0&tochange=3f7925e3933b, which is bug 922669.

Comment 14

[Philip Chee]

(In reply to Dan Stillman from comment #13)
> I think this actually is a Core issue and not specific to SeaMonkey — on OS
> X I see the same thing in Thunderbird 29 Beta (20140424045348) and in the
> items list in Zotero (Firefox extension). (The behavior doesn't happen for
> me in Firefox in Places, which appears to use its own special styling, but
> it happens in Zotero's unadorned XUL <tree>.)
> 
> The regression period was
> http://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=d22b3851aff0&tochange=3f7925e3933b, which is bug
> 922669.

Assuming you are correct, Setting flags and dependencies.

Comment 15

[Dan Stillman]

Just to clarify, Firefox 28 and up are in fact affected here as well, since it happens in XUL trees in Firefox extensions. (This problem has been reported by users of Zotero.) Places just happens to use custom styling that's unaffected.

I assume this should be recategorized as a Core/CSS bug, since it was caused by bug 922669. My regression range can be verified in Firefox using mozregression and the Zotero extension [1]:

1) Open the Zotero pane and create three items in its middle pane (e.g., New Item (green "+") button -> Book).

2) Select all three items.

3) Unfocus the pane by clicking elsewhere (e.g., the Firefox address bar).

The middle row won't have the expected grey highlight.

(Any other extension that creates an unstyled <tree> would also suffice.)

I just checked it again now and got the same regression range as above.


[1] https://www.zotero.org

Comment 16

[Andrew Poth]

I noticed that messages that have been tagged and a text color applied do not exhibit the zebra-striping problem, at least in a special case where I'm using a filter to move selected mail to another folder and tagging the messages before moving.  This results in all messages in that folder having the non-default color and the text retains good contrast against the background color, whether the messages are selected or de-selected.

Curiously, this provides a partial work-around until the problem gets fixed.  Define a new tag called "Normal", color white, and apply it to ALL messages in a folder.  Now lines with poor contrast are readable.  The "Normal" tags can be removed from messages later when this bug is fixed.

SeaMonkey 2.25, Ubuntu 10.04.1, GNOME 2.30.2, using Clearlooks Theme.

Comment 17

[Dan Stillman]

Just noticed an easier test case in Firefox: open the DOM Inspector, select three lines from the left pane, and click in the top-right pane.

Comment 18

[Cameron McCormack (:heycam)]

Sounds like the same issue as bug 1016063.  Anyone care to try a SeaMonkey build that includes the patch that just landed there to see if the problem is gone?

Comment 19

[Dan Stillman]

Can't test SeaMonkey, but I can confirm that the problem described above is gone in Firefox extensions in the latest mozilla-central build.

Comment 20

[Cameron McCormack (:heycam)]

Might need to wait until the next nightly.

Comment 21

[long]

I don't see any current linux nightlies at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk/

Should I be looking elsewhere?

Comment 22

[u347682]

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29
Build-Identifikator: 20140822025554

Looks as if the problem is gone.