343890 - The "you're updated" page in Firefox CJK build has hard-coded link to Google

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[juan becerra [:juanb]]

The TW and CN CJK builds show a start page that has a hard-coded link to Google. There should not be any references to Google. It happens on first launch after installation.

To recreate:
1. Install a zh-TW or zh-CN version of the CJK Firefox builds with a clean profile.
2. Launch the browser for the first time.

Expected: Either a Yahoo search page or a "updated" page with a link that takes you to the Firefox start page with Yahoo search page.

Actual: You get a page whose URL is http://www.mozilla.com/firefox/updated which has a link "Go to Firefox Start Page" that takes you to a Google search page.

about:config | startup.homepage_override_url has a value of www.mozilla.com/firefox/releases/whatsnew/ which then redirects the user to http://www.mozilla.com/firefox/updated

Perhaps we can have the latter page detect the build type and change the link to a Yahoo start page instead of a Google one accordingly.

Comment 1

[Basil Hashem [:baz]]

In order to mitigate the amount of changes that are needed, I suggest we simply "eliminate" the first run page for these special releases. Simply set the startup.homepage_override_url property to the same value as the home page for the given locale.

This needs verification from CBeard & Lilly to ensure we are OK, per contract.

Comment 2

[Jay Patel [:jay]]

I don't know if removing the "you're updated" page will be a smart move, but if there is no other way around this problem, I guess we can live with it.

I like Juan's idea of detecting which build it is and dynamically generating the link to point to whichever startpage we need users to end up at.  It should be easy to do with some JS magic, but not sure if there is an easy way to differentiate between a standard Mozilla build, Yahoo! build, and Google build (do each of them have a unique user-agent string?).

Juan:  Can you check on the user-agent?

Unless this can be fixed on the server-side, I don't think we will be able to get this in for 1.5.0.5 unless someone gets a patch submitted and reviewed ASAP and Rob get's it landed before packaging the CJK builds.

Comment 3

[juan becerra [:juanb]]

The user-agent string may not be unique. The strings that could identify a CJK build are the locale initials and the build date. This only works if the builds are done on different days for a specific locale. If we build a regular Google zh-CN and a Yahoo CJK zh-CN on the same day, the user-agent string will look the same.

We could also remove that link from the "you're updated" page...

Comment 4

[Jay Patel [:jay]]

cbeard really needs to chime in here so we can figure out what we want to do and get the CJK builds packaged and ready for testing.

Chris:  Do we want to remove the link entirely?  It doesn't look like there is an easy fix for this with JS, since the user agent is identical (including the locale name and build id).

If anyone has other ideas, let us know.

Comment 5

[Robert Helmer [:rhelmer]]

Attachment: use window.home() instead of google link

One suggestion that came up in the 1.5.0.5 meeting today was to link to the user's home page, rather than explicitly link to google, by using the JS function window.home()

Here is a patch to cvs-www/mozilla-com that does this.

Comment 6

[Jay Patel [:jay]]

blocking, so we verify this change for the release.

Comment 7

[Jay Patel [:jay]]

Comment on attachment 229309 [details] [diff] [review]
use window.home() instead of google link

approved for 1.8.0.5, please get this checked in to the website CVS. a=jay for drivers.

Comment 8

[Robert Helmer [:rhelmer]]

Checking in src/firefox/updated.html;
/cvsroot/mozilla-com/src/firefox/updated.html,v  <--  updated.html
new revision: 1.10; previous revision: 1.9
done

Comment 9

[Daniel Veditz [:dveditz]]

1) This missed the suggestion to put the old link in a <noscript></noscript> -- this now doesn't work if JS is disabled.

2) I don't see this change if I go to the actual updated page. The URL I go to is  http://www.mozilla.com/firefox/updated which I don't see on the site, and don't see what would load the modified updated.html from that.

"Last Modified" on the page I get is "Monday, July 17, 2006 9:15:34 AM" -- before Rob's check-in. It Expires tomorrow, so maybe there's server-side caching getting in the way? 

Comment 10

[Daniel Veditz [:dveditz]]

> which I don't see on the site

which I don't see in *CVS* for the site.

Comment 11

[Robert Helmer [:rhelmer]]

(In reply to comment #9)
> 1) This missed the suggestion to put the old link in a <noscript></noscript> --
> this now doesn't work if JS is disabled.
> 
> 2) I don't see this change if I go to the actual updated page. The URL I go to
> is  http://www.mozilla.com/firefox/updated which I don't see on the site, and
> don't see what would load the modified updated.html from that.
> 
> "Last Modified" on the page I get is "Monday, July 17, 2006 9:15:34 AM" --
> before Rob's check-in. It Expires tomorrow, so maybe there's server-side
> caching getting in the way? 
> 

Hi Dan,

I just found out that the process has changed a bit; need to file a bug to get content pushed from stage->prod now.

So, we can still get this in.. what should the non-JS link be?

Comment 12

[Daniel Veditz [:dveditz]]

Attachment: what I was talking about

Here's what I was talking about -->
  1) use script to create the script-requiring link
  2) put the old link in a <noscript>

An alternate would be to eliminate the <noscript> block and just document.write() the javascript link. If script's turned off there's no link or image at all, which is better than a non-working one.

Comment 13

[Basil Hashem [:baz]]

I'm OK with the fact that users with JS disabled would have a different experience. I think it's an OK trade-off. Assuming here that we implement Dan's suggested solution and attachment.

Comment 14

[Robert Helmer [:rhelmer]]

Attachment: no link if JS disabled

Here is a version that has no link if JS is disabled; I assume that users with JS disabled won't feel "stuck" if there is no link. However if we want to take Dan's version (which falls back to google) I am fine with that too.

Comment 15

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Comment on attachment 230476 [details] [diff] [review]
no link if JS disabled

approval1.8.0.5 doesn't make much sense for the webtree. :-)

You might want to add type="text/javascript" to the script element and a "\" before the "/a" so that the page validates.

Comment 16

[Robert Helmer [:rhelmer]]

Attachment: address dbaron's comments

Thanks for the review dbaron! How is this?

Comment 17

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Looks great to me, especially if you've tested it with script enabled and disabled.

Comment 18

[juan becerra [:juanb]]

This has been working with scripting disabled or enabled, in the first case clicking on the image/link does nothing, and in the latter case it takes you to the user's home page, in this case the yahoo search page which is what we want for yahoo cjk builds.

Tested by clean installing:

Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5

Comment 19

[Robert Helmer [:rhelmer]]

Landed:

Checking in updated.html;
/cvsroot/mozilla-com/src/firefox/updated.html,v  <--  updated.html
new revision: 1.11; previous revision: 1.10
done

Juan can you retest when this goes up on www-stage? The link/image should not appear w/ scripting disabled.

Comment 20

[juan becerra [:juanb]]

Page in question now shows link that takes you to the user's home page if Javascript is enabled, or doesn't show the link at all if Javascript is disabled.

Comment 21

[Daniel Veditz [:dveditz]]

Looks fixed to me.