180144 - Filter editing UI: filter conditions group can fail to have a scroll bar if sized too small - so it seems unable to have multiple criteria, rules are missing

Status: RESOLVED FIXED

(MailNews Core :: Filters, defect)

Description

[Todd Pederzani]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021114
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021114

When editing a filter, the box that contains the conditions for the filter can
be missing a scroll bar if your dialog is sized small enough vertically.

Reproducible: Always

Steps to Reproduce:
1. Edit a message filter
2. Resize your window vertically so that you can only see part of the text of
the condition to match
3. Click on the "More" button to add another filter condition
Actual Results:  
If you've sized your window small enough, even though another condition was
added, no scroll bar will be visible.  If you resize your window now, you can
get the scrollbar to appear - mine did when the first pixel of the condition box
for the second condition appeared.


I'm using the classic theme on a nightly I downloaded this morning.  This caused
me a bit of confusion initially, as my window was sized perfectly to trigger the
bug; I thought the additional conditions were not being added.

Comment 1

[Sander]

*** Bug 190519 has been marked as a duplicate of this bug. ***

Comment 2

[Sander]

*** Bug 193165 has been marked as a duplicate of this bug. ***

Comment 3

[Sander]

*** Bug 191639 has been marked as a duplicate of this bug. ***

Comment 4

[Sander]

Confirming. I hope to tackle this within the next two weeks, but if someone
wants to fix this sooner (or if I don't find time after all), please don't let
that stop you. 

Comment 5

[Sander]

*** Bug 180137 has been marked as a duplicate of this bug. ***

Comment 6

[Sander]

*** Bug 194250 has been marked as a duplicate of this bug. ***

Comment 7

[Sander]

People should no longer see this occurring without having resized the window 
themselves due to the fix for bug 183994. Don't know if the underlying problem 
is fixed as well - will check with a nightly in a few days. (If so, this is a 
dupe.) Regardless, this is not something I'm going to do anymore.

Comment 8

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 9

[Mike Cowperthwaite]

Per comment 7: underlying problem is not fixed, duplicated in 
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

Comment 10

[Mike Cowperthwaite]

This bug can be easily addressed with the same fix described at 
bug 297006 comment 10 -- that one CSS tweak fixes the problem here and 
at that bug, as the ID of the criteria box is the same is all those dialogs.

Comment 11

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 12

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 15

[Wayne Mery (:wsmwk)]

kent, I collected all the gsfn examples I could find into http://gsfn.us/t/qu2u

Comment 19

[Wayne Mery (:wsmwk)]

I consolidated several more gfsn articles.

xref Bug 205039 - Filter Rules window needs a splitter

Comment 21

[Kent James (:rkent)]

Attachment: Set minimum heights

This bug has become a collecting point for a very common user support issue, when they set the filter dialog too small somehow, and lose critical UI elements.

Though I rarely venture into UI fixes, either I'm missing something, or we just need to set some minimum heights here. So let me toss this patch into the hopper, and see what the real UI people think (or inspire them to propose something better).

Comment 22

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 528541 [details] [diff] [review]
Set minimum heights

Review of attachment 528541 [details] [diff] [review]:

This certainly seems better, but I wonder if we can also set a minimum size on the dialog as a whole…

Oh, and I think we want some sort of minimum width, since resizing horizontally really messes things up, but it mostly fixes itself if we then resize vertically…

So, all in all, a bunch of weird things are happening here, and while I think this patch makes some of them a little better, I think there's still a bunch of work to do.

Uh, I guess that translates into r=me, but I would appreciate it if you did a little more on this.  ;)

Thanks,
Blake.

Comment 23

[Kent James (:rkent)]

"I would appreciate it if you did a little more on this"

Yes it needs more work. I keep hoping that someone who is more familiar with issues in front end bugs will get motivated to work on this. But for now, I'm tired of the support issues on this, and just want to solve the worst pain point.

Comment 24

[Kent James (:rkent)]

Comment on attachment 528541 [details] [diff] [review]
Set minimum heights

Checked in http://hg.mozilla.org/comm-central/rev/13132fc6dd1b

Comment 25

[Serge Gautherie (:sgautherie)]

Comment on attachment 528541 [details] [diff] [review]
Set minimum heights

http://hg.mozilla.org/releases/comm-2.0/rev/2f118df0ef18