150102 - Search Sidebar: hide Previous and Next buttons instead of disabling

Status: RESOLVED EXPIRED

(SeaMonkey :: Search, defect)

Description

[Matthew A. McGuigan]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
BuildID:    2002060511

"Previous" and "Next" buttons area should not display, when the functions are
not  defined for the search plugin(s) in use.  When a users favorite search
engine has dimmed out "Next" and "Previous" buttons in the side bar that don't
function, many an end user will think that the Mozilla search panel or plugin is
broken.

Reproducible: Always
Steps to Reproduce:
1.Choose search plugin without inputnext or inputprev defined.
2. Perform a search.


Actual Results:  Next and Previous buttons appear in the sidebar search panel,
but are grayed out.  

Expected Results:  No Next and Previous buttons in the panel if they are not
activated in the plugin.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Would this involve shifting around any other buttons?

Comment 2

[Jesse Ruderman]

I think it would be more confusing to hide the buttons than to disable them.  If
they're hidden, users would wonder if there are more search results when there
are actually 10.

Comment 3

[Matthew A. McGuigan]

I'm not sure I understand your comment. If there are 10 more search results and
the plugin makes use of the function then the buttons would be enabled and in
plain view. 

Perhaps I worded this poorly.

I'm not suggesting that the buttons be hidden because there are no next or
previous results available on a search using a plugin that makes use of the next
and previous buttons, though I don't think that would be a bad thing.  I'm
suggesting that they should be hidden if the plugin doesn't make use of the next
and previous buttons(IOW, they are not defined in the search plugin to begin
with).  

Comment 4

[Erich 'Ricky' Iseli]

Confirming this. Discussion will tell whether it's a bug or a wontfix

Comment 5

[R.K.Aa.]

is this related to bug 149631?

Comment 6

[Erich 'Ricky' Iseli]

Rather related to bug 149631, it's a blocker of bug 57855 (which is about the
implementation of these buttons.

Comment 7

[timeless]

uid is being phased out.

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420