Google search pops up sidebar

RESOLVED FIXED

Status

SeaMonkey
Sidebar
RESOLVED FIXED
13 years ago
11 years ago

People

(Reporter: Greg Kemnitz, Assigned: Andrew Schultz)

Tracking

({fixed-seamonkey1.1a, relnote})

Trunk
x86
All
fixed-seamonkey1.1a, relnote
Bug Flags:
blocking-seamonkey1.0a -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

4.23 KB, patch
jag (Peter Annema)
: review+
neil@parkwaycc.co.uk
: superreview+
Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com]
: approval-seamonkey1.1a+
Details | Diff | Splinter Review
(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040714
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040714

The "sidebar" pops up if you do a search in Google in 1.8 alpha 2.



Reproducible: Always
Steps to Reproduce:
1.Go to Google
2.Do a search
3.

Actual Results:  
Sidebar will pop up.

Expected Results:  
No sidebar

Comment 1

13 years ago
Edit->Preferences->Internet Search:
Is "Open the Search tab in the Sidebar when search results are available" unchecked?
(Reporter)

Comment 2

13 years ago
Yes - it is.  After unchecking the check-box, it didn't do this anymore.
The only surprising thing was that it didn't do this before - is this
a new feature?  If so, the default should probably be unchecked, otherwise,
it "feels" like a bug since it is different from the old installation.

Comment 3

13 years ago
It is not checked on mine and still comes up.

Comment 4

13 years ago
Comment 3 is missing build ID. I'm not aware of any changes in defaults.
But this is the third report of the phenomena in a month. Before that there
wasn't one for two years..

Fix for bug 229753 is the only related checkin of late, but judging by comments
it seems to be newer than the build this is reported with.

Resolving as dup of todays other bug to see if there's a trend here. (The third
report was bug 248624. Have people been testing bug 229753..?)

*** This bug has been marked as a duplicate of 252756 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
(Assignee)

Comment 5

12 years ago
reopening... bug 252756 was about using Mozilla's built-in search functions,
which are supposed to open the sidebar.
Status: RESOLVED → UNCONFIRMED
Component: General → Sidebar
OS: Windows 2000 → All
Resolution: DUPLICATE → ---
(Assignee)

Comment 6

12 years ago
confirmed with linux trunk 2005050602
Assignee: general → sidebar
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
QA Contact: general

Comment 7

12 years ago
blocking, per Chris's request.
Assignee: sidebar → cst
Flags: blocking-seamonkey1.0a+
Created attachment 189253 [details] [diff] [review]
turn the pref off by default
Attachment #189253 - Flags: review?(neil.parkwaycc.co.uk)

Comment 9

12 years ago
Comment on attachment 189253 [details] [diff] [review]
turn the pref off by default

Chickening out...
Attachment #189253 - Flags: review?(neil.parkwaycc.co.uk) → review?(jag)

Comment 10

12 years ago
Not a regression, see bug 229753
Keywords: regression

Comment 11

12 years ago
What do you mean, not a regression? This worked fine in all 1.7 builds.
bug 229753 deals with doing a search through the location bar.
This bug deals with searching on the Google site itself.

Comment 12

12 years ago
(In reply to comment #11)
> What do you mean, not a regression? This worked fine in all 1.7 builds.
> bug 229753 deals with doing a search through the location bar.
> This bug deals with searching on the Google site itself.

wfm, Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b3) Gecko/20050714 SeaMonkey/1.0a

wfm. using the location bar for search, or using google.com.
If I try to use google.com, I get redirected to google.de,
but the search is ok, and sidebar stays closed.

Comment 13

12 years ago
Comment on attachment 189253 [details] [diff] [review]
turn the pref off by default

"code" change looks fine to me. I'll leave the final call on this to you, Neil
:-)
Attachment #189253 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #189253 - Flags: review?(jag)
Attachment #189253 - Flags: review+

Comment 14

12 years ago
I finally narrowed down the cause of my problem.
See, in my searchplugins folder, I have the plug-in for GoogleBE_nl.

While I have this plug-in, and "Open Sidebar..." checked:
-Searching on Google.be pops up the sidebar, as well as showing the results on
the site.
-Searching via the location bar pops up the sidebar, as well as showing the
results on the site.

When I don't have this plug-in:
-Searching on Google.be shows the results on the site.
-Searching via the location bar pops up the sidebar.

I think the real issue here is the search plug-ins, and how they are handled.
The reporter probably uses Google.com, and its search plug-in.

Comment 15

12 years ago
Correction: searching via the location bar (with the Google.com plug-in) without
my search plug-in pops up the sidebar AND shows the results on the Google.com site.

Comment 16

12 years ago
(In reply to comment #12)
>If I try to use google.com, I get redirected to google.de,
>but the search is ok, and sidebar stays closed.
Ah, but if you install the google.de plugin then it will trigger the auto-open.

Updated

12 years ago
Attachment #189253 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview-
Will relnote for 1.0a, but not block.
Flags: blocking-seamonkey1.0a+ → blocking-seamonkey1.0a-
Keywords: relnote
Whiteboard: [need 1.0a relnote]
http://lxr.mozilla.org/seamonkey/source/xpfe/components/search/src/nsInternetSearchService.cpp#2812
Could this search be modified to search for the
"&client=mozilla&rls=org.mozilla:en-US:unofficial" that we add to the URL when
you do a search from the URL bar instead of Google's page?
Whiteboard: [need 1.0a relnote]
Based on some discussion on IRC, this may be by design.

Comment 20

12 years ago
If so, it would be very bad design, in my opinion.
Come on, you search on Google.com, and you get TWO instances of results?

Not to mention that the Search mentioned wouldn't be a search on a website.
Can we please just flip the pref off?  I always have to show my friends how to
disable sidebar... I'd imagine they represent more people than the few
developers who like it.  Those developers know where the pref is.

Comment 22

12 years ago
I personally think it should be fixed instead of being thrown in the 'forget
bin'. I'm not a Mozilla developer, but I think it shouldn't be too hard to fix.
I think it would be fixed by removing the link between the sidebar search and
the searching done on the site.
(In reply to comment #22)
> I personally think it should be fixed instead of being thrown in the 'forget
> bin'. I'm not a Mozilla developer, but I think it shouldn't be too hard to fix.
> I think it would be fixed by removing the link between the sidebar search and
> the searching done on the site.

Lots of things seem like they should be easy until you actually see the code.

Comment 24

12 years ago
I've been trying to track down the regression window, without luck.

The earliest trunk build available for Windows, 20041005, shows this behavior, as well as 1.7 Final, and 1.6 Final.
With browser.search.opensidebarsearchpanel set to true, any search engine, that is added to the SeaMonkey search list via window.sidebar.addSearchEngine() shows this behaviour. Eg. open dmoz.org with google.com as default search, make a search and the sidebar will still popup.

Comment 26

11 years ago
Yeah, that's known. At least by me. When a page is loaded, the search component is loaded, and it checks all the installed search engines for a math with the URL. Every time.
(Assignee)

Comment 27

11 years ago
==> me

I have a patch that explicitly opens the search panel if URL bar search is invoked from the autocomplete popup.  But the text in the pref panel is no longer appropriate --"Open the Search tab in the Sidebar when search results are available"

"...when a search is invoked" ?
Assignee: cst → ajschult
(Assignee)

Comment 28

11 years ago
Created attachment 210443 [details] [diff] [review]
patch

We'll still switch to the search tab within the sidebar if you manually search google (if the pref is set), but only if the sidebar is already open.
Attachment #189253 - Attachment is obsolete: true
Attachment #210443 - Flags: superreview?(neil)
Attachment #210443 - Flags: review?(jag)

Comment 29

11 years ago
Comment on attachment 210443 [details] [diff] [review]
patch

You seem to have forgotton the search button.
Attachment #210443 - Flags: superreview?(neil) → superreview-
(Assignee)

Comment 30

11 years ago
Comment on attachment 210443 [details] [diff] [review]
patch

> You seem to have forgotton the search button.

http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.xul#226

Search button goes the OpenSearch which still opens the search sidebar if the pref is set.

http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js#1098
Attachment #210443 - Flags: superreview- → superreview?(neil)
(Assignee)

Comment 31

11 years ago
Created attachment 210740 [details] [diff] [review]
simplify UpdateInternetSearchResults more

Neil pointed out that checking the pref in UpdateInternetSearchResults was pointless
Attachment #210443 - Attachment is obsolete: true
Attachment #210740 - Flags: superreview?(neil)
Attachment #210740 - Flags: review?(jag)
Attachment #210443 - Flags: superreview?(neil)
Attachment #210443 - Flags: review?(jag)

Updated

11 years ago
Attachment #210740 - Flags: review?(jag) → review+

Updated

11 years ago
Attachment #210740 - Flags: superreview?(neil) → superreview+
(Assignee)

Comment 32

11 years ago
fixed
Status: NEW → RESOLVED
Last Resolved: 13 years ago11 years ago
Resolution: --- → FIXED
Attachment #210740 - Flags: approval-seamonkey1.1a+
(Assignee)

Updated

11 years ago
Keywords: fixed-seamonkey1.1a

Comment 33

11 years ago
I think that this option should be unchecked by default

Thanks

Comment 34

11 years ago
Sorry, but the module owner can't be convinced of that.
Besides, with this patch, it doesn't really matter anymore.
You need to log in before you can comment on or make changes to this bug.