User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.1) Gecko/20061223 Firefox/2.0.0.1 Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.1) Gecko/20061223 Firefox/2.0.0.1 The command line options -new-tab is not suppported under os2, every time you open an url from command line it will be opened in a new window. This option is available in unix builds, should be easy to enable also for OS/2. Reproducible: Always Steps to Reproduce: 1. 2. 3.

What happens if you call e.g. firefox -new-tab http://www.mozilla.org I took a quick look in the code and for Firefox it is implemented in cross platform code (browser/components/nsBrowserContentHandler.js line 353). Does it work on Windows?

(In reply to comment #1) > What happens if you call e.g. > firefox -new-tab http://www.mozilla.org tried on two different installations, always opened a new window with the url. >Does it work on Windows? Yes, windows support it, just tested with ffox 2.001 and NT4.

Then this is a real bug not just an enhancement request. ;-) I confirmed this using my own build of FF 2.0.0.1. I guess that it is related to the problem with new windows that open when calling FF from external applications, even when browser.link.open_external is set to 3 (which should open a new tab instead and is the default). That is a problem that comes up every now and then in the newsgroup.

Hmm, I am a bit confused. From what I see in the code a bare -new-tab <URL> does not seem to be supported on any platform. What should be supported, though, is the -remote functionality, i.e. firefox -remote openURL(http://www.mozilla.org,new-tab) As this doesn't work on OS/2, I am just trying to debug why not...

(In reply to comment #4) > Hmm, I am a bit confused. From what I see in the code a bare -new-tab <URL> > does not seem to be supported on any platform. What should be supported, > though, is the -remote functionality Both are supported, cross-platform (see http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/components/nsBrowserContentHandler.js&rev=1.33#371).

Thanks for the hint Gavin, must have been blind not to see that... A little bit more debugging and I found out that our z-order stuff is as broken as on Linux so we need to #define BROKEN_WM_Z_ORDER (as added in bug 302281 for Unix) on OS/2, too. This patch does just that. Then -remote() with new-tab or new-window and bare -new-tab and -new-window arguments as well as the hidden pref browser.link.open_external works as they should.

Comment on attachment 254720 [details] [diff] [review] #define BROKEN_WM_Z_ORDER on OS/2, too Is there a bug filed on the OS/2 Z order code being broken, or is it the same issue as bug 156333 comment 0? Either way, it'd probably be a good idea to file a new one so that this hack can be removed someday if that ever gets fixed.

Fix checked into trunk. Good suggestion, Gavin. I filed Bug 370134 about this issue.

Comment on attachment 254720 [details] [diff] [review] #define BROKEN_WM_Z_ORDER on OS/2, too This is a simple OS/2-only workaround. But as it is in a cross-platform file, I would like to get approval for 1.8 branch.

Comment on attachment 254720 [details] [diff] [review] #define BROKEN_WM_Z_ORDER on OS/2, too approved for 1.8.1.4, a=dveditz for release-drivers

Checked into branch. (QA team: as there are no branch nightlies for OS/2 this will as usual only appear in the next release at which point I will verify.)