297006 - No criteria rows displayed on Search Messages dialog box if sized too small or splitter moved too high

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Mike]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

On the Search Messages dialog, there are no criteria rows displayed, and there
is no way to get them to display.  Therefore, I can't do any searchess.  I've
tried unilstalling Thunderbird and re-installing it, but it doesn't fix the
problem. My guess is that somehow my user-specific configuration files have
become corrupted.

When I originally installed the software, the Search Messages worked. So I must
have done something that broke it. But I don't know what.

Reproducible: Always

Steps to Reproduce:
I don't know. If you e-mail me, I supposed I could send you any configuration
files you think might be significant.

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Mike]

This bug is driving me nuts. Somehow, during the first month or so of using
Thunderbird, I got the Search Messages dialog box to have no filters listed. I
assume the More button is intended to add new filters, but it doesn't do
anything. So, at this point, I have no way of doing searches. (Maybe it's that I
don't know how to use the GUI.) I tried re-installing Thunderbird, but that
didn't fix it. So I'm thinking maybe it's something that's been corrupted my
user configuration files. Please feel free to contact me at
[e-mail] if you have any questions or would like me to send
you any files.

Comment 3

[Laura Prowicz]

I definitely have this same problem. I have played with the client endlessly and
reinstalled several times but no criteria. 

It's a pain having to page through tons of emails to find old ones when I know
the words in the subject line or the sender....

Laura [e-mail]

Comment 4

[Mike Cowperthwaite]

See bug 317915 comment 3.  If the Search Messages dialog with the problems is the same as attachment 204269 [details], the problem is user error, and this bug should be resolved as Invalid.

Comment 5

[Laura Prowicz]

(In reply to comment #4)
> See bug 317915 comment 3.  If the Search Messages dialog with the problems is
> the same as attachment 204269 [details] [edit], the problem is user error, and this bug should
> be resolved as Invalid.


"Draggable splitter" aye. Problem is I'm what I would consider a serious power user and this evaded me. Imagine the general public trying to sort through this. 

Laura

Comment 6

[Mike]

See bug 317915 comment 3.  If the Search Messages dialog with the problems is
the same as attachment 204269 [details], the problem is user error, and this bug should
be resolved as Invalid.

Comment 7

[Mike]

I am a software developer myself, and even though this was a user error, I probably never would have dicovered what I was doing wrong. Someone should probably review the interface design and see if there is some way to prevent this scenario.

Comment 8

[Mike Cowperthwaite]

I agree that the UI for this is bad.  Part of the issue is, Toolkit apps (Firefox and Thunderbird) do not have a "grippy" on the splitters; Mozilla did and Seamonkey does, and that makes the splitter quite visible.
The change for Thunderbird, at least, was a deliberate decision; see bug 214361. I don't know whether the extension mentioned at that bug will add the grippy for the Search Messages window or only for the splitters in the 3-pane, nor whether the extension is current.

Another part of the problem is that the layout for the Search Messages dialog does not put the splitter directly between the "panes".  If the splitter is going to be drawn featureless, it should be placed exactly at the lower border of the criteria list and the at top border of the results list; instead, both lists are inset a bit , so the splitter is swallowed up by inactive dialog-background space, and does not appear as the splitters do in the 3-pane window.

Finally, as a bit of a respite: version 1.5 and later have a slightly larger minimum height for the criteria list, so it can't be collapsed to total invisibility as it can in 1.0.x.

The larger margin around the results list is due to a specific problem, for 
which I've opened bug 320258.  The rest of the appearance issues are a factor 
of the skin's CSS (searchDialog.css), and could be customized if desired, or tweaked in the default or any other skin.  
   the splitter itself is    #gray_horizontal_splitter
   the criteria listbox is   #searchTermList
   the results list is       #searchResultListBox  (xref bug 320258)
(searchDialog.xul is zipped into messenger.jar, searchDialog.css is zipped into classic.jar)
See also the rules in splitter.css (also in classic.jar).

Comment 9

[Mike Cowperthwaite]

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

Comment 10

[Mike Cowperthwaite]

(In reply to comment #8)
> The larger margin around the results list is due to a specific problem, for 
> which I've opened bug 320258.  The rest of the appearance issues are a factor 
> of the skin's CSS (searchDialog.css), and could be customized if desired, or
> tweaked in the default or any other skin.  
>    the splitter itself is    #gray_horizontal_splitter
>    the criteria listbox is   #searchTermList
>    the results list is       #searchResultListBox  (xref bug 320258)

Bug 320258 is fixed on the trunk.  Even without the fix, tho, I've found the following fixes this bug's main problem: add to userChrome.css the following rule:
  #searchTermList { min-height: 3em; }

This keeps the list from shrinking too small.  (The same rule fixes the problem in the Search Addresses window, too.)  It doesn't do anything to improve the appearance of the splitter.

Comment 11

[Mike Cowperthwaite]

The tweak described in comment 10 also fixes an identical problem in the Filter Rules dialog box (bug 180144).

Comment 12

[Frederick Luehring]

This is my first interaction with Bugzilla please forgive me if I am not following proper protocols. I am having a problem very similar to what is reported here that just started when I upgraded to Thunderbird 3.0 a couple of weeks ago. I am running on Mac OS X (Leopard). When I open the Search Messages dialog I cannot add additional lines of search criteria by hitting the plus sign (+) button. The current line simply redraws with the entered search criteria deleted and no additional search criteria lines can be added. After searching Bugzilla and finding this bug, I  found that maximizing the size of the Search Messages window that I could add search criteria lines. The Search Messages window where adding lines failed was approximately the size that it had been when I used version 2 of Thunderbird. The failing window was of a reasonable size and not small.

Comment 14

[Wayne Mery (:wsmwk)]

bug 494039 has a screen shot

Comment 18

[Nicolas Mandil (:NicolasWeb)]

Could the reporter add regressionwindow-wanted to the keywords.
Not so sure that this is a minor one : it make a basic (and old) feature totaly ununsable.

Why not asking for "blocking-thunderbird3.2 ?" ?

Comment 19

[Nicolas Mandil (:NicolasWeb)]

Please, add the keyword "useless-UI" so we can decide something for the next release ;-)

Comment 20

[Wayne Mery (:wsmwk)]

Nicolas, I don't see how this bug is any of the things you have suggested; as far as I know it is not a regression, and it isn't "unusably broken" - one just resizes the window and it's permanently fixed unless the user fiddles with window size again.  But if that's not correct, then this is more severe than minor. (Please read the descriptions at https://bugzilla.mozilla.org/page.cgi?id=fields.html#importance and https://bugzilla.mozilla.org/describekeywords.cgi#useless-UI )

perhaps ux-control or ux-discover is appropriate.  But neither is essential to understanding the issue or the need for the fix - the UI is there but broken because a minimum size needs to be imposed on the window. (I have wondered how someone can get in this situation and not know they did it.)

Comment 21

[:aceman]

Does this still happen for anybody?
I can't see this in TB14. Using the splitter in the search dialog I can sqeeze the rules list to one item but not hide it completely as the reported describes. On the other hand, it is possible to hide the bottom part with the search results. Should that be disallowed too? I think I could do it.

Comment 22

[John I Davies]

(In reply to :aceman from comment #21)
> Does this still happen for anybody?
> I can't see this in TB14. Using the splitter in the search dialog I can
> sqeeze the rules list to one item but not hide it completely as the reported
> describes. On the other hand, it is possible to hide the bottom part with
> the search results. Should that be disallowed too? I think I could do it.

The problem has not existed for several releases as far as I can tell. It certainly existed several years ago when I first signed up for notifications about the bug. Since its easy to work around once you know how, and the fix persists for each user, it is not possible to tell when it was fixed without actually forcing it to happen which, mea culpa, I have not done in those intervening years.

Comment 23

[:aceman]

Can you see the problem when moving the splitter down?

Comment 24

[John I Davies]

Attachment: screen shot of T'bird search with splitter set low

see reply to -
Subject: 	[Bug 297006] No criteria rows displayed on Search Messages dialog box if sized too small or splitter moved too high
Date: 	Wed, 18 Apr 2012 10:07:38 +0000
From: 	[e-mail]
To: 	[e-mail]


Do not reply to this email. You can add comments to this bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=297006

--- Comment #23 from :aceman <[e-mail]> 2012-04-18 03:07:38 PDT ---
Can you see the problem when moving the splitter down?

-- 
Configure bugmail: https://bugzilla.mozilla.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Comment 25

[John I Davies]

(In reply to John I Davies from comment #24)
> Created attachment 616071 [details]
> screen shot of T'bird search with splitter set low
> 
> see reply to -
> Subject: 	[Bug 297006] No criteria rows displayed on Search Messages dialog
> box if sized too small or splitter moved too high
> Date: 	Wed, 18 Apr 2012 10:07:38 +0000
> From: 	[e-mail]
> To: 	[e-mail]
> 
> 
> Do not reply to this email. You can add comments to this bug at
> https://bugzilla.mozilla.org/show_bug.cgi?id=297006
> 
> --- Comment #23 from :aceman <[e-mail]> 2012-04-18 03:07:38 PDT ---
> Can you see the problem when moving the splitter down?
> 
> -- 
> Configure bugmail: https://bugzilla.mozilla.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

Similar problem with splitter all the way down - when Windows "taskbar" pops up and conceals number of matches found. Note that Windows often locks the taskbar in the up position (It seems to be related to some [unflagged] call for user attention) If this happens the user will see no indication that the search found anything. See JPG screenshot also submitted

Comment 26

[:aceman]

Ok, would a solution be if the splitter couldn't be dragged all the way down? Like today it can't be dragged up, it always leaves at least one rule line visible. Should it always leave some space for the results, not allowing to fully collapse them?

Comment 27

[John I Davies]

(In reply to :aceman from comment #26)
> Ok, would a solution be if the splitter couldn't be dragged all the way
> down? Like today it can't be dragged up, it always leaves at least one rule
> line visible. Should it always leave some space for the results, not
> allowing to fully collapse them?

Yes that would solve it. Its a bit messy since the space to be left would be dependent upon the depth of the windows taskbar - which can be increased by dragging its splitter upwards. A neater solution would perhaps be to show the number of hits just below the search criteria. Then it couldn't be obscured by any "lower frame" on the screen, whether a Windows taskbar or something else in, say, linux Gnome/KDE/etc.

Comment 28

[:aceman]

I am not sure we can (or want) to fight the OS (desktop environment). After all, the user can want the window to be obscured otherwise he wouldn't allow it to span behind the taskbar (he can set it to only expand to the taskbar). Yes, for you the OS behaviour (taskbar) is not what you want, but somebody could want it (or the taskbar hides properly).

This wrong behaviour can happen in any window/dialog and we also do not fight it. E.g. What do you do when the TB statusbar is hidden by the taskbar?

So, the original report is not about OS obscuring TB's windows, but that the splitter can be moved so that the search rules are hidden and it is not apparent for the user where they are and how to get them back. That one we can solve.

Comment 29

[John I Davies]

(In reply to :aceman from comment #28)
> I am not sure we can (or want) to fight the OS (desktop environment). After
> all, the user can want the window to be obscured otherwise he wouldn't allow
> it to span behind the taskbar (he can set it to only expand to the taskbar).
> Yes, for you the OS behaviour (taskbar) is not what you want, but somebody
> could want it (or the taskbar hides properly).
> 
> This wrong behaviour can happen in any window/dialog and we also do not
> fight it. E.g. What do you do when the TB statusbar is hidden by the taskbar?
> 
> So, the original report is not about OS obscuring TB's windows, but that the
> splitter can be moved so that the search rules are hidden and it is not
> apparent for the user where they are and how to get them back. That one we
> can solve.

Agreed. We can't, in general, solve OS problems in an application. However someone needs to consider "J Random User". Probably a broader, policy, issue for Mozilla generally. Not your department, I guess. Its certainly above my pay grade! 
I'm away tomorrow. Look me up at www.flying-boat.co.uk if you are interested.

Comment 30

[:aceman]

Bwinton, would you agree making the search results part not completely collapsible?

Comment 31

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

Yeah, that makes sense to me.

Comment 32

[:aceman]

Attachment: patch

Ok, I've done it for Seamonkey too, will see if they want it too.

Comment 33

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

Comment on attachment 616229 [details] [diff] [review]
patch

Looks good to me, at least on the Thunderbird side.  :)

ui-r=me.

And while I'm here, r=me for the Thunderbird bits, too.

Later,
Blake.

Comment 34

[Ian Neal]

Could I have some steps to reproduce the problem, as at the moment I cannot see it on TB with or without the patch?

Comment 35

[:aceman]

The original report does no longer apply.
What is left is that it is possible to drag the splitter down and it collapses the search results part of the dialog. It is not know why that would be beneficial and it confuses the user where the list and buttons went. The patch just prevents that.

Comment 36

[Ian Neal]

Comment on attachment 616229 [details] [diff] [review]
patch

r=me

Comment 37

[Ryan VanderMeulen [:RyanVM]]

http://hg.mozilla.org/comm-central/rev/4b8c1efc5d9f