567518 - Consider supporting or switching to SSL Google search (https)

Status: RESOLVED FIXED

(SeaMonkey :: Search, enhancement)

Description

[Jens Hatlak (:InvisibleSmiley)]

We're currently using Google as the default search engine--over an unencrypted line. Google recently started to support https for searches. This bug is about considering to switch our default search engine to the secure variant.

Currently (May 2010) I think it's too early, though:
"At this time, search over SSL is supported only on Google web search. We will continue to work to support other products like Images and Maps. All features that are not supported have been removed from the left panel and the row of links at the top."

Comment 1

[Justin Wood (:Callek)]

WONTFIX for SeaMonkey 2.1 given the quote in c#0.

I'm tempted to reso/wontfix this until such time as we would consider this a viable option though.

Comment 2

[Jason Orendorff [:jorendorff]]

This has changed on Google's end; now the HTTPS version of a search result page is the same as the HTTP one.

Comment 3

[Jason Orendorff [:jorendorff]]

Seems like the action is in bug 633773.

Comment 4

[Jens Hatlak (:InvisibleSmiley)]

I'm not sure duping a SM bug to a FF bug is a good idea (maybe if it was a Core bug...). I guess I'll leave it this way until the other bug gets resolved, and then reopen this one because I'm 99% sure the other bug won't include/handle the SM part.

Comment 5

[Philip Chee]

I'm reopening this and setting a dependency since the code needs to be ported to SeaMonkey. We also need a resolution on the client=firefox vs seamonkey issue.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

There's no code to be ported, we're just changing URLs in prefs and the OpenSearch plugin.

Comment 7

[Robert Kaiser]

(In reply to Gavin Sharp (use [e-mail] for email) from comment #6)
> There's no code to be ported, we're just changing URLs in prefs and the
> OpenSearch plugin.

If it's code or some other lines of anything is really just splitting hairs. The fact is that *something* needs to be ported - and yes, for reasons that people who thought that the suite would have died years ago probably will never understand, the SeaMonkey teams cares and wants to do work like this.

Comment 8

[Philip Chee]

> There's no code to be ported, we're just changing URLs in prefs and the OpenSearch
> plugin.
Gavin. The code is forked so there needs to be a separate patch for SeaMonkey and Thunderbird. Are you volunteering to write us a comm-central patch?

Comment 9

[:Gavin Sharp [email: [e-mail]]]

I'm sorry, I'm not sure why what I said that was so offensive! I'm well aware that you'll need separate SeaMonkey changes, and wasn't arguing against this bug being reopened, if that's the misunderstanding. "code needs to be ported" implied a code change, and I was just trying to clarify that there aren't any code changes that need to be ported for that bug (but there are indeed equivalent configuration changes).

Comment 10

[Philip Chee]

Gavin. Thanks for the clarification. To me the opensearch xml *is* code.

Comment 11

[Jens Hatlak (:InvisibleSmiley)]

(In reply to Gavin Sharp (use [e-mail] for email) from comment #9)
> I'm sorry, I'm not sure why what I said that was so offensive!

Rest assured, it wasn't. Sometimes people get each other wrong, esp. if they are not talking face to face. Let's calm down everyone and try to assume that we all have good intentions rather than assuming the worst. It really is a question of what you expect your counterpart to mean rather than what s/he actually writes. I saw this issue arise with bug 724344 and continue here. Please let us believe in good faith, relax, and then get back to work. OK? :-)

Comment 12

[Jens Hatlak (:InvisibleSmiley)]

So, bug 633773 (attachment 605197 [details] [diff] [review]) landed in time for FF 14 which is currently on the Aurora channel. The change involved three parts (as far as we are concerned):

1. region.properties: browser.search.siteSearchURL (l10n)
2. google.xml: <Url template> (l10n)
3. all.js: keyword.URL (no l10n, no change needed on our side)

So we have two options:
a) only port the changes to current trunk
b) also backport the changes to Aurora, "breaking" l10n (needs NG post)

KaiRo, Callek, what's your opinion?

Comment 13

[Justin Wood (:Callek)]

(In reply to Jens Hatlak (:InvisibleSmiley) from comment #12)
 
> KaiRo, Callek, what's your opinion?

If it is possible to port to aurora *without* breaking l10n and affecting only en-US, I'd accept that. And we can do a l10n NG post giving localisers the chance/option to switch now for aurora, (or later for SM2.12)

Basically I think it is worth it - now on trunk one way or another, and if we can do it without too much headache [or any actual breakage] on aurora lets do so.

Comment 14

[Robert Kaiser]

I don't think it's worth breaking the L10n freeze, but we should do this where we can without breaking that.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

In Firefox, the google.xml change doesn't "break l10n" because searchplugins are not independent across locales (and most locales use the en-US google plugin). Is that not the case for SeaMonkey?

The siteSearchURL change isn't relevant to SeaMonkey (and actually isn't even really relevant to Firefox, it's just an unused string).

Comment 16

[Robert Kaiser]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #15)
> In Firefox, the google.xml change doesn't "break l10n" because searchplugins
> are not independent across locales (and most locales use the en-US google
> plugin). Is that not the case for SeaMonkey?

I'd hope that most are using the en-US one but I haven't looked at details. I agree that the search plugin can be regarded as not breaking the freeze.

I haven't looked at any actual patch as there's none here and I rarely have time to look into SeaMonkey issues, I just stated my general opinion.

Comment 17

[Jens Hatlak (:InvisibleSmiley)]

Attachment: patch [Checkin: Comment 20]

The attached is the conservative approach, simply does s/http:/https:/ (for the Google-related strings only of course).

Comparing to the equivalent files of TB and FF I see:
* TB currently has the same as we do, minus the "client=firefox" parameter
* FF uses a different URL for suggestions (one which might have less redirects)

Gavin, are we allowed to switch to the same URL FF uses for suggestions?

Comment 18

[Justin Wood (:Callek)]

(In reply to Jens Hatlak (:InvisibleSmiley) from comment #17)
> Created attachment 619874 [details] [diff] [review]
> patch
> 
> The attached is the conservative approach, simply does s/http:/https:/ (for
> the Google-related strings only of course).
> 
> Comparing to the equivalent files of TB and FF I see:
> * TB currently has the same as we do, minus the "client=firefox" parameter
> * FF uses a different URL for suggestions (one which might have less
> redirects)
> 
> Gavin, are we allowed to switch to the same URL FF uses for suggestions?

I vaguely remember hearing that the specific URL Firefox has is part of the contract they have with Google, and only for Firefox, CCing Kev hoping he has time to answer this, since I suspect he will know this more readily than gavin.

Comment 19

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 619874 [details] [diff] [review]
patch [Checkin: Comment 20]

You shouldn't use the exact same URL as Firefox. As to what you're "allowed" to do, you'd have to ask Google. If I were you I'd just use the normal Google search URL, minus all the Mozilla-specific parameters (i.e. omit "rls" and "client" parameters - "output" in the suggest URL is also unnecessary now AFAIK).

Comment 20

[Jens Hatlak (:InvisibleSmiley)]

Comment on attachment 619874 [details] [diff] [review]
patch [Checkin: Comment 20]

http://hg.mozilla.org/comm-central/rev/fe14bab9ba9b