Bug 883440

Summary: Quick search text field is too small
Product: [Community] Bugzilla Reporter: Tom McKay <tomckay>
Component: User InterfaceAssignee: Matt Tyson <mtyson>
Status: CLOSED CURRENTRELEASE QA Contact: tools-bugs <tools-bugs>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.2CC: jingwang, mtyson, rjoost
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 4.4-3 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-20 18:06:52 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
screenshot for comment4
none
screenshot for comment13 none

Description Tom McKay 2012-12-04 10:47:08 EST
The search textfield in the web UI is very small. It is fine for simple search strings, but loses usefulness for longer queries. For example,

NEW,ASSIGNED product:"Subscription Asset Manager" assignee:tomckay@redhat.com
_______________________  <-- Size of textfield

Also, in Firefox as I start to type a search it shows a list of previously entered searches but since the drop down list is only as wide as the textfield, the previous searches are all cut off too.

It would be fantastic if this was configurable in some way, even if I could just move the search to its own line in the header.
Comment 1 Simon Green 2012-12-16 22:43:22 EST
I've got no objection to making the text box bigger if you focus in the bug. I assume this is possible with some Javascript.
Comment 2 Matt Tyson 2013-03-03 18:37:31 EST
I've added some js that will make the search box expand as you type.

Its clamped at an upper limit (currently 500px) to avoid breaking the page if too much text is typed.
Comment 4 wangjing 2013-05-08 05:58:56 EDT
Verified on qe test env version 4.4.rc2-3(20130426) --> FAIL

Verify steps:
1. open the homepage of bugzilla.
2. type ' NEW,ASSIGNED product:"Subscription Asset Manager" assignee:tomckay@redhat.com ' in the  textfield of Quick Search box which appears at the top and bottom of the page seperately.
3. check the textfield of Quick Search box.

then expected result: the textfield of Quick Search box should  expand when typing the long strings. And the textfields both on top and at bottom should be the same.

4. paste this conditions in the  textfield:' NEW,ASSIGNED product:"Subscription Asset Manager" assignee:tomckay@redhat.com '.
5. check the textfield.

then expected result: the textfield of Quick Search box shoulde expand to adjust its size to display this long query not to be cut off at least.

Actual results:
after step3:
the textfield on top is not the same as it at bottom when typing in the same long strings. the screenshot attached.

after step5: when pasting the long query in the textfield, we should click some key on keyboard, such as 'tab', then the textfield will expend. is this by definition? I don't think it's easy to use.
Comment 5 wangjing 2013-05-08 06:01:04 EDT
Created attachment 745168 [details]
screenshot for comment4
Comment 6 Simon Green 2013-05-08 21:08:57 EDT
(In reply to comment #4)
> after step5: when pasting the long query in the textfield, we should click
> some key on keyboard, such as 'tab', then the textfield will expend. is this
> by definition? I don't think it's easy to use.

It's a limitation of the Javascript used. If you are copying and pasting, I don't see it as a big issue.

  -- simon
Comment 7 wangjing 2013-05-09 04:58:07 EDT
(In reply to comment #6)
> (In reply to comment #4)
> > after step5: when pasting the long query in the textfield, we should click
> > some key on keyboard, such as 'tab', then the textfield will expend. is this
> > by definition? I don't think it's easy to use.
> 
> It's a limitation of the Javascript used. If you are copying and pasting, I
> don't see it as a big issue.
> 
>   -- simon

IMO, the operation was not that handy.

another one, what's ur opinion about thus in comment4:
'after step3:
the textfield on top is not the same as it at bottom when typing in the same long strings. the screenshot attached.'
Comment 8 Simon Green 2013-05-09 08:32:31 EDT
(In reply to comment #7)
> another one, what's ur opinion about thus in comment4:
> 'after step3:
> the textfield on top is not the same as it at bottom when typing in the same
> long strings. the screenshot attached.'

The screenshot shows the bottom query string is 500 pixels wide. This is the maximum width this text box will go.

  -- simon
Comment 9 wangjing 2013-05-09 10:33:51 EDT
(In reply to comment #8)
> (In reply to comment #7)
> > another one, what's ur opinion about thus in comment4:
> > 'after step3:
> > the textfield on top is not the same as it at bottom when typing in the same
> > long strings. the screenshot attached.'
> 
> The screenshot shows the bottom query string is 500 pixels wide. This is the
> maximum width this text box will go.
> 
>   -- simon

see they are not in the same size, right?
Comment 10 Roman Joost 2013-05-10 01:25:43 EDT
The input field does exactly what is implemented and mentioned in Matt Tyson's comment: "will make the search box expand as you type." Therefore pasting text is technically different to typing it in. So, if it expands as you type, it does exactly what it should. Test pass.

Perhaps it should have been better specified/designed in the first place, before implementing it to avoid this confusion. It would lead to a better user acceptance.

Having said that, I'm happy to ship 4.4-3 with a quick search input field which doesn't expand when pasting text. The performance improvements this release will bring are far more important than a not expanding input field when pasting text. If that is important, please file a new bug report.

Thank you for your understanding.
Comment 11 wangjing 2013-05-10 03:24:13 EDT
(In reply to comment #10)
> The input field does exactly what is implemented and mentioned in Matt
> Tyson's comment: "will make the search box expand as you type." Therefore
> pasting text is technically different to typing it in. So, if it expands as
> you type, it does exactly what it should. Test pass.
> 
> Perhaps it should have been better specified/designed in the first place,
> before implementing it to avoid this confusion. It would lead to a better
> user acceptance.
> 
> Having said that, I'm happy to ship 4.4-3 with a quick search input field
> which doesn't expand when pasting text. The performance improvements this
> release will bring are far more important than a not expanding input field
> when pasting text. If that is important, please file a new bug report.
> 
> Thank you for your understanding.

hi~ roman~
did u see the screenshot attached, the size of the quick search boxes on the top and at the bottom were not the same.

yes, I know v4.4-3 was expected by people, we could release v4.4-3 firstly, but how will this feature be it's better to make clear on this bug before closing it.

this bug is not high Priority.

thanks~
Comment 14 wangjing 2013-05-16 07:30:03 EDT
Created attachment 748759 [details]
screenshot for comment13
Comment 18 Tom McKay 2013-05-20 12:30:17 EDT
I disagree that this is fixed. Note from my original report:

Also, in Firefox as I start to type a search it shows a list of previously entered searches but since the drop down list is only as wide as the textfield, the previous searches are all cut off too.

The solution implemented is less than optimal since it only expands as you type. Even selecting one of the auto-complete choices in firefox I still need to move the cursor for the text field to expand.

Also, when the search is complete the search box goes back to being too small so the search string just queried is hidden if it is long. Once again the mouse cursor must be moved in the text field for it to expand (focus does not enlarge it).

A simpler solution that covered all cases would have been to simply expand the width on focus. You could have, optionally, reduced the size back to length required to display entered text when focus left.
Comment 19 Simon Green 2013-05-20 18:06:52 EDT
(In reply to Tom McKay from comment #18)
> I disagree that this is fixed. Note from my original report:

Please file this a new bug. This bug has been release, and we will not retarget an existing released bug.

  -- simon