Closed Bug 56969 Opened 25 years ago Closed 24 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: 24 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: 24 years ago → 24 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.