Closed
Bug 986509
Opened 11 years ago
Closed 10 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)
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)
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 2•11 years ago
|
||
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.
Comment 6•11 years ago
|
||
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.
Comment 8•11 years ago
|
||
(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
Comment 11•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
(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
Updated•11 years ago
|
Whiteboard: [seamonkey-2.24-unaffected] [seamonkey-2.25-affected] [thunderbird-29-affected]
Version: SeaMonkey 2.28 Branch → Trunk
Comment 15•11 years ago
|
||
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
Updated•11 years ago
|
Component: Themes → CSS Parsing and Computation
Product: SeaMonkey → Core
Version: Trunk → 28 Branch
Comment 16•11 years ago
|
||
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.
Updated•11 years ago
|
Flags: needinfo?(cam)
Comment 17•11 years ago
|
||
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•11 years ago
|
||
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)
Comment 19•11 years ago
|
||
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•11 years ago
|
||
Might need to wait until the next nightly.
Reporter | ||
Comment 21•10 years ago
|
||
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•10 years ago
|
||
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: 10 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•