Closed Bug 514467 Opened 10 years ago Closed 10 years ago

fix FAQ/Privacy/Credits links in about:firefox

Categories

(Firefox for Android Graveyard :: General, defect)

defect
Not set

Tracking

(fennec1.0+)

VERIFIED FIXED
fennec1.0b5
Tracking Status
fennec 1.0+ ---

People

(Reporter: Gavin, Assigned: Gavin)

References

Details

Attachments

(1 file)

The links that landed in bug 512843 don't all work:

-FAQ
-Privacy Policy (hardcoded link to http://www.mozilla.com/legal/privacy/ ?)
-Fennec Credits (bug 510931)
tracking-fennec: --- → ?
Assignee: nobody → gavin.sharp
tracking-fennec: ? → 1.0+
From the dependent bugs, looks like we'll want:

FAQ: http://www.mozilla.com/mobile/faq/
Privacy Policy: http://www.mozilla.com/legal/privacy/
Credits:  http://www.mozilla.com/mobile/credits/

Axel: is depending on web-l10n detection acceptable, or do we need to use URL formatting to explicitly link to the mozilla.com/ab-CD/ versions?
We have an mobile-specific privacy policy.
I'd rather have explicit urls.
I as well. I can't confirm yet, but most likely: http://www.mozilla.com/legal/privacy/mobile.html
(In reply to comment #2)
> We have an mobile-specific privacy policy.

Right, I guess there's no reason not to link directly to it.

So that means:

FAQ: http://www.mozilla.com/%LOCALE%/mobile/faq/
Privacy Policy: http://www.mozilla.com/%LOCALE%/legal/privacy/firefox/mobile/
Credits:  http://www.mozilla.com/%LOCALE%/mobile/credits/
I'm basing that on where steven checked it in in bug 516690. If things change such that it becomes legal/privacy/mobile.html, I can change it around pretty easily.
There's also a 404 page not found for the release notes link. Since there's no bug associated with it, maybe we should add this to the list here.
The patch I'm about to post results in the following URLs when run in a current Fennec nightly on Mac:

releaseNotesURL: http://www.mozilla.com/en-US/mobile/1.0b4pre/releasenotes/
supportURL: http://support.mozilla.com/1/mobile/1.0b4pre/Darwin/en-US/
faqURL: http://www.mozilla.com/en-US/mobile/faq/
privacyURL: http://www.mozilla.com/en-US/legal/privacy/firefox/mobile/
creditsURL: http://www.mozilla.com/en-US/mobile/credits/

The version number and platform ("Darwin") would obviously be different when we ship.

Laura says that they can set up support.mozilla.com redirects to point to the right mobile.support.mozilla.com page, so I can file a bug on that.

Steven/Caitlin, do the mozilla.com links look right? When can we expect that content to be live?
Comment on attachment 402135 [details] [diff] [review]
patch

Let's take this for now, can always adjust later as needed.
Attachment #402135 - Flags: review?(mark.finkle)
(In reply to comment #11)
> (In reply to comment #8)
> > creditsURL: http://www.mozilla.com/en-US/mobile/credits/
> 
> I changed this one to remove the trailing slash locally, since
> https://www-trunk.stage.mozilla.com/en-US/mobile/credits works, but
> https://www-trunk.stage.mozilla.com/en-US/mobile/credits/ doesn't.

That's because it's credits.html. Might be wise to move it to its own directory? Thoughts?
Attachment #402135 - Flags: review?(mark.finkle) → review+
The "FAQ", "Privacy Policy", "Release Notes" and "Credits" URLs are also 404 in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mobile-1.9.2/fennec-1.0b5pre.en-US.win32.zip (dated 12-Oct-2009).


The "Know you Rights" URL gives this error:

XML Parsing Error: undefined entity
Location: jar:file:///C:/Program%20Files/fennec/xulrunner/chrome/toolkit.jar!/c
Line Number 16, Column 10:
  <title>&rights.pagetitle;</title>
---------^


The "Support" URL works OK.

Rob
(In reply to comment #14)
> The "Know you Rights" URL gives this error:
> 
> XML Parsing Error: undefined entity

That's bug 515109.
Depends on: 520029
Links in the in product page (About page) are pointing to 404s. Can we point those to the live pages? Last I heard, "about:rights" for desktop Firefox would be the same for Fennec. I'll confirm with Doug and Catherine.
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #8)
> > > creditsURL: http://www.mozilla.com/en-US/mobile/credits/
> > 
> > I changed this one to remove the trailing slash locally, since
> > https://www-trunk.stage.mozilla.com/en-US/mobile/credits works, but
> > https://www-trunk.stage.mozilla.com/en-US/mobile/credits/ doesn't.
> That's because it's credits.html. Might be wise to move it to its own
> directory? Thoughts?

Reference: http://httpd.apache.org/docs/1.3/mod/mod_dir.html#directoryindex 

The URL: "https://www-trunk.stage.mozilla.com/en-US/mobile/credits" (NO  trailing backslash) means (depending on the server (and sometimes the browser)) to look for a file called "????/en-US/mobile/credits" and then the other files.

The URL: "https://www-trunk.stage.mozilla.com/en-US/mobile/credits/" (WITH trailing backslash) means (depending on the server (and sometimes the browser)) to look for a file called "????/en-US/mobile/credits/index.html" and then the other files.

Thus it is slightly quicker (avoids an "internal redirect") to add the trailing backslash, and for the server to send, (the browser to expect), a file that is called "????/????/index.html" - (unless on an 8+3 filesystem).

It is also slightly quicker to call the file's URL "credits.html" (and name the file appropriately) so that ".html" does not have to be appended to "????/credits" and so that a directory called "credits" is not going to get searched for a file called "index.html".

Don't make the Browser guess or the Server retry.

Rob
No longer depends on: 520029
mozilla.com pages have been pushed live, so all of the about:firefox and default bookmark links now work, woohoo!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → B5
verified FIXED on builds:

Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2b3pre) Gecko/20091110 Firefox/3.6b2pre Fennec/1.0b5

and

Mozilla/5.0 (X11; U; Linux armv6l; Nokia N8xx; en-US; rv:1.9.3a1pre) Gecko/20091110 Firefox/3.7a1pre Fennec/1.0b5
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.