Seen using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 STR: 1. Import a home page from IE or another browser during first launch 2. The user sees the www.mozilla.org/products/firefox/beta2.html) page. There should be some verbiage on the page that indicates the user will see this page only once. Not sure how this should be done, but it will minimize confusion since as a user I would expect it to show the home page I have imported upon first launch. Seen on Windows and Mac.

Jesse and I think this should be considered for RC1.

Some possible solutions: A. Add "You'll only see this once" to the start page, as suggested in comment 0. B. Remove the ability to import home pages. C. Remove the first-launch-page feature. D. Don't show the first launch page if you import a home page. E. Somehow show both the first launch page and your home page (using mutliple tabs or windows) (A) is probably best for Firefox 1.5 in order to minimize client code changes.

We've always ignored your start page the first time you run a new release for the first time to show you the first launch page. So this behavior isn't new per say. Have we had reports of users using new versions of Firefox that were confused about why they didn't see their home page (whether the google start page or a custom start page) the first time they launched an updated build?

It would be nice if the start page had an explanation and two buttons that say "go to my home page now" or "use this as my home page." That may be a bit tricky to implement and is probably beyond the scope of this release.

I think this is most problematic for new users (not users who have upgraded from previous versions of Firefox), because it happens right after they select "Import my home page from Safari" or "Import my home page from Internet Explorer".

Would be nice if the first launch page would simply disappear. I see it everytime when trunk and branch build succeed each other. Haven't found anything yet to prevent that.

Maybe a choice in the setup "Show important product information" or "Show my homepage" could also be an option.

(In reply to comment #6) > Would be nice if the first launch page would simply disappear. > I see it everytime when trunk and branch build succeed each other. > Haven't found anything yet to prevent that. You can set the "browser.startup.homepage_override.mstone" pref to "ignore" if you never want to see the "first startup" page.

I suppose that pref could also be used to easily disable this feature for 1.5, if desired.

Its not desired, IMO. I think we just need to make it more clear in the content that this is a first-startup page, which isn't a blocker for RC1. Another option (futured) is to open a second foreground tab with the first-run page, and closing that would get you to your homepage.

Rafael, we need to make it obvious on the first start page, if at all possible, that we're showing a one-time start page and that in future starts, it'll show the users's home page.

While we're discussing server-side changes to make this UE better: for 1.5 release ... * mozilla.org/releases/whatsnew should redirect to a mozilla.com address * the use of a full cavendish-skinned page is, IMO, unneccessary * title="Welcome to Firefox" * intro text~="Before you get started ..." * the page should be mostly graphical, point out the three big UE things we want to promote (tabbed browsing, auto-update, faster render times) * should have big links to add-ons, firefox product page * should have smaller links to devmo, mozilla.org and maybe even thunderbird

note: in reading that, I note that I failed to quantify "big". I actually, quite confusingly, don't mean "big" :) I mean "links to things like add-ons and 'read more about...' should be larger than links to devmo or other products." Overall, the goal of the page should be to tell the user a few things about their new toy, and then let them get browsing.

note: in reading that, I note that I failed to quantify "big". I actually, quite confusingly, don't mean "big" :) I mean "links to things like add-ons and 'read more about...' should be larger than links to devmo or other products." Overall, the goal of the page should be to tell the user a few things about their new toy, and then let them get browsing.

Suggest -'ing RC1 and +'ing RC2 as a way of making sure we hit this by launch, but not hold up our RC1 rollout ...

is this still blocking the 1.5 release and if so what is the status on this?

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

(In reply to comment #7) > Maybe a choice in the setup "Show important product information" or "Show my > homepage" could also be an option. This could be my choice: Keep the feature, but add a new dialog/option at the end of the migration to choose to start with the first-launch-page or the personal-home-page. I believe this option could be added on the dialog which selects/imports the home page !?

This page now redirects down to http://www.mozilla.com/firefox/central/ which has been designed to be a minimal announcement of some new features, as well as provide some useful things that people can do. Good enough to close this off?

I don't suppose there's any way of us knowing on that page whether or not someone has imported a custom start page? If there was, it would be cool it have a link that said something like: "Take me to my own start page: [Start Page Name]"

(In reply to comment #20) > I don't suppose there's any way of us knowing on that page whether or not > someone has imported a custom start page? If there was, it would be cool it The issue here is really making it clear to users that this welcome page is one-time-only, which is difficult because the exact same page is being used as the destination for throbber-clicks. I guess I really see two options: 1. Create seperate pages for throbber-clicks and the first-run page 2. Just don't use a first-run page In a bit more detail ... 1. The first-run page would be almost identical to the throbber-click page (ie: quick ways to get started with firefox, calling attention to browser features, etc) but could have a banner/arrow/element at the bottom that says "Start browsing with firefox!" that leads to the user's homepage (as was set in the migration piece). This presupposes that we can programatically hit that variable from a webpage, and I'm not sure that we can. 2. I'm not thrilled with this idea, as I think it's a good idea to welcome users and point out the new features of Firefox, however it should be considered (ccing cbeard for comment)

After a bracing conversation with shaver who made me realize that I've lost sight of the real issue here, I'd like to issue a retraction for comment 21, full-stop. For the purposes of this conversation let's forget the throbber target. Entirely. The goal of the first launch experience is to welcome new users to Firefox. Due to "we couldn't get anything better done in time reasons" we didn't create the type of experience that I would have liked. The exprience we want to give our new users is: - welcome to Firefox! - here are some fun things you can do with Firefox! - now let's get browsing We should do this in a way that communicates (either implicitly or explicitly) that this is a one-time deal, and that they can quickly move on to browsing the web. Some ways to accomplish this might be: - make the entire experience XUL - put it in an overlay that shows the user's homepage underneath - use a <browsermessage> or something (might be too small) Our strategy shouldn't be limited to the mitigations we copped to in the 1.5 release. Let's get it right. :)

cc:ing Axel. Getting this right means getting this page localized and having a fallback when a localization of the page isn't available.

Here's a *really* rough mockup to see if we're thinking of the same basic idea... I'm not advocating we do something like this, just throwing something out to have a visual frame of reference.

Comment on attachment 209127 [details] *Really* rough concept mockup Steven, this is precisely the sort of thing I'm thinking of. Definitely on the same page.

Though, um, if you pick one and click it, what happens then, if it never comes back again? It looks pretty cool though!

The tutorial / first-run experience could exist within that window, with navigation tools to boot. Shaver was talking to me about this today, and said that he threw together a proof of concept last night where we simply use the code to inject a <script> tag on first run that launches this first-run experience piece, so there's a definite route-to-implementation that provides rich interaction.

Technical details comments: I'd propose to get rid of the overlay when clicking anywhere on the transparency part. How do we cope with bad window sizes? This is in part an l10n problem, as they tend to have more problem with dialog sizes, they're usually larger than english ones. Can we expose the links we're shadowing? L10n comments: If this is a page inside our code, this seems reasonable. I'd like to see an evaluation of trademarks-compliance impact, though, and probably a QA plan, if this is trademarks-relevant. This is especially note-worthy if the links on that page extend our current set of pages. I'd like to get this blocked by fixing region.properties, this is part of our branding story which should be cleaned up wrt all those links we have.

Need to figure this out, one way or another. User feedback from the 1.5.0.1 release really implies that people like this type of thing, the means to do it is vastly imperfect.

-> beltzner for design-fu

I'd like to add a related request - whatever gets displayed, could it please be shipped with the browser and not obtained from the web? We use Firefox on an intranet without direct internet access, and we change the home page to an internal site - but on first launch each user would still get a timeout, or at best an unexpected proxy authentication dialog. (I hacked my way around the problem by changing the code in migration.js, but I don't really like that solution!) Harry.

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

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

Adding swag, cc'ing Michael Wu, intern extraordinaire, who did something like the rought mockup concept for Reveal.

That translucent overlay on the user's homepage is difficult to do. Google safebrowsing implemented it by using a big canvas and dimming a snapshot of the current webpage. It's possible to jack into the page dom and stick a big translucent PNG or something over it, but I'm not sure if that's a good idea. Otherwise, it doesn't seem difficult to implement since it isn't that far off from the first-run thing used in Reveal. The first-run + tutorial system in Reveal took a day to do.

For Firefox 2 this is what we should do for any *new profile* creation: - Open a "welcome to Firefox" page in a tab, user's homepage in other tabs (this is accomplished by Enn's patch in bug 339279, which I'll ask him to actually move over to here) Then we can open a new bug for Firefox 3 that takes the content from that URL and renders it in a sexy transluscent flyover, whatever. We should also take bug 324093, and not insist on hijacking the user's homepage on every update, but instead make it the update's responsibility to provide a release-note URL if its felt neccessary.

(In reply to comment #36) > We should also take bug 324093, and not insist on hijacking the user's homepage > on every update, but instead make it the update's responsibility to provide a > release-note URL if its felt neccessary. From the point of URLs in region.properties, we add the startup.homepage_welcome_url and remove the startup.homepage_override_url in favor of a URL provided by the update itself? Bug 324093 seems to be a moving subject, just want to make sure where the l10n stuff is going to end up, esp in terms of links to websites.

(In reply to comment #38) > (In reply to comment #36) > From the point of URLs in region.properties, we add the > startup.homepage_welcome_url and remove the startup.homepage_override_url in > favor of a URL provided by the update itself? Bug 324093 seems to be a moving > subject, just want to make sure where the l10n stuff is going to end up, esp in > terms of links to websites. Yes, that's right. I think we should make sure that the URLs that we use are all localized (ie: http://mozilla.com/whatever-we-want-%locale%) so that we basically remove the need to build/ship updated properties for each locale. Is that possible?

I generally hope to not add locales to URLs and instead push server side accept_lang detection. That way, minority locales like frisian or south african languages can pick up their majority languages if available without any deep dramatic server magic. And of course, the user could still change that and hint us at something we haven't thought of. Someone with a portugese version may actually prefer to see french content to english (and if it's a *really* savvy one, she'd adjust intl.accept_languages to "pt, pt-PT, fr, en" or so).

I think there might be some usage/tracking requirements here that we want to be aware of; can the server-side accept_lang detection provide those stats?

Shouldn't the locale name in the user agent be sufficient for most cases? I know, users can fake that, but I doubt that is statistically relevant.

Anytime that we can provide information in the URL string, the better. Out of the box, our Web stats package does not allow us to cross-tab a specific page view with agent string locale. Unique HTML file names are golden. (Remember, we don't track individual users or their browsing habits. We simply require a limited amount of aggregate information to best prioritize product development and IT resourcing efforts.)

pushing out non-critical-path bugs to b2

Comment on attachment 226342 [details] [diff] [review] startup patch >+ if (pagesToLoad && startpage) pagesToLoad += "|"; on two lines please > startup.homepage_override_url=http://www.mozilla.org/products/firefox/releases/whatsnew/ >+startup.homepage_welcome_url=http://www.mozilla.com/firefox/central let's change startup.homepage_override_url to http://www.mozilla.com/firefox/updated while we're here

(In reply to comment #45) <...> > let's change startup.homepage_override_url to > http://www.mozilla.com/firefox/updated while we're here > Actually, bug 318639 changes it to http://www.mozilla.com/firefox/releases/whatsnew/, and that URL is non-trivial redirecting to either updated, central, or bonecho. Just requested branch landing approval on that patch.

Axel, why not be explicit and point to the right place from the client?

(In reply to comment #47) > Axel, why not be explicit and point to the right place from the client? The bonecho redirect in whatsnew actually looks useful, and is a lot less complex than changing that URL in 50 locales back and forth. One could argue though that it may suffice to just move that pref into firefox.js and be done with it. Then it's merely a product decision with significantly reduced complexity. startup.homepage_welcome_url links to central, which is a bit more complex, as we require that to be localized anyway, so that should be in l10n. Assuming that we don't require that URL to point somewhere else for pre-rc non-firefox-branded versions.

I opened a discussion on url requirements and structure in .planning.

This was checked in on the trunk.

Need a followup for the web side, resolving this as FIXED.

Comment on attachment 226342 [details] [diff] [review] startup patch This has baked enough.

Comment on attachment 226342 [details] [diff] [review] startup patch > #config.js > startup.homepage_override_url=http://www.mozilla.org/products/firefox/releases/whatsnew/ >+startup.homepage_welcome_url=http://www.mozilla.com/firefox/central I'd love to see these change to: > startup.homepage_override_url=http://www.mozilla.org/products/firefox/releases/whatsnew/ startup.homepage_override_url=http://www.mozilla.com/en-US/firefox/2.0.0.0/whatsnew/ >+startup.homepage_welcome_url=http://www.mozilla.com/firefox/central startup.homepage_welcome_url=http://www.mozilla.com/en-US/firefox/2.0.0.0/central This makes mod rewriting super easy, and is pretty easy for localizers to understand. If there's ways of pulling those variables (locale, version) out of a single location, even better.

(In reply to comment #51) > Need a followup for the web side, resolving this as FIXED. Filed bug 345805 for that.

Comment on attachment 226342 [details] [diff] [review] startup patch a=drivers. Please land on the MOZILLA_1_8_BRANCH. I'll submit a followup bug to change the URLs, which will hopefully actually cue of enable-branding

I filed bug 348076 to change the URLs.