Closed Bug 56969 Opened 24 years ago Closed 23 years ago

Sidebar should not appear when I use a Web search site

Categories

(SeaMonkey :: Search, defect, P3)

Product:
SeaMonkey
Component:
Search
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED INVALID
Milestone:
mozilla0.9.8

People

(Reporter: mpt, Assigned: samir_bugzilla)

References

Details

Build: 2000101620, Mac OS 9.0

To reproduce:
* Start Navigator.
* Turn the sidebar off.
* Visit <http://www.google.com/>, or <http://www.altavista.com/>.
* Type some words in the Web site's search field, and press Enter.
* Wait for the results to load.

What happens:
* The sidebar opens, showing a list of results which duplicates that shown in
  the Google results page.

What was expected:
* Since I have the sidebar turned off, and I didn't do my Web search using the
  sidebar or any other part of the Navigator chrome, the sidebar should @#%! off
  and leave me alone.

Search results should only be displayed in the sidebar if one of the following is 
true:
(1) I use the sidebar search panel to carry out the search;
(2) I use the location bar to carry out the search, AND the `Open the Search tab
    in My Sidebar when search results are available' option is turned on.
this is not how the search sidebar was designed to work. Now, I do agree that if I used the
view menu to turn the sidebar off (not just minimize it) then I don't want to see the @#$%
thing, but I lost that battle long ago. Plus, that is _precisely_ what the pref is for. There's
no bug here, notice the wording of the pref - "when search results are available" we're
agnostic as to the origin of the results.

The whole point is so you can feel free to surf on from the results page (eg follow the results)
and not have to navigate back to it to view a different result - because they are in your search
sidebar panel.

I understand the usefulness of holding search results in the sidebar panel. And 
on the occasions when I want that, I will search using the location bar or the 
sidebar itself. I will be entering my search in the chrome, so it makes sense to 
show my results in the chrome.

But when I'm doing a search *within a Web site* and I am not even aware that the 
site happens to be one of the search services listed in my prefs, opening the 
sidebar all the time is just bad manners.

*** Bug 59076 has been marked as a duplicate of this bug. ***
*** Bug 59672 has been marked as a duplicate of this bug. ***
Since two _bugs_ (not requests to change the current behavior) have been filed 
on this issue, I think it's worth looking into.  Anyone with a good 
UI/usability proposal?
so how about we just disable the pref by defualt.  If there are marketing issues
then this may be a situation like javascript in mail-news where mozilla and
netscape set a differnt defualt.

Disabling the pref by default is just going to reduce the number of people 
affected by the bug by n (where n is the proportion of people who never touch the 
pref); it's not going to actually fix the bug.

My UI/usability proposal is described in the `What was expected' section of the 
bug report.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
*** Bug 62077 has been marked as a duplicate of this bug. ***
*** Bug 62077 has been marked as a duplicate of this bug. ***
*** Bug 62794 has been marked as a duplicate of this bug. ***
I still don't see how this is a bug and not just a "request to change the current behavior"
(as Blake put it). The feature is working as designed, you are asking for a design change.

I thought the proposal to default the pref the other way would be a fine sol'n. As I understand
it you (mpt) want the following: You as Joe User has gone in and specifically set the pref
to "open the Search tab in my Sidebar when results are available" yet when you've turned
the sidebar off via the View menu you want your pref setting to be ignored?

I really believe this is not a bug. If you don't want search results when you do a search that
doesn't originate from the panel you don't have to have them - we've provided a pref just
for that.

Bear in mind, my true feelings are on the other side of this issue - I belive View-->Off
should make the sidebar go away forever until I call it back, but that battle was fought many
months ago. That pref was the compromise. I'm just saying don't masquerade this as some
newly found 'bug'. What we have here is simply a difference of opinion about a design issue.

This bug is a request for design change, yes.  But the two bugs duped against 
it are just that -- bugs; their reporters really thought there was incorrect 
and buggy behavior.
Make that five dups.  I don't understand how there can't be a design flaw here.
FWIW, I disagree with this bug. I *like* it that the sidebar opens, and there
*is* a pref for turning this feature off. Of course, having it off as default
would perhaps be a good idea.
*** Bug 62794 has been marked as a duplicate of this bug. ***
Unexpected behaviour is a bug, a design that prompts undesigned behaviour is a 
bad design.  Bad design is a bug.  Requesting a change to bad design is a bug 
report not an enhancement request.

In general, any situation where an application behaves differently from how the 
user was expecting it to behave is a bug. As can be seen from the duplicates, 
Mozilla is clearly not behaving here as people expect it to behave. The current 
behavior can result, for example, in the sidebar opening when the user clicks the 
Back button. That is simply absurd. You can call this a `request to change the 
current behavior' rather than a bug if you like, but that doesn't make it any 
less serious.

This should also serve as an object lesson in how providing extra prefs doesn't 
make a UI problem go away -- it just makes it worse. Providing search results in 
the sidebar is useful sometimes, and if I want that, then I'll perform the search 
itself in the sidebar. But when my search has nothing to do with the chrome, the 
results should have nothing to do with the chrome either. The pref is useless in 
that neither setting could give me that desired behavior.

giving to german since he is our UI dude.
You make the call german.
Assignee: matt → german
Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this 
bug is nsbeta1-.
Keywords: nsbeta1-
*** Bug 65935 has been marked as a duplicate of this bug. ***
Cursory usability testing on NS6 betas with that behavior were inconclusive at
best. Some who like the sidebar search feature also liked being prompted to the
sidebar results by it auto-opening.
For a large number of users though this seemed intrusive similar to popups.
After having looked at this I'd rather err on the non-intrusive side and tend to
side with mpt in that auto-opening should not be the default behavior. This is
especially true since it is usually not the beginners that change their default
config ie by closing the sidebar, thus we should respect this as a deliberate
user decision. I would like to coordinate this with Ben also, forwarding to him
to have a look at this as this affects mostly browser.
Assignee: german → ben
I agree that we could default the pref the other way - I hope to see that done but I'm afraid
that might mask the two issues i see here.
1. What's happens when i have the pref set to show me results but I've turned the sidebar
off via the 'View' menu?
2. What happens when I do a search that originates from within a web page e.g. google.com?

Are we agreeing that if we default the pref off and someone goes and explicitly turns it on then
they should not be surprised or upset when their sidebar turns itself on and displays results in
these two situations?

Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
*** Bug 78223 has been marked as a duplicate of this bug. ***
Additional dups (marked as invalid):
bug 29904 search opens sidebar, overiding and confusing view-->sidebar setting 
      (bug 29904 has two dups: bug 31529 and bug 32439)
bug 54742 Sidebar reappears on searches
Keywords: mostfreq
It seems that all the pref does is keep the sidebar from opening.  On big
searches on bugzilla, even with the pref unchecked, the search results are still
processed in the sidebar tab freezing up the browser.

What I would expect is that if I choose not to use the sidebar, there should be
no extra processing involving the sidebar.

You are hurting Mozilla's performance by doing this processing by default. 
Sometimes I want to view the results in the sidebar and I'd want the thing to
open automatically...but when I choose to not view the sidebar, it should not
interfere in any way with anything else that I'm doing in Mozilla.

If you say "well, that was how it was designed"...the I'd have to reply "change
the design".  The sidebar should be able to be completely disabled in some way
shape or form.  That is what I thought unchecking the View/My Sidebar did, but,
apparently not.

please don't tell me this is invalid.  It seems to be what everyone is requesting.

jake
How many dubs we have of this bug 10?

But what do we hear

"It's not a bug, it's a feature"

When I download a browser I just want to use it not searching through the pref
trying to turn this thing off.

If you want a compromise put the pref inside the search panel.

There should be a little checkbox "Don't open on searches" under the results
From Slashdot, comments on 0.9.1:

" In Mozilla it has a feature when ever you do a search on google or bugzilla, 
the taskbar pops out showing all the titles from the results

  I find this feature really annoying and it took me forever to figure out how 
to turn it off.

  To turn it off, in preferences under Navigator choose Internet Search and 
uncheck the checkbox.

  Does anyone like this feature? I'm afraid some people might stop using Mozilla 
because this is so annoying and they can't figure out how to turn it off."

"No I hate that too."

- http://slashdot.org/comments.pl?sid=01/06/08/0134228&cid=152
I figured out how to get the sidebar to not process searches, on the Mac at least.

Go to the Component Folder and remove the file search.xpt

The search function in Mozilla will not work at all.

This will also stop the sidebar from opening during searches
You can prevent the sidebar from opening by visiting
Edit->Preferences->Navigator->Internet Search and deselecting the option for
opening the sidebar tab. 
Ben, please see my comments from 2001-05-03 13:06 

I agree, the sidebar pref prevents the opening of the sidebar upon obtaining 
search results from a search engine.  However, and this is the important part, 
it still processes all the search results behind the scenes freezing up the 
browser!

So, great!  We have a pref that prevents (what many consider) the annoying 
behavior of the sidebar opening upon searches.  But if the browser is freezing 
up anyway because it is doing all this processing behind the scenes, what is 
the point of the pref???

With the pref unchecked, the behavior should be to NOT open the sidebar 
automatically (already done) *AND* not waste cycles processing something I 
didn't care to see or have running in the first place.

Until the freezing issue is addressed, the pref does almost no good!

jake

The rogue code is at:
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js#116

This should not be done at all unless the pref is set, or the sidebar is open at
the appropriate panel, or when the panel is opened manually by the user. The
patch is probably fairly simple...
--> me
Assignee: ben → blake
Target Milestone: Future → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room
for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work.
 If anyone disagrees with the new target, please let me know.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Samir is handling these issues, -->samir
Assignee: blakeross → sgehani
Target Milestone: mozilla0.9.6 → ---
Target Milestone: --- → mozilla0.9.7
Moving to mozilla0.9.8.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Usability issues are being dealt with as part of:
<http://mozilla.org/xpapps/sidebar/proposals/usability.html>
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Why wontfix?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
You're right, this should really be 'invalid', resolving as such.  This is not a
defect, current default behavior is what the module owner and UI designer intend
it to be.  There is a way to get the behavior you want, and we plan to make that
more discoverable. We will also address any issues with the sidebar opening too
aggressively.  I'm surprised to hear you make such a distinction between chrome
and content, since I'm sure you're aware that our target users largely do not.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
thank the lawd. this 'flaw' is finally VERIFIED Invalid...11 months after I said
as much.
Status: RESOLVED → VERIFIED
btw, my comments were directed to MPT, in response to some of his comments in
this bug.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.