Enabled column in Message Filters does not track dialog size properly

RESOLVED FIXED in Thunderbird 3.1b2

Status

MailNews Core
Filters
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: MrC, Assigned: rkent)

Tracking

({regression})

1.9.1 Branch
Thunderbird 3.1b2
x86
Windows XP
regression

Thunderbird Tracking Flags

(thunderbird3.0 .5-fixed)

Details

(URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090922 Shredder/3.0pre

The Enabled column does not position properly when the dialog is widened,
and then width decreased.  

Reproducible: Always

Steps to Reproduce:
1.Increase the Message Filters dialog width to be wider than the number of items, so that no scrollbar appears.  Any scrollbar repainting prevents the
problem from being exhibited.
2. Now reduce the dialog width (don't decrease the height of the dialog).
3.Note how the Enabled column's checkboxs are missing.  Decreasing the height of the dialog (to that which will cause scrollbars to be created) will move the Enabled checkboxes to within the dialog.
Actual Results:  
Dialog's Enabled checkboxes are not shown within the dialog (nor are under the Enabled column).

Expected Results:  
Enabled checkboxes should always appear under the Enabled column.  Repainting of the dialog contents should occur as the dialog is resized.
(Reporter)

Comment 1

8 years ago
FYI: I first mentioned this bug (as item #2) in bug 517617 (that bug is now resolved).
(Assignee)

Comment 2

8 years ago
I can confirm this happens. I've never been able to unravel the mysteries of the filter editor CSS, however.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 410092 [details]
screen shot

I confirm this w/ 20091014, 20091103 nightly.
Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.1.6pre) Gecko/20091103 Shredder/3.0pre

Decreasing and Increasing (or maximize the window) does not resolve this.
Duplicate of this bug: 537487
Workaround:
  1. Reduce panel width to normal size => check box is hidden
  2. Change focus to other, then move focus back to filter list
  2-a. Click title bar or status bar, then click filter list box
  2-b. Expand selection list(Filters for:/Run selected folders on:) and close
  2-c. Click column header(Filter Name, Enabled)
  => Check box re-appears.
(Assignee)

Updated

8 years ago
Component: General → Filters
Product: Thunderbird → MailNews Core
QA Contact: general → filters
I can't reproduce this in v2.0.0.21, so => regression
core or theme bug?  
- https://bugzilla.mozilla.org/buglist.cgi?short_desc=css%20width;bug_severity=major;bug_severity=normal;resolution=---;query_format=advanced;short_desc_type=allwordssubstr;product=Core;product=Firefox
- is it definitely a css issue? 

littlebird theme 1.8.56 https://addons.mozilla.org/en-US/thunderbird/addon/1493  on 2 machines is slightly different, and makes using littlebird unusable for me, but maybe it's because the Enable column checkbox is just missing. 

On desktop I immediately see attachment (id=410092) without resizing.
On my laptop at home, I don't see the slider column go underneath Enable column ever.

3.0.1
Keywords: regression
Version: unspecified → 1.9.1 Branch
(Assignee)

Comment 7

8 years ago
I've seen this reported several times in support forums, so I thing that I need to look at it some more.
Assignee: nobody → kent
Status: NEW → ASSIGNED
hook up go gsfn http://gsfn.us/t/pj7x
Whiteboard: [gs]
(Assignee)

Comment 9

8 years ago
There are definitely some strange behaviors in the way that the "enable" column displays. For example, if you expand the width of the filter list dialog, then shrink it, then expand it, then the enabled column does not reappear until the width returns to its widest value. You can keep making it wider and wider, until eventually the only time the enable column appears is when the width is at its widest. To make the enable column reappear normally, what you need to do is to set the width of the filter list dialog to a normal value, close it, the reopen it again.

But that is not what is going on here. If the width of what would be in English the "Enabled" text is very small, as it is in Japanese, and the number of filters is so large that a scroll bar is needed, then the scroll bar covers up the "Enabled" columns completely, regardless of the width of the filter list dialog.

I can simulate that by replacing "Enabled" with "A". See the attached screenshot. For my simulation, I can then fix the problem by adding a minimum width to the listheader element. That is what I will do in a patch.
(Assignee)

Comment 10

8 years ago
Created attachment 426470 [details]
Simulated problem
(Assignee)

Comment 11

8 years ago
Created attachment 426471 [details]
Simulated solution: min-width=40
(Assignee)

Comment 12

8 years ago
Created attachment 426473 [details] [diff] [review]
min-width=40
Attachment #426473 - Flags: review?(mkmelin+mozilla)
(Assignee)

Updated

8 years ago
Whiteboard: [gs] → [gs][needs review mkmelin]

Comment 13

8 years ago
The patch doesn't fix everything.
Resize the dialog box bigger (much bigger), and than much smaller.
The enabled checkmarks still disappear, and won't back easily...
(Assignee)

Comment 14

8 years ago
(In reply to comment #13)
> The patch doesn't fix everything.
> Resize the dialog box bigger (much bigger), and than much smaller.
> The enabled checkmarks still disappear, and won't back easily...

That was one of the main points of my comment 9, that there are multiple issues, but I would like to focus on just one here (which it what the OP showed) to make some progress. The issue I addressed in the patch is rarer than the one described in comment 9 and comment 12, but it has no easy workaround unlike that issue.

Comment 15

8 years ago
Comment on attachment 426473 [details] [diff] [review]
min-width=40

I'm not really able to reproduce the problem this would fix. (Though there's obviously a lot of wackiness there.) 

Not that is would break anything either. How about a minwidth attribute in xul instead though?
(Assignee)

Comment 16

8 years ago
To reproduce, I made a custom XUL file to replace the "enabled" text. Not optimal I realize. Tried to load Japanese, but it was clear it was going to need more than just installing the downloaded file to get it to work on my system.

By "minwidth attribute in xul" do you mean hardwired in the .xul file, instead of adding it as a style? It's all the same to me, but I am not really that familiar with the standard expectations of what goes where in XUL and CSS.

This seems low risk to solve a problem which is quite severe in Japanese looking at the example, but it is rare otherwise. As you say there is plenty of wackiness beyond this issue, which is also the point of comment 13.

Comment 17

8 years ago
Hello

this problem also does occur with european characters, once the number of filters is too big to fit in one window (which is the case for several of my mailboxes)
(Assignee)

Comment 18

8 years ago
With Arnaud's ping, I realize this patch is left hanging. Mkmelin, could you answer my question in comment 15? Added you to the cc list to make sure you are getting this.

Comment 19

8 years ago
Comment on attachment 426473 [details] [diff] [review]
min-width=40

Sorry, missed it since i forgot to cc in.

I'd prefer the xul approach, especially to avoid having 3rd party themes bitten by it.
Attachment #426473 - Flags: review?(mkmelin+mozilla) → review+
(Assignee)

Comment 20

8 years ago
Created attachment 436995 [details] [diff] [review]
use xul attribute instead of css

I revised this patch to move the minwidth into the xul attribute, as requested.
Attachment #426473 - Attachment is obsolete: true
Attachment #436995 - Flags: review?(mkmelin+mozilla)

Updated

8 years ago
Attachment #436995 - Flags: review?(mkmelin+mozilla) → review+
(Assignee)

Comment 21

8 years ago
Comment on attachment 436995 [details] [diff] [review]
use xul attribute instead of css

Checked in http://hg.mozilla.org/comm-central/rev/083e3dae4e99
(Assignee)

Updated

8 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
status-thunderbird3.0: --- → ?
Resolution: --- → FIXED
Whiteboard: [gs][needs review mkmelin] → [needs approval 3.0.x]
Target Milestone: --- → Thunderbird 3.1b2
(Assignee)

Updated

8 years ago
Attachment #436995 - Flags: approval-thunderbird3.0.5?
(Assignee)

Comment 22

8 years ago
Comment on attachment 436995 [details] [diff] [review]
use xul attribute instead of css

checked in http://hg.mozilla.org/comm-central/rev/083e3dae4e99
Attachment #436995 - Flags: approval-thunderbird3.0.5? → approval-thunderbird3.0.5+
(Assignee)

Comment 23

7 years ago
Comment on attachment 436995 [details] [diff] [review]
use xul attribute instead of css

Checked in http://hg.mozilla.org/releases/comm-1.9.1/rev/15da4205b86b
(Assignee)

Updated

7 years ago
status-thunderbird3.0: ? → .5-fixed
(Assignee)

Updated

7 years ago
Whiteboard: [needs approval 3.0.x]
You need to log in before you can comment on or make changes to this bug.