Initial start pages do not appear when starting Firefox with the -foreground flag followed by another flag the first time

RESOLVED WORKSFORME

Status

()

--
minor
RESOLVED WORKSFORME
8 years ago
2 months ago

People

(Reporter: whimboo, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [mozmill])

(Reporter)

Description

8 years ago
Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110113 Firefox/4.0b10pre

When you start Firefox the first time and the -foreground flag with a following flag has been specified on the command line, our initial start pages (tabs) are not opened. Instead only one single tab with the specified URL appears. But when you open a new window, those two tabs are getting opened.

We have seen this problem with one of our Mozmill tests which failed because of this problem. See bug 616152. A workaround for Mozmill has been pushed by bug 580438. But the underlying issue cannot be solved and we have to make sure that we do not push any other flag after the -foreground flag (which also gets added when you restart the browser afaik).

This bug only affects Windows and Linux. It's not present on OS X.
(Reporter)

Comment 1

8 years ago
Hit Enter too fast...

Here the steps:
1. Create a fresh profile but don't start Firefox
2. Start Firefox with: firefox -foreground -whatever x -p profile
3. Check the browser window
4. Open a new browser window
I highly suspect this is actually a Firefox specific bug and that it is handled in either http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js or http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserGlue.js

Gavin: can you confirm the above?
Yeah, the start pages are only opened when you hit the "defaultArgs" path in nsBrowserContentHandler on update, and that gets skipped if you pass -foreground. Bug 615785 is similar.
Component: Startup and Profile System → General
Product: Toolkit → Firefox
QA Contact: startup → general
Version: 1.9.1 Branch → Trunk
Due to some unrelated work I had test the ordering of flags today.
There are cases where the ordering, or rather duplication, of flags
matter.  For example "./firefox -profile foo -profile bar" is
permissable and will pick the latter profile.

I could not, however, reproduce the bug where -foreground before
the -profile argument triggers different behaviour than after.
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.