Closed Bug 986509 Opened 9 years ago Closed 8 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

28 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1016063

People

(Reporter: long, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [seamonkey-2.24-unaffected] [seamonkey-2.25-affected] [thunderbird-29-affected])

Attachments

(4 files)

Attached image 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
Attached image after.png
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.
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.
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.
Hang on, I'm going to move this bug to Core::Widget GTK
Component: MailNews: Message Display → Widget: Gtk
Product: SeaMonkey → Core
Summary: mail subject highlight lost when clicking in mail body → On Linux GTK/KDE with zebra striping for trees and menulists when focus is lost the selected row highlight is also lost
Version: SeaMonkey 2.25 Branch → 28 Branch
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.
(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.
Status: UNCONFIRMED → NEW
Component: Widget: Gtk → Themes
Ever confirmed: true
Product: Core → SeaMonkey
Version: 28 Branch → SeaMonkey 2.28 Branch
Duplicate of this bug: 990693
Duplicate of this bug: 995261
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.
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.
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.
(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.
Blocks: 922669
Keywords: regression
Whiteboard: [seamonkey-2.24-unaffected] [seamonkey-2.25-affected] [thunderbird-29-affected]
Version: SeaMonkey 2.28 Branch → Trunk
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
Component: Themes → CSS Parsing and Computation
Product: SeaMonkey → Core
Version: Trunk → 28 Branch
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.
Flags: needinfo?(cam)
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.
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?
Flags: needinfo?(cam)
Can't test SeaMonkey, but I can confirm that the problem described above is gone in Firefox extensions in the latest mozilla-central build.
Might need to wait until the next nightly.
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?
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1016063
You need to log in before you can comment on or make changes to this bug.