433912 - After Ctrl+Up (or Ctrl+Down) the current line is not highlighted

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008051501 SeaMonkey/2.0a1pre

This did not happen yesterday

Reproducible: Always

Steps to Reproduce:
1. In the Main mail window, make the List pane current, with several messages listed.
2. Hit Ctrl+Down one or more times.

Actual results:
No highlight is showing which line is current (and will be selected if you hit Space)

Expected behaviour (which happened until yesterday)
The current line is highlighted by horizontal lines immediately above and below it

Comment 1

[Tony Mechelynck [:tonymec]]

P.S. Adding "access" keyword for keyboard (as opposed to mouse) multi-select

Comment 2

[Karsten Düsterloh]

Classic or Modern theme?

Comment 3

[Tony Mechelynck [:tonymec]]

(In reply to comment #2)
> Classic or Modern theme?
> 

Modern.

Comment 4

[Karsten Düsterloh]

WFM with "Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9pre) Gecko/2008051522 SeaMonkey/2.0a1pre" debug build and KDE/Raleigh.

Comment 5

[Tony Mechelynck [:tonymec]]

(In reply to comment #4)
> WFM with "Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9pre) Gecko/2008051522
> SeaMonkey/2.0a1pre" debug build and KDE/Raleigh.
> 

Seeing you mention KDE, I am running KDE 3.5.7 "release 72.9" under openSUSE 10.3 (including all Online Updates distributed so far). AFAIK I changed nothing between yesterday and today that could have affected the change. I see that a new nightly has just been published though -- let's see if there's any change. (I don't expect that the difference between 32-bit i86 and x86_64 would be significant.)

Comment 6

[Tony Mechelynck [:tonymec]]

Attachment: screenshot

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008051602 SeaMonkey/2.0a1pre

Still no highlight.

In this screenshot, the "current" line is the 5th thread (which happens to be underlined because it contains unread messages), as I ascertained by hitting the space bar after taking this shot (making it become part of the selection in reverse-video). The fullwidth lines above and below, which would have been there in the nightlies for day before yesterday or ealier, are absent.

Comment 7

[Tony Mechelynck [:tonymec]]

(In reply to comment #3)
> (In reply to comment #2)
> > Classic or Modern theme?
> > 
> 
> Modern.
> 

Also with "SeaMonkey Default Theme" theme.

Comment 8

[Tony Mechelynck [:tonymec]]

I could make do with a userChrome.css hack if I knew which selector to use. I've just (10 minutes ago) started a new thread in mozilla.dev.tech.css about this so no need to spam the bug.

Comment 9

[Karsten Düsterloh]

> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008051602
> SeaMonkey/2.0a1pre

I downloaded that very same nightly and it's still WFM. 
Did you try a fresh profile?

JFTR: My distribution is Kubuntu 7.10 (Linux 2.6.22-14-generic x86_64 GNU/Linux).

Comment 10

[Tony Mechelynck [:tonymec]]

Hm. :-/ well, I hadn't, but now I did, and you're right:

  seamonkey -no-remote -P clean

(using an existing but reasonably clean profile of mine, where I now created a news account in order to check whether the bug was present) -- well, did not exhibit the bug: the current line had what amounted in the default theme to {outline: 1px dotted black} and in the Modern theme to {outline: 1px 0px 1px solid black}

My newspost mentioned in comment #8 got no reply so far. If I could work around it by userChrome.css I wouldn't have to find out which extension or preference (that I would perhaps not want to disable) was the cause.

Comment 11

[Tony Mechelynck [:tonymec]]

P.S. While I was typing this, Neil replied on the NG -- now I'll try it.

Comment 12

[Tony Mechelynck [:tonymec]]

WORKAROUND (Vary at will) in userChrome.css:

treechildren::-moz-tree-row(current)
  { border:     1px dotted green     !important
  }

Note: When using "outline" rather than "border", the surrounding rectangle starts at the current line but goes all the way down to the bottom of the pane.

That workaround (as written above with "border") is good enough for me.

Comment 13

[Serge Gautherie (:sgautherie)]

(In reply to comment #10)
> I wouldn't have to find out which extension or preference
> (that I would perhaps not want to disable) was the cause.

Did you find out?
Anyway, isn't this bug Invalid or at least Incomplete?