1069419 - userchrome.css not honoured & no support for arial narrow font

Status: UNCONFIRMED

(Thunderbird :: Folder and Message Lists, defect)

Description

[softedge]

Attachment: userChrome.css

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140911151253

Steps to reproduce:

update from tb24.8 to tb31.1


Actual results:

tb31 does not honour userchrome.css for colours, arial narrow font, or folder/thread pane row height as does tb24.8. tb29 does honour colours, but not folder/thread pane row height or font

Comment 1

[softedge]

also using nightly and aurora appearance theme/persona

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to softedge from comment #0)
> update from tb24.8 to tb31.1

In Firefox, internal elemtnts were changed from Firefox 29 for Austrails. This big change may affect on Tb.

> tb31 does not honour userchrome.css for colours, arial narrow font, or folder/thread pane row height 
> as does tb24.8. tb29 does honour colours, but not folder/thread pane row height or font

> (a) not folder/thread pane row height or font in Tb 25/28/31

Is #folderTree > treechildren::-moz-tree-cell-text like specification proper?
-"moz-tree-cell-text" like one may be changed to official one.

> (b) not honour for colours, arial narrow font in Tb 31

If font-family/size is requested by "much limited element like xxx::PsuedoClassLikeOne", generic request like next is not used for the element.
> * { font-size: 12pt !important; font-family: ArialNarrow !important; }

Anyway, check relevant XUL elements by DOM Inspector.
What "Computed Style" is actually used for the relevant elements?
What CSS Rules are actually used for the relevant elements?
Is your userchrome.css specfiction correct in Thunderbird 31?

What Theme do you use? Standard Theme? No compatibility problem in your Theme with Tb 31?

By the way, "Theme Font&Size Switcher" Addon is availaable for long time, and is usefull for generic Font/Size/Color change in UI.
Is such Addon not appropriate for you? Different size in "Menu" and "Folder Pane row, Thread Pane row" is needed?

Comment 3

[WADA:World Anti-bad-Duping Agency]

> (a) not folder/thread pane row height or font in Tb 25/28/31

Read next MDN document for "Styling a Tree".
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Styling_a_Tree#CSS_Selectors_for_the_Tree
"more complex syntax(complex selector)" may be needed for "pseudo element" in tree-cell.

Comment 4

[Jorg K (CEST = GMT+2)]

This was working in 24.x to set a new colour when hovering over a potential drop target during a drag&drop:

treechildren::-moz-tree-row(dropOn) {
  background-color: #ff8080 !important;
}

It is no longer working in 31.2.0 or 33 beta.

The description says:
dropOn: if a drag is occuring over the tree, this property is set for the row currently being dragged over, as long as the mouse pointer is hovering over the row.

This worked, now it no longer works.

Comment 5

[Jorg K (CEST = GMT+2)]

Can someone please mark this as regression. Thanks.

Comment 6

[WADA:World Anti-bad-Duping Agency]

I(In reply to Jorg K from comment #4)
> treechildren::-moz-tree-row(dropOn) {
>   background-color: #ff8080 !important;
> }
> It is no longer working in 31.2.0 or 33 beta.

It worked well at Folder Pane in my Thunderbird Version 31.2.0(32bits, standard Theme) on Win.
But following didn't look to work. It seems "not supported yet".
> treechildren::-moz-tree-row(dropBefore) { background-color: #FF0000 !important; }
> treechildren::-moz-tree-row(dropAfter)    { background-color: #00FF00 !important; }

When "no longer working in 31.2.0"?
   (a) mouseover at a tree row where Drop is accepted.
   (b) mouseover at a tree row where Drop is not accepted.
If you are talking about  (b), it may be spec change of "dropOn".

I can't find string like 'treechildren::-moz-tree-row(dropOn) { background-color: #ff8080 !important; }' in your userChrome.css file attached to this bug.
Is userChrome.css correctly written when you tested?

Comment 7

[Jorg K (CEST = GMT+2)]

Attachment: Jorg K's userChrome.css

There seems to be a little confusion here, since there are two people complaining about different things related to userChrome.css.

I am complaining that the following doesn't work any more:
/* selected item */
treechildren::-moz-tree-row(dropOn) {
  background-color: #ff8080 !important;
}

Check **MY** attached userChrome.css (not the other guy's) to see it.

Comment 8

[Jorg K (CEST = GMT+2)]

Attachment: video showing the problem-1069419.zip

Two videos, one using 24.x, the other one 31.x.
Please see for yourself.
Please mark the bug as regression. How much more convincing does it need?

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to Jorg K from comment #7
> There seems to be a little confusion here, since there are two people
> complaining about different things related to userChrome.css.

Oh, sorry, you were not bug opener.

(In reply to Jorg K from comment #8)
> Please mark the bug as regression. How much more convincing does it need?

Do you understand my comment?
I said "your setting of 'dropOn' worked pretty well in my environment". i.e. I couldn't reproduce your problem.

Jorg K, can you check with following only in your userChrome.css for ease of trouble shooting?
> treechildren::-moz-tree-row(dropOn) {  background-color: #ff8080 !important; }

Comment 10

[Jorg K (CEST = GMT+2)]

Attachment: folder still not going red.zip

I understand what you said. I reduced my userChrome.css to these three lines:
treechildren::-moz-tree-row(dropOn) {
  background-color: #ff0000 !important;
}

You can what happens see in the video:
The red colour seems to appear, but it is hidden behind the highlight.

In 24.x the potential "dropOn" target goes red.

So I kindly request again that this bug be marked as a regression. Obviously something in the draw/fill order has changed and the result is, that the colour (almost) doesn't show any more.

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In reply to Jorg K from comment #10
> The red colour seems to appear, but it is hidden behind the highlight.

What is dragged to where?
  (a)  "Folder in folder pane" is dragged to "other folder in folder pane"?
  (b)   "Mail at thread pane(message list)" is dragged to "folder in folder pane"?
  (c)  Other?

If (b), "height of background of dragging item" is smaller than "height of tree row at folder pane". So you can not see phenomenon like "userchrome.css not honoured".

If (a), "box size of dragging item" is nearly same as "box size of tree row at folder pane".
So, iif dragging is dome from "icon of a folder" to "icon of other folder", it looks "hidden" for you.
Try dragging "folder icon" to "folder name text part of other folder".

I checked by (b) , and by (a) with dragging "folder name part" to "folder name part of other folder", so I couldn't see phenomenon like "userchrome.css not honoured ".

You ate talking about this phenomenon?
If so, it's not "hidden behind highlight". It's "partially hidden(or overlay) by background of dragging item".
And, it's observed in Tb trunk nightly(Tb 35.0a1, 2014/10/10 build was used) and Tb 31.2.0.

Comment 12

[Jorg K (CEST = GMT+2)]

OK, finally we are coming to an agreement here:

When dragging
(a) a folder in folder pane to other folder in folder pane
or
(b) one or more Mail mat thread pane (message list) to folder in folder pane
the following effect is observed:

The colour of the potential drog target as defined by
treechildren::-moz-tree-row(dropOn) { background-color: #ff0000 !important; }
is not clearly visible. It seems that it is hidden/overlaid the background colour of the item(s) being dragged.

This is a regression that didn't exist in 24.x. If makes the "dropOn" stuff pretty much useless.

So, since obviously I reported the problem to the wrong bug, should I create a different bug for it?

Thank you for your help clarifying the issue.

Comment 13

[WADA:World Anti-bad-Duping Agency]

(In reply to Jorg K from comment #12)
> should I create a different bug for it?

I think so, because your problem is never "userchrome.css not honoured" like one which is stated in bug summary of this bug.

Comment 14

[Jorg K (CEST = GMT+2)]

A new bug 1090840 has been created.

My apologies:
I observed the problem now described in bug 1090840 and at first thought that it fitted under the header "userChome.css not honoured". This is why I reported it here to save opening yet another bug.

So my apologies to the bug opener for hijacking his bug. You can safely ignore comment #3 to comment #13.