With latest mozilla-1.3-r2, mozilla will sometimes quietly exit when asked to display certain (unfortunately ill-defined URLs) or files. This looks a lot like mozilla bugs #20224, #18013 but not on their specific examples. This also can happen when simply browsing some (unfortunately not noted at the time by me) URLs. As a test, I verified this also with 1.4-r3 (where someone reported something similar fixed). I do not recall any such behavior with 1.0.1-r3 (else it would not have suddenly surprised me), so I'll go back to that. If I *do* see it there, I'll pass that on, too. I doubt this is sparc specific, but I have no way of verifying or refuting. Hence, reported under sparc. Reproducible: Always Steps to Reproduce: 1.go to "http://distro.ibiblio.org/pub/linux/distributions/gentoo/experimental/sparc/livecd/sparc64/" 2. Left-click on the first "...iso.bz2" 3.Watch mozilla exit Actual Results: mozilla quietly exits. Expected Results: Either garbage on screen or (better) "Mozilla doesn't know what to do with application/bz2" lacewing root # emerge info Portage 2.0.48-r5 (default-sparc64-1.4, gcc-3.2.3, glibc-2.2.5-r2,2.3.1-r4) ================================================================= System uname: 2.4.21-sparc-r1 sparc64 sun4u GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="sparc apm avi encode fbcon foomaticdb gif jpeg mad mikmod mpeg ncurses nls png pdflib spell truetype xv xml2 xmms gdbm berkdb slang readline tetex tcltk java guile X sdl gpm tcpd pam libwww ssl perl python imlib gtk qt motif opengl mozilla cdr mysql -oggvorbis crypt -arts -alsa -esd -oss cups ruby tiff zlib Xaw3d bidi stroke cjk -gnome -kde" COMPILER="gcc3" CHOST="sparc-unknown-linux-gnu" CFLAGS="-mcpu=ultrasparc -O3 -pipe" CXXFLAGS="-mcpu=ultrasparc -O3 -pipe -Wno-deprecated" ACCEPT_KEYWORDS="sparc" MAKEOPTS="-j3" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache" ====== This system is actually completely current with "emerge -uv world" on 11.viii.03
I see that 1.4-r3 is now released for sparc, so I regenerated and all comments refer to " [ I] net-www/mozilla-1.4-r3 (0)" This looks more like #20224 than anything else, and I am sure it is font related: one one system, I get the mozilla termination, and on a second system, I get the expected garbage on the screen with my little test case. I am willing to believe that the failing system (Ultra-2) is misconfigured or has some stale files lying around; on the other hand, mozilla really should recover better that just to disappear (as in complain about what it doesn't like).
Also, it's somehow environmentally sensitive: If I try as root, it notices that "... .iso.bz2" is "application/octet" and asks for help. But even if I start with a completely empty '~/.mozilla' directory, it tries to display the file, and depending on the system, shows junk (OK) or quits (not OK).
Testing things here and unable to replicate (on a Blade 100). Also running XFree using the X Font Server. Are you using XFS or not? I'll try replicating on an Ultra2 when it frees up.
Several comments. I think I am reporting two different problems; one having to do with inappropriate behavior for "application/octet-stream" files, and one having to do with strange fonts. But first: 1. Xfs --- normally, not used, but starting it seems to have no effect; 2. The U60 tests are in fact being run from (and displayed on) the U2, but a quick check shows that doesn't matter. 3. For the U60, the "iso.bz2" files are shown as garbage, root or me. 4. For the U2, root says 'Don't know what to do with "application/octet-stream"'; but for me, it tries and dies. 5. The "strange fonts" problem is related to sites like "www.geocities.com/dharwadker/", and that URL does not seem to kill 1.4. (But, the display is really rough-looking; I haven't a clue what the authors' math fonts are.) So, I think I am looking at a problem with mozilla & mime-types, and so far it has been beyond me so far to figure out where mozilla makes its decisions regarding them. I know that for U2/root, it gets it right, for U60/anyone it gets it wrong but acceptable, and for U2/me it gets it wrong. I suspect that the resolution will be: Second problem (the one like 18013 "ilse") no longer reproducible with 1.4; First problem: Someplace somehow I am giving mozilla bad mime-type information. If I knew where it got its information, I'd just fix it. Hint: Starting mozilla with empty or missing '~/.mozilla' directory does not cure anything; mozilla never gets to 'mimeTypes.rdf' *Something* in my environment is leading mozilla astray. Data: U60/any -- gets 'iso.bz2' wrong and shows junk U2/root -- gets 'iso.bz2' right --- i.e., punts U2/me -- gets 'iso.bz2' wrong, tries to process, and exits (or aborts?) It will only be by chance who, if anyone, can duplicate. Someone should know where mozilla gets its information, though. Sorry to ramble, Ferris
OK, this one should be closed as follows: (1) the upgrade from mozilla-1.3-r2 -> mozilla-1.4-r3 seems to cure the problem related to difficulties displaying sites like the "4-Colour" site with strange font sets; (2) U2-root is and never was right; I was accidentally comparing the "ftp://..." site with "http://...", and ftp is fine for everyone. (3) The U2-exit is going to be a stale-files problem, like my recent forum flow of consciousness. Something is causing mozilla to perform a normal exit. (I.e., on exit it clears its lock file, makes sure context is up to date, etc.) What is *doesn't* do is report why it is doing such a thing. (4) So, net is that I was reporting one real bug which was being fixed as I was reporting it, a problem related to stale files (I believe) that mozilla is getting hold of, and what looks like less than informative behavior on abnormal termination (unless, of course, displaying an unprintable file somehow sends mozilla 'Ctrl-Q'). Sorry for the fire drill; Ferris
Here's the complete resolution: 1. The '4-colour' site problem's killing mozilla was fixed by unmasking mozilla-1.4-r3 at the same time I was reporting against mozilla-1.3-r2 2. The 'iso.bz2' problem was caused by having 'x11-libs/xft' on the system along with xfree-4.3.0-r2, and mozilla was compiling against the xf-version but ending up using the xft version. 3. Here's how that happens: Because of the openGL problem at #19776, I had installed xfree using a sequence thus: ebuild xfree-4.3.0-r2.ebuild fetch unpack compile << Manually patch up xc/lib/GL/glx code >> ebuild ... install qmerge Maybe not elegant, but it gets what I want. 4. As a side effect, no xft/xfree conflict is seen; to get that, I did emerge xfree-4.3.0-r2.tbz2, saw the conflict, and had sort of an AHA moment. So, there is no mozilla problem, and this is a user error or side effect of a completely unrelated bug (19776); take your pick.
As per user comments, resolving.
