14.00 KB, image/png
36.44 KB, image/jpeg
38.05 KB, image/jpeg
1019 bytes, patch
Magnus Melin: review+
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) 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:126.96.36.199pre) 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.
FYI: I first mentioned this bug (as item #2) in bug 517617 (that bug is now resolved).
I can confirm this happens. I've never been able to unravel the mysteries of the filter editor CSS, however.
Created attachment 410092 [details] screen shot I confirm this w/ 20091014, 20091103 nightly. Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:188.8.131.52pre) Gecko/20091103 Shredder/3.0pre Decreasing and Increasing (or maximize the window) does not resolve this.
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.
I can't reproduce this in v184.108.40.206, 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
I've seen this reported several times in support forums, so I thing that I need to look at it some more.
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.
Created attachment 426473 [details] [diff] [review] min-width=40
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...
(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 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?
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.
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)
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 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.
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.
Comment on attachment 436995 [details] [diff] [review] use xul attribute instead of css Checked in http://hg.mozilla.org/comm-central/rev/083e3dae4e99
Comment on attachment 436995 [details] [diff] [review] use xul attribute instead of css checked in http://hg.mozilla.org/comm-central/rev/083e3dae4e99
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