19.14 KB, image/png
47.36 KB, patch
Benjamin Smedberg: review+
|Details | Diff | Splinter Review|
3.31 KB, patch
Josh Aas: review+
|Details | Diff | Splinter Review|
1.38 KB, patch
Benjamin Smedberg: review+
|Details | Diff | Splinter Review|
1.42 KB, patch
|Details | Diff | Splinter Review|
1006 bytes, patch
|Details | Diff | Splinter Review|
We need to rebrand this release. Replace Firefox with "Deer Park Alpha 1" and drop the official branding artwork.
Chase is flipping build system to remove --enable-official-branding
no changes to UA.
deb, can you point to the start page doc you are working on?
need to figure out what we want to do for desktop icons and install path.... easiest just to leave as is. that wouldn't allow 1.0.x and deerpark on the same systems. profile incompatiblities might make it hard for some users to go back 1.0 after running deerpark
Are we affecting the UA string for this release? I think we probably shouldn't.
darin, no, see comment 2. I think that was discussed and decided the same way a couple weeks ago.
Whoops, sorry for the SPAM. What about other things like the registry keys, profile location, and the default install path? Will the value of nsIXULAppInfo::name be changed from "Firefox" to something else? I think we should avoid making too many changes here.
I don't think it's worth it to make further changes. The goal for the rebranding is to differentiate these previews from our final releases and I think we've accomplished that.
documentation start page is here: http://developer-test.mozilla.org/docs/Deer_Park
Created attachment 183785 [details] [diff] [review] rebrand to deer park ok, so this rebrands the installer and the app to use "Deer Park" as the shortname and "Deer Park Alpha 1" as the long name. (So where it says "Firefox" it'll say "Deer Park" and where it says "Mozilla Firefox" it'll say "Deer Park Alpha 1"). This does change the default install path, but I think that's a good thing. We want users to be able to go back to their existing install if there's problems, and I've tested it without any negative effects (it doesn't change profile patches or exe names or anything really dangerous). This changes the desktop/quick launch/start menu entries as well, so this makes the alpha a safe install for existing users who don't want to lose their existing setup. To-do: Placeholder URL on www.mozilla.org for the Deer Park page (I can do that, and dria can replace it with real content based on what's on the wiki). Change "Firefox Start" to something appropriate to what we're calling the Deer Park start page. Both of these are trivial, where and what we're calling it is the stopper. Otherwise we're good to go.
You'll have to give me more information about what you would need/want for a start page -- the wiki documentation is essentially non-existant, and seems unlikely to get much more content any time soon (unless there are docs being worked on that I don't know about).
I think the idea was supposed to be a list of new features/API changes/other things that affect developers, both extension and web, sort of like a highly-detailed release notes setup. Asa was going to collate a bunch of different relnote lists, and do a call for feedback from everyone who's landed stuff since 1.7.x. I may be remembering wrong, but that was the idea. And there should have been more docs, yes... we (meaning Mozilla developers) still aren't good at that whole "documenting" thing. If I'm right on this, I'll create something as a placeholder tonight, and get these branding changes landed.
"so this makes the alpha a safe install for existing users who don't want to lose their existing setup." This isn't really true. We'll be affecting installed extensions and changing the profile in interesting ways that may cause users headaches when switching back-n-forth between this application and firefox 1.0. I think that those are the headaches we want to learn about now rather than later, so this is probably a good thing. I am a bit concerned that we are changing the registry keys used to locate the current version of Firefox. That just means that any third-party apps that rely on our registry keys to locate the installed version of Firefox will not find this alpha release. That's probably OK... but maybe just a little concerning that we aren't fully testing what a real Firefox 1.1 release would be like. Perhaps that will all be tested later on when we do a Firefox 1.1 PR.
Created attachment 184020 [details] [diff] [review] rebrand, remove recapture homepage code, change default homepage
Comment on attachment 184020 [details] [diff] [review] rebrand, remove recapture homepage code, change default homepage ok, my editor config was stupid on the new box. reattaching without the spurious whitespace changes shortly
I've put together a new page for summarizing the additions and changes in Deer Park Alpha here: http://developer-test.mozilla.org/docs/What%27s_New_in_Deer_Park_Alpha If anyone can help fill in some of the blanks with a sentence or three of explanation, it would be much appreciated. I'll do a full edit once we get some more content in place.
Created attachment 184025 [details] [diff] [review] without the spurious whitespace changes
Comment on attachment 184025 [details] [diff] [review] without the spurious whitespace changes I'm tempted to say that the installer should keep saying "Firefox" even as the rest of everything say Deer Park, just to avoid weird registry issues, but ok.
Comment on attachment 184025 [details] [diff] [review] without the spurious whitespace changes just getting ducks lined up, we can land this once we're ready to spin builds. Will also need Asa's modded image of course.
There's a summary for all items on the new/changed features list except SVG and <canvas>: http://developer-test.mozilla.org/docs/What%27s_New_in_Deer_Park_Alpha
Sorry: also missing notes for PrefWindowV and Searchable Download Actions.
Comment on attachment 184025 [details] [diff] [review] without the spurious whitespace changes a=asa
checked in for respins/testing. Remember that this patch requires building _without_ the --enable-official-branding switch, so if we respin with that we won't be testing these changes properly. Marking fixed for now. I'll file a followup for undoing the naming-specific changes after we ship a1
> Marking fixed for now. I'll file a followup for undoing the naming-specific > changes after we ship a1 So we won't reintroduce the reset homepage option for 1.1? And why was it removed in the first place?
No. Its been possibly the biggest source of complaints, especially with the 'full installer as upgrade' setup we currently have. We talked about this in the Deer Park meeting and everyone agreed that the best course of action was to remove it permanently.
(In reply to comment #5) > Created an attachment (id=183776)  > about "Deer Park" image It looks like the image never made it to the tinderboxen.
Our extension is broken by this name rebranding. our extension rely on windows registry to find firefox entensions directory and copy files to <firefox>/extensions directory. But now, it cannot work. How to detect firefox on system reliably ? Firefox 1.1 will be "Deer Park", will Firefox 1.5 be "The Ocho" ? third party need a reliable way to detect firefox.
Firefox 1.1 will be Firefox 1.1, Deer Park is what we're labelling the alpha releases as, but beta and final will be "Firefox"
Thanks clarification. So the final Firefox 1.1 can still be detected by HKLM\Software\Mozilla\Mozilla Firefox\CurrentVersion, is it right ? BTW, we rely on the nightly image on mozilla.org to test our product. We still want it to use HKLM\Software\Mozilla\Mozilla Firefox, if it's impossible, we need build Firefox by ourselves, enabling --enable-official-branding can help, is it right ? And the official Firefox 1.1 and higher versions will be built with " --enable-official-branding", right ?
This is incomplete. Mac still identifies itself as Firefox. The application menu is titled "Firefox" (and while the 'About' on that menu is "Deer Park Alpha 1", the Quti and Hide both say "Firefox",) the application bundle itself is titled "Firefox", and the About dialog/window says "Firefox" under the globe. The artwork is correct.
Also, the about image I attached at https://bugzilla.mozilla.org/attachment.cgi?id=183776 hasn't showed up in any of the platforms. -> Josh for mac stuff. Who can land the about image?
(In reply to comment #32) > Also, the about image I attached at > https://bugzilla.mozilla.org/attachment.cgi?id=bug hasn't showed up in any of > the platforms. Mike Connor landed that earlier today. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-05-23+08%3A22&maxdate=2005-05-23+08%3A22&cvsroot=%2Fcvsroot
OK. thanks. Also, found that the Windows installer incorrectly includes the "1.0+" all over the place. http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/installer/installer.inc#8http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/installer/installer.inc#8
Taking for mac bits
Created attachment 184335 [details] [diff] [review] mac build part, untested
Comment on attachment 184335 [details] [diff] [review] mac build part, untested According to Asa, we are supposed to leave Firefox in the copyright section.
Created attachment 184338 [details] [diff] [review] mac build part (partly backed out) tested.
I checked in the revised about image a few hours ago, it was in my checkin tree but didn't go in previously.
Comment on attachment 184338 [details] [diff] [review] mac build part (partly backed out) a=asa
Checked in, reassigning to Mike and resloving. Checking in Makefile.in; /cvsroot/mozilla/browser/app/Makefile.in,v <-- Makefile.in new revision: 1.77; previous revision: 1.76 done Checking in macbuild/Contents/Info.plist.in; /cvsroot/mozilla/browser/app/macbuild/Contents/Info.plist.in,v <-- Info.plist.in new revision: 1.11; previous revision: 1.10 done Checking in macbuild/Contents/Resources/English.lproj/InfoPlist.strings; /cvsroot/mozilla/browser/app/macbuild/Contents/Resources/English.lproj/InfoPlist.strings,v <-- InfoPlist.strings new revision: 1.6; previous revision: 1.5 done
Sorry for the "spam", but why do I get the feeling that this will finally be fixed in time to put it all back again?
<sigh/> Backed out the APP_NAME change due to bustage (APP_NAME isn't used for the diskimage, apparently), reopening.
The diskimage name is taken from MOZ_APP_DISPLAYNAME, but can be overridden in the makefile before you include packager.mk. See http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/installer/packager.mk#99
Created attachment 184350 [details] [diff] [review] more mac stuff... haven't tested (yet).
...and i'm not sure if it should be mac-specific (the _display_name change), but I'm not familier with the packaging code, and can't test it on a windows machine right now.
Comment on attachment 184350 [details] [diff] [review] more mac stuff... ick: this will do in a pinch, but I'd like to find a more generic solution (like a branding.mk file).
Looks like trying to uninstall "Deer Park" has unintended behavior I think.
Sorry for the bugspam. Last comment should have referenced bug 295272 : The new Deer Park branded alphas breaks the standard firefox add/remove entry
(In reply to comment #28) > Our extension is broken by this name rebranding. our extension rely on windows > registry to find firefox entensions directory and copy files to > <firefox>/extensions directory. But now, it cannot work. How to detect > firefox on system reliably ? Mike, You should probably use the new Windows registry-based install location: http://wiki.mozilla.org/Extension_Manager:Win32_Registry_Location The "deer park" branded firefox 1.1 alpha release will still look in the following locations for extensions: HKEY_CURRENT_USER\Software\Mozilla\Firefox\Extensions HKEY_LOCAL_MACHINE\Software\Mozilla\Firefox\Extensions FWIW, I raised this very concern in comment #14. I know this will break third-party global extension installers (that are not modified to use the Win32 registry based install location). Since this problem will only affect the alpha releases of Firefox 1.1, I don't think we should concern ourselves too much. However, this basically means that people using "firefox --install-global-extension" to install global extensions are screwed (for the deerpark alpha) because they will have no way to find out where firefox.exe lives. Hopefully those extension authors will learn about the Win32 registry based install location and use that instead, which is anyways the preferred method of installing global extensions into firefox on Windows.
Comment on attachment 184350 [details] [diff] [review] more mac stuff... Sigh, Deer\ Park (note the "\ ") isn't OK for hdiutil: cd ../../dist; /Users/mano/Development/Mozilla/ff4/mozilla/build/package/mac_osx/make-diskimag e firefox-1.0+.en-US.mac.dmg firefox Deer\ Park FOLDER_SIZE=61568 IMAGE_SIZE=63415 creating disk image hdiutil: create: Only one image can be created at a time. Usage: hdiutil create <sizespec> [options] <imagepath> hdiutil create -help However DeerPark works...
Any shell script guru in the yard? I guess that we need at least this change to make-diskimage: # Create the image echo "creating disk image" -hdiutil create -sectors $IMAGE_SIZE -fs HFS+ $DMG_TEMP_NAME -volname $VOLUME_NAME +hdiutil create -sectors $IMAGE_SIZE -fs HFS+ $DMG_TEMP_NAME -volname "$VOLUME_NAME" that, and a fix for the ditto call.
(In reply to comment #50) > You should probably use the new Windows registry-based install location: > http://wiki.mozilla.org/Extension_Manager:Win32_Registry_Location Thanks Darin! Yes. we can use this method. Unfortunately this feature came too late(it's only avaiable from 05/16/2005). we followed http://wiki.mozilla.org/Firefox:1.1_Extension_Manager_Upgrades to develop our extension and use nightly build on mozilla.org to test it. we've passed codefreeze deadline :-( > registry based install location). Since this problem will only affect the alpha > releases of Firefox 1.1, I don't think we should concern ourselves too much. Is that to say, Firefox 1.1 will rebrand back and use HKLM\Software\Mozilla\Mozilla Firefox again ? it's very important to us. And some code ( not extension) in our product need to detect the version of Firefox, it relies on HKLM\Software\Mozilla\Mozilla Firefox\CurrentVersion ,it's broken too. I tried to use --enable-offical-branding to build Firefox on win32, but it seems useless. "Deer Park" is still written in windows registry. Is there any workaround for us to build temporary Firefox which has the same registry layout as Firefox 1.1 ?
I'll attach a patch for backing out the branding changes tomorrow (need to do this anyway since i intend to debrand the trunk after we ship a1, and hopefully figure out a better plan for rebranding in general. I understand that you passed code freeze, but perhaps you could make an exception for this? There are another couple months before final at least...
Created attachment 184384 [details] [diff] [review] Remove version in installer screen Mike, can you land this? a=asa on IRC.
Comment on attachment 184384 [details] [diff] [review] Remove version in installer screen r=me, a=asa on IRC
Comment on attachment 184384 [details] [diff] [review] Remove version in installer screen a=asa
Comment on attachment 184350 [details] [diff] [review] more mac stuff... I have already noted this is incomplete. I will try to come up with something shortly.
Comment on attachment 184350 [details] [diff] [review] more mac stuff... assuming a=asa. Going to check this is in as DeerPark.dmg/DeerPark.app, on the app itself (windows,menus) "Deer Park" (note the space) will be exposed.
filed bug 295307 on the make-diskimage limitation.
The tinderbox hardly tries to use Firefox.app after the build, gah.
That was the bustage, in case someone is familer with the tinderbox scripts... /builds/tinderbox/firefox/Darwin_7.7.0_Depend/mozilla/xpfe/bootstrap/init.d/README ../../../dist/bin/init.d /builds/tinderbox/firefox/Darwin_7.7.0_Depend/mozilla/obj/dist/Firefox.app/Contents/MacOS/firefox-bin does not exist. Error: binary not found: firefox-bin
So, we need someone w/ access to the tinderbox itself (to fix up the testing script?)
Created attachment 184392 [details] [diff] [review] mac patch for checkin once the tinderbox are ready where ready=s/Firefox.app/DeerPark.app on the mac tinderboxes scripts.
(In reply to comment #31) > This is incomplete. Mac still identifies itself as Firefox. The application menu > is titled "Firefox" (and while the 'About' on that menu is "Deer Park Alpha 1", > the Quti and Hide both say "Firefox",) the application bundle itself is titled > "Firefox", and the About dialog/window says "Firefox" under the globe. > (To clarify, all of this is already fixed in the hourly builds. However,the dmg label/app-name/dock-label do need the last patch, I should point out that we haven't done this on windows, where the executable name isn't as exposed as on mac).
The "firefox-bin" executable name should not be changed. It's fine to rename the app bundle, but the internals shouldn't change at this point; we have too much code hanging around that tests and depends on the executable name.
Benjamin, i didn't point to the executable itself, just to the app bundle (which is considered as the executable from the user POV).
I changed ProductName on atlantia from "Firefox" to "DeerPark". Its next build will be a release build. This should be all that's needed to use the new app name.
Checking in app/Makefile.in; /cvsroot/mozilla/browser/app/Makefile.in,v <-- Makefile.in new revision: 1.81; previous revision: 1.80 done Checking in installer/Makefile.in; /cvsroot/mozilla/browser/installer/Makefile.in,v <-- Makefile.in new revision: 1.15; previous revision: 1.14 done
Chase, the ProductName change has two issues: * It shoudn't be done on candence, it seems we're still using offical branding on this tinderbox (this is causing a bustage). * It shoudn't affect the profile-existence check(s), since the patches here do not affect the profile folder location (this is causing orange on imola and atlantia). Noted on the tinderboxes as well.
Would someone with insight to the rebranding plan please announce in npm.l10n what localizers are expected to do? And how much of this is temporarily and what is there to stay, as someone may just land that seperatly to be able to back it out for beta, if I understood things right.
(In reply to comment #54) > I'll attach a patch for backing out the branding changes tomorrow (need to do > this anyway since i intend to debrand the trunk after we ship a1, and hopefully > figure out a better plan for rebranding in general. Hi Mike, a1 is released, would you please let me know when to debrand the trunk ?
Mike, I'm hoping to back out the assorted branding changes tomorrow, need to undo some tinderbox/build-box changes before I land that though.
(In reply to comment #73) > Mike, I'm hoping to back out the assorted branding changes tomorrow, need to > undo some tinderbox/build-box changes before I land that though. Hi Mike, do you have time to work on this issue ? Or Firefox 1.4 will revert back to normal registry naming ? It's planed for August, do you know what's exact date ?
1.4 will be Firefox Beta, as I understand it. Now, trunk may not follow the same path, we have yet to figure out what we're doing with trunk branding at this time. There is no exact date set for Beta, as with all of our releases its pretty much When Its Done.