I built 0.92 under Solaris 2.6 with the GNU xpm library. Upon testing I found that this version would not honour the DISPLAY environment variable regardless of how this variable was constructed. I see this a bug and reporting it as such BUT if this is expected behaviour I would like to know. I previously built 0.91 GECKO with GTK and remote display worked well. I have no binary at the moment as I am about to try 0.92 with GTK to see if the problem persists in this build.

Interesting. Does it honor the "--display" command-line argument? The code for the Xlib version looks like this: char *displayName=nsnull; for (int i = 0; ++i < argc-1; ) /*allow both --display and -display*/ if (COMPARE_FLAG12 ("display",argv[i])){ displayName=argv[i+1]; break; } // Open the display if (mDisplay == nsnull) { mDisplay = XOpenDisplay(displayName); the manpage claims that if XOpenDisplay is passed NULL it will default to using the DISPLAY environment variable....

.

The manpage is correct, NULL is often used as a shortcut for "current display" which is retrieved from DISPLAY variable. "setenv DISPLAY remote:0" would do the trick. 0.9.2 and recent CVS versions work remotely just fine (for me). adding to xlib tracker

Thanks for the setenv string. I am aware of it syntax. With xlib, this setting was NOT obeyed. Remember this is Solaris 2.6, gcc and gnu xpm. The GTK compile has just finished and I will be testing today.

UPDATE: GTK version behaves as expected. I am updating via this version. Now to rebuild xlib version.

Builds take over 24 hours on the build machine. I will update when build is complete.

In testing mozilla-0.92withxlib using DISPLAY=host.domain.com, I get: ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= registerSelf for remoteControl nsDeviceContextXlib::Init(dpy=2e3f70 screen=2e4ad8 visual=2deeb0 depth=24) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 12 Current serial number in output stream: 13 Setting DISPLAY to theh IP of the remote system, I get: %[677] setenv DISPLAY aa.bb.cc.dd:0.0 %[678] mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsDeviceContextXlib::Init(dpy=132b00 screen=151c70 visual=102a00 depth=24) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 12 Current serial number in output stream: 13 Testing this version with the local Xsun, gives a working Mozillawith initial output of: %[501] cd /backup/mozilla/dist/bin %[502] mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsDeviceContextXlib::Init(dpy=132b00 screen=153138 visual=14e670 depth=8) Getting the xlib connection number. NS_TimeToNextTimeout() lives! NS_ProcessTimeouts() lives! So there is something funny going on wrt remote usage. What next?

G. Singleton, what X server is the remote system running? Could you possibly use a debugger to step through startup and determine where exactly the error occurs?

I have only dbx and an old one at that. I will try. If you have later debugging tools such as forte or even a current gdb, would making the image available make more sense. My test platform is an SS-2 if you catch my drift. I you agree, let's go offline so that I don't have to expose myself.

we still don't like this scenario, reporter can you run mozilla through truss? r=timeless

Trying patch. Will post results here.

patched, re-compiled and tested using $DISPLAY and specifiying --display on the commandline. No change in behaviour. This version does not honour remote display. BTW, local display is okay as before. Errors are as follows: %[706] mozilla --display=aa.bb.cc.dd:0.0 ./run-mozilla.sh ./mozilla-bin --display=aa.bb.cc.dd:0.0 MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsDeviceContextXlib::Init(dpy=132b00 screen=153138 visual=106b88 depth=24) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 12 Current serial number in output stream: 13 %[703] setenv DISPLAY myhost.MYDOMAIN.org:0.0 %[704] mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsDeviceContextXlib::Init(dpy=135078 screen=131270 visual=10bb80 depth=24) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 12 Current serial number in output stream: 13

> %[706] mozilla --display=aa.bb.cc.dd:0.0 Could you try mozilla --display aa.bb.cc.dd:0.0 instead? We most definitely do not support that equals sign being there (though we maybe should and that's a separate bug).

Which doesn't explain why the DISPLAY var is not picked up right, btw.

%[715] mozilla --display myhost.mydomain.org:0.0 ./run-mozilla.sh ./mozilla-bin --display pather.pathtech.org:0.0 MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsDeviceContextXlib::Init(dpy=132b00 screen=153138 visual=102a00 depth=24) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 12 Current serial number in output stream: 13 %[716] mozilla --display aa.bb.cc.dd:0.0 ./run-mozilla.sh ./mozilla-bin --display aa.bb.cc.dd:0.0 MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= nsDeviceContextXlib::Init(dpy=132b00 screen=151c70 visual=102a00 depth=24) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 12 Current serial number in output stream: 13 As you can see. Still not working with remote display. Before some one asks, yes xhost is properly enabled. Is the fact that the host machine is running 2.6 significant? It shouldn't be but ...

depth=24. I'm going to bet that your ss2 doesn't like that. try reading through http://www.google.com/search?q=X_CreateWindow+BadMatch and perhaps some bug in bugzilla about colordepth issues. RichB: help? I'm pretty sure someone @Sun knows something about this... I suspect this article is a relatively good explanation for what's happening http://www.google.com/search?q=cache:U7lCUhtoT9k:www.adobe.com/support/techdocs /1a5f6.htm+X_CreateWindow+BadMatch&hl=en [ignore details like application and os] I don't know offhand how to tell mozilla to use something other than 24bit... can you give us the output from dpyinfo (i think that's it) for both the working and nonworking xservers?

You guys are the experts but I think that this error would also showup when displaying on the host machine. This does not happen. The SS-2 uses a CG-6 graphics interface whilst the remote machine uses a CG-14 and the error occurs only when attempting to display remotely. hope this helps.

Tested Roland's image. It too will NOT display remotely this time from my SS-20 Solaris 7 box to another. See http://puck.informatik.med.uni-giessen.de/download/mozilla-sparc-sun-solar is2.7-0.9.2-xlib.tar.gz for his image.

OK... my binary does work. But not with all Sun framebuffers... ;-( It looks that SPARCstation5/Ultra1/Ultra5/Blade_100_ are working. But machines with Expert3D/Creator3D do not work. This issue is independent of local/remove X11 and only depends on the fact that there a visuals with different depths...

Then you agree you binary is buggy since it will not work universally. If compiling with --enable-toolkit=xlib produces an executable that will not xhost properly then this is the scope of my original submission. I, too, can say that my binary works plus it is cross-platform. If what you claim about framebuffers is true then I suggest that this be fixed. Since your binary is plagued as well, can you contribute to getting a fix?

I recommend this bug report be closed. The work that Roland.Mainz@informatik.med.uni-giessen.de has done between my posting this report and his posting of his 0.93 version for Solaris has eliminated the problem that this bug addresses. Thanks Roland. I would appreciate a copy of your .mozconfig so I can get a working 2.6 version.

Interesting. I'll try to test on a Creator3D framebuffer on weds.

0.93 built with a .mozconfig as follows: # sh # Build configuration script # # See http://www.mozilla.org/build/unix.html for build instructions. # # Options for 'configure' (same as command-line options). ac_add_options --enable-toolkit=xlib ac_add_options --enable-mathml ac_add_options --enable-svg ac_add_options --enable-crypto ac_add_options --enable-jsd ac_add_options --enable-optimize ac_add_options --disable-tests ac_add_options --disable-debug using xpm-3.4k (xprint replacement), gcc-2.95.3 and gmake-3.79.1 produced the following when attempting to xhost to my SS-20: %[543] mozilla ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= registerSelf for remoteControl X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 12 Current serial number in output stream: 13 I had hoped this version was capable. Compiling with GTK and Glib produces a binary that works as expected except slow.

As before xlib-toolkit version for Solaris 2.6 works like a dream on the local machine but refuses to work with a remote display. I think Roland is correct about it being hardware sensitive. I have saved the dist if any one wants it.

Uhm... what is this: -- snip -- xpm-3.4k (xprint replacement) -- snip -- ??

> Uhm... what is this: > xpm-3.4k (xprint replacement) > It is my understanding that this is one of its functions.

ROTFL... uaaaah... uaaaah... Sorry... :-)) No... AFAIK xpm is simply the libXpm stuff - nothing more - which isn't required for Mozilla's Xlib-toolkit Xprint is something completely different... - it is a client/server print API which uses the X11 protocol...

That would explain the odd behaviour on 2.6. Is there an xprint for 2.6? Source or package would do.

> That would explain the odd behaviour on 2.6. Which odd behaviour !? > Is there an xprint for 2.6? Source or package would do. Uhm... Xprint support was added in MU4(=Maintaince Update 4) for Solaris 7; it was never backported to Solaris 2.6 (open call and ask Sun why ? (answer: 2.6 is DEAD)). But you can grab X.org sources (X11R6.6) and build libXp.so and Xprt (X11 print server) yourself - details on demand. But AFAIK Mozilla does not require the existence of libXp.so not Xprt - of libXp.so is not available it simply turns the build of the Mozilla Xprint module off - don't worry...

Thankyou. I am becoming more and more convinced that Roland Mainz is correct about this problem being hardware related. The Mozilla host machine is an SS-2 running SOlaris 2.6 with a CG-6 framebuffer. Mozilla-Xlib works locallay but when trying to have this binary display on another machine (xhosting) I get the problem as described. However, employing the downloadable 0.93 Sol7 binary in other direction, all works. If there's anything else I can do to solve this problem, let me know.

OK... I have a patch from Sun which adds 8+24bit support to the m64 framebuffer in my Ultra5. I have two heads, left screen runns with 8bit, right screen with 8+24bit (various 8bit visuals (8bit PseudoColor is the default+1st in the list) and one 24bit TrueColor visual (last one in visual list)). Left screen works, right screen causes BadMatch error in nsWidget::StandardWidgetCreate(): -- snip -- case eWindowType_toplevel: mIsToplevel = PR_TRUE; parent = XRootWindowOfScreen(mScreen); printf("depth=%d, vclass=%x, visualid=%x, parent=%lx\n", (int)mDepth, (int)mVisual->c_class, (int)mVisual->visualid, (long)parent); mBaseWindow = XCreateWindow(mDisplay, parent, mBounds.x, mBounds.y, mBounds.width, mBounds.height, 0, mDepth, InputOutput, mVisual, attr_mask, &attr); AddWindowCallback(mBaseWindow, this); SetUpWMHints(); break; -- snip -- Console output: -- snip -- Initialized app shell component {28c13ee3-ca0c-4395-be98-d126ead3b941}, rv=0x00000000 xxlib_find_handle: 'xxlib-default' entry 185448 nsDeviceContextXlib::Init(dpy=17f540 screen=16a9f0 visual=18a110 depth=24) depth=24, vclass=4, visualid=29, parent=33 nsAppShellXlib: Warning (X Error) - BadMatch (invalid parameter attributes) Abort -- snip -- Any clues ? ---- BTW: attachments 41850 isn't required anymore... I fixed that issue in another bug.

Accepting bug. Thanks to the new feature patch for the m64 driver from Sun I was able to hunt this issue down... :-) Patch follows...

Requesting r=/sr= ...

Comment on attachment 49090 [details] [diff] [review] Better patch for 2001-09-08-08-trunk per timeless's IRC comments Looks I forgot to fix Dnd window code, too ... ... new patch follows ...

Requesting r= ... (no sr= required because all code touched by the patch is not part of the default build).

What is r= ? I am still interested in helpling.

G. Singleton wrote: > What is r= ? I am still interested in helpling Basically you look at the patch and _review_ it (see http://mozilla.org/hacking/reviewers.html for details). r={your_email} means that the patch is OK for you and that you like it. Well... and you're in charge when the patch causes trouble... =:-) Mozilla.org usually requires a two-step review system (review&&superreview), sometimes a 3rd step (a= --> approval) is required, too.

r=caspian.maclean@tuxia.com for attachment 49095 [details] [diff] [review] (Better patch for 2001-09-08-08-trunk)

CC:'ing jst@netscape.com for superreview ...

Comment on attachment 49095 [details] [diff] [review] Better patch for 2001-09-08-08-trunk sr=jst

Fix checked in (http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&branch=HEAD&cvsroot=/cvsroot&date=explicit&mindate=1000850340&maxdate=1000851300&who=jaggernaut%25netscape.com). Marking bug as FIXED.

Thank you, Roland!!

G. Singleton: Could you please VERIFY this bug, please ?

Not at this time. I have an active project that prevents me from building. If you can point me to a Solaris 2.6 binary, I can test otherwise, no. THe point has become moot since we began this exercise as 2.6 is EOL'd (see http://www.sun.com/software/solaris/2.6/) Why flog a dead horse when it will no longer have good support?

Uhm... this issue isn't Solaris 2.6 specific. It always happens if the rootwindow's visual is not the "best" visual ("best" in the view of GDK/GTK+ weired visual choosing alrorithm). Always happens for me if rootwindow uses a 8bit pseudocolor visual but the framebuffer supports 24bit truecolor/directcolor, too ...

I'm confused. I submitted this bug against xlib-toolkit. All versions that I built using GTK, worked as expected. Thus versions of Mozilla needed for 2.6 can be successfully built using that toolkit. I personally believe that persuing xlib-toolkit issues with this particular version of Solaris is no longer required. As for later revs of Solaris your previous work corrected the problem in Sol7 and, I assume, Sol8. Do we need to beat the dead horse some more. I'm willing but I need a working binary.