Search on help.ubuntu.com does not work on FF v23.

[Pablo Piaggio]

Content is block because the search's results are not secure:

https://support.mozilla.org/en-US/kb/how-does-content-isnt-secure-affect-my-safety?as=u&utm_source=inproduct

Disabling the protection shows results, but it does not work for a subsequent search. In other words, each search has to be disable in order to display results.

At least one other person confirms that the problem is presented on FF v23.

Also 2 people confirm that the problem does not present itself on Chromium (28.0.1500.71).

Additional info:

$ lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.2 LTS
Release: 12.04
Codename: precise

$ uname -a

Linux vaughan 3.2.0-51-generic #77-Ubuntu SMP Wed Jul 24 20:18:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ apt-cache policy firefox

firefox:
  Installed: 23.0+build2-0ubuntu0.12.04.1
  Candidate: 23.0+build2-0ubuntu0.12.04.1
  Version table:
 *** 23.0+build2-0ubuntu0.12.04.1 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages
        100 /var/lib/dpkg/status
     11.0+build1-0ubuntu4 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Doug Smythies (dsmythies)]

I did make some changes on help.ubuntu.com just over a day ago, and perhaps I introduced some issue . Although, nothing changed that should have effected the search function. I recall there have been issues with search in the past.

Can anyone confirm or deny if search was working with FF v23 a a few days ago?

[Elfy (elfy)]

I'd assume that it's something to do with ff v23 to be honest, as I have had issues with other ubuntu areas prior to me forcing ff to open pages with insecure content

[Doug Smythies (dsmythies)]

There have been a number of issues with mixed content (https and http) since the switch to the new theme (the one with the red background stuff, whereas the "old" theme was brown background stuff).

If I use MS IE, I also get the mixed content warning, but can proceed if I allow it. Using FFv23, but from a windows computer, I actually get nothing for search results.

Evidently, the root issue is within the file "https://www.google.com/afsonline/show_afs_search.js" which is called from sample.html when the "search" button is pressed. A possible solution is to copy the file, change the one occurrence of "http" within the file to "https", and call the local copy instead. The obvious potential problem, is what if google makes some change to the file?

Typically, I test help.ubuntu.com changes on one of my test computers before submitting changes. The test system is not currently setup for HTTPS, and so I don't have an easy way to test this possible solution. Also the help.ubuntu.com address is absolute and not relative on each and every html page within help when using the search function (i.e even on my test computer, it ends up at help.ununtu.com anyhow).

Another option might be to switch to Google Custom Search Element v2. According to their intro page, it should not suffer from the mixed content issue if ones calls the https version instead of the http version.

References:
http://stackoverflow.com/questions/3838716/how-to-use-google-custom-search-on-https-to-avoid-non-secure-content-prompt
https://developers.google.com/custom-search/docs/js/cselement-devguide

[Doug Smythies (dsmythies)]

Correction: Where I wrote "sample.html" above, I meant to write "search.html"

Please try it now and comment back here.

While my branch update to launchpad was automatically picked up and copied to help.ubuntu.com about 10 hours ago, there seems to have been some cached version of search.html somewhere upstream (driving me crazy trying to figure it out for hours). Anyway, and for me at least, it seems to have finally flushed.

One way to determine if you are getting the new search.html or still the old one is to check the last sentence of the footer, which was also changed:

This means the new search.html was used (and is expected to not give any mixed content warning):

"To report errors in this documentation, file a bug."

This means that somehow the old search.html was used (and it is expected to give mixed contents warnings, or just not work on some browsers):

"To report a problem, visit the bug page for Ubuntu Documentation"

[Doug Smythies (dsmythies)]

see also bug 1044714

[Pablo Piaggio (papibe)]

This seems to be working for me.

Obs: now the FF lock info it says: Verified by GoDaddy.com, Inc.

[Doug Smythies (dsmythies)]

Even though this bug has a "fix released", I am leaving the status as "in progress" for now and so it will stay on my "to do" list. I used the copy the file method mentioned in post # 4 above, and would like to find a better way.

[Doug Smythies (dsmythies)]

The file show_afs_search.js has changed significantly sometime during the last cycle.

I have tested the new one on my test server, and it will updated tonight, for publication tomorrow as part of the help.ubuntu.com release day edits.

[Doug Smythies (dsmythies)]

I have updated show_afs_search.js again.

[Doug Smythies (dsmythies)]

I have updated show_afs_search.js again.

[Doug Smythies (dsmythies)]

show_afs_search.js from https://www.google.com/afsonline/show_afs_search.js (see post #4) is now 16988 bytes whereas the current one for help.ubuntu.com from November, 2021 is 3453 bytes. I won't update it until forced to via complaints of something not working.

[Gunnar Hjalmarsson (gunnarhj)]

Wondering if an update would help for the issue described at bug #2017525.

[Doug Smythies (dsmythies)]

Hi Gunnar,

I tried it on my test site (I'll send you the link in a separate email), and it made no difference for this issue.

[Gunnar Hjalmarsson (gunnarhj)]

For me it fixed the issue. (Using the FF snap in Ubuntu 22.04.)

Why don't we see the same thing?

[Doug Smythies (dsmythies)]

I made a mistake and did not force re-load cached content on my test web site. I'll update show_afs_search.js from https://www.google.com/afsonline/show_afs_search.js (see post #4) to the now much larger file.

I'll also set bug #2017525 to be a duplicate of this one.

[Doug Smythies (dsmythies)]

The file "https://www.google.com/afsonline/show_afs_search.js" no longer contains any occurrences of "HTTP", it only has "HTTPS" so there is no longer any need to have a local edited copy. By switching back to the original method of a link to the master source, we could finally close this bug report and forget about it.

Tested on multiple browsers.

Thanks to Gunnar for the suggestion.