Axel (l10n) noted in bug 318586 comment 1 that region.properties has not been updated with the new mozilla.com stuff (specifically the live bookmarks page). Besides changing to mozilla.com, some of the other URLs could be changed to go directly to their current pages instead of going through a redirect. This is for both the trunk and the 1.8 branch. Here's a list of updated options that use the new URLs: --- homePageDefault=http://start.mozilla.com/firefox ^^^ or should this be http://en-US.start.mozilla.com/firefox ? releaseNotesURL=http://www.mozilla.com/firefox/releases/%S.html browser.startup.homepage=http://start.mozilla.com/firefox ^^^ or should this be http://en-US.start.mozilla.com/firefox ? browser.throbber.url=http://www.mozilla.com/firefox/central startup.homepage_override_url=http://www.mozilla.org/products/firefox/releases/whatsnew/ ^^^ this currently instantly redirects to http://en-US.start.mozilla.com/firefox searchEnginesURL=https://addons.mozilla.org/search-engines.php feedLiveBookmarkInfoURL=http://www.mozilla.com/firefox/livebookmarks ^^^ the actual page is livebookmarks.html but it seems livebookmarks (no ext) is what the header menu uses app.update.url.details=http://www.mozilla.com/firefox/releases/ --- If this is correct, I'll make a patch for these changes and attach it to the bug. Locales that use mozilla.org URLs will need to be updated, too.

Fixing region.properties is a bigger task, we'll probably chat about that next week. Fixing will likely be different on the branch and on the trunk. Note that "has not been updated" does not reflect the timeline, those URLs have changed after release.

(In reply to comment #1) > Fixing will likely be different on the branch and on the trunk. What exactly would need to be different? Doesn't the trunk usually branch off into the newer branches later on, meaning that normal users will get that region.properties eventually. > Note that "has not been updated" does not reflect the timeline, those URLs > have changed after release. Yeah, I just meant that it needs to be updated for later 1.8 releases and on the trunk. timeless pointed out http://cvs-www.mozilla.org/webtools/bonsai/cvsblame.cgi?file=mozilla-org/html/products/firefox/.htaccess&rev=1.6&cvsroot=/cvsroot as the current "redirects" for some of the m.o->m.c stuff. CC'ing some people that might know more about what exactly should be updated/changed.

*** Bug 319842 has been marked as a duplicate of this bug. ***

From looking into bug 319842, I noticed that "http://www.mozilla.org" is hardcoded in toolkit/content/about.xhtml#78. If that is to change from .org to .com, it can probably be handled here as well.

No activity since December, need to see some patches landed in trunk/1.8 first before we'd consider for a security-update release.

(In reply to comment #5) > No activity since December, need to see some patches landed in trunk/1.8 first > before we'd consider for a security-update release. Axel: What's the current word on how you want to proceed with this and the other issues that relate to l10n?

I'm getting closer to have something, I already have js code that generates the central URL. That can be easily morphed to perl code to be used by the build. But that's still just one URL of many. I don't see any pressing reason why we need to fix those URLs on the 1.8.0 branch myself.

Assigning to Pike, since he's working on the URL consolidation stuff. Should be sorted by Fx2 l10n cutoff, since it doesn't make any sense to let it linger beyond that.

Let's remove some unnecessary stuff first. Content packs are so yesterday, Firefox didn't have them for ages, so let's remove contentlocale. (Seamonkey is going to go there, too.) homePageDefault is just a fallback if the pref for browser.startup.homepage ain't found. Why not pull that entity from l10n, if you want to pull that directly? Thus, kill homePageDefault, shouldn't be triggered anyway. I adjusted browser.js to not fall back there, and renamed the bundle var name to be non-suite. I moved releasenotes, homepage, and homepage_override_url over to mozilla.com. I tested this with a trunk build and removed Firefox dir, so that the profile would be generated from scratch.

After more investigation and chatting, there's more to die: browser.startup.homepage lives in resource:/browserconfig.properties, let's fall back to there in browser.js. fallbackDefaultSearchURL references were removed by Gavin, let's get rid of the property, too. feedLiveBookmarkInfoURL landed for feedview, but was never used. update_notifications.provider.0.datasource is SeaMonkey only. I reorganized the file to have the search related items together, and moved the searchplugins page over to the redirect target, which is on amo now.

Comment on attachment 226132 [details] [diff] [review] remove more stuff, fall back to browserconfig.properties for browser.startup.homepage morgamic: >+searchEnginesURL=https://addons.mozilla.org/search-engines.php Should this be https://addons.mozilla.org/search-engines.php or https://addons.mozilla.org/firefox/search-engines/ ? Axel: You need to request a specific person for the approval-branch-1.8.1 flag. I've gone ahead and requested it from mconnor.

(In reply to comment #11) > (From update of attachment 226132 [details] [diff] [review] [edit]) > morgamic: > > >+searchEnginesURL=https://addons.mozilla.org/search-engines.php > > Should this be https://addons.mozilla.org/search-engines.php or > https://addons.mozilla.org/firefox/search-engines/ ? I don't really mind, I just took what .htaccess redirects to. http://bonsai-www.mozilla.org/cvsblame.cgi?file=mozilla-org/html/products/firefox/.htaccess&rev=&root=/cvsroot&mark=4 Thanks for adjust the approval-flag.

(In reply to comment #11) > (From update of attachment 226132 [details] [diff] [review] [edit]) > morgamic: > > >+searchEnginesURL=https://addons.mozilla.org/search-engines.php > > Should this be https://addons.mozilla.org/search-engines.php or > https://addons.mozilla.org/firefox/search-engines/ ? I'd go with https://addons.mozilla.org/search-engines.php -- the rewrite might not contain the app in the future (see bug 337198).

Comment on attachment 226132 [details] [diff] [review] remove more stuff, fall back to browserconfig.properties for browser.startup.homepage Baked on the trunk since Friday, and enough, I think, requesting branch approval.

Fixed on the trunk since Friday, needs branch landing.

Landed on the branch, too.