mozilla-1.4-r3 and mozilla-firebird-0.7 seem to have problems displaying some instances of URLs which are not meant to be displayed (in the given example, it's a livecd iso image for sparc64). For me on sparc64, it's about 90% failure rate; a couple e-mails on the same subject suggest my 10% success rate makes me lucky. Extracts from these are included in the "additional information" below. So, what's failure? A (usually silent) exit. Reproducible: Sometimes Steps to Reproduce: 1.mozilla http://gentoo.oregonstate.edu/experimental/sparc/livecd/sparc64/ 2.Left-click on the first iso image file. 3. Actual Results: Almost always, mozilla thinks a little bit then just exits. Expected Results: A screen full of garbage. My systems are current gentoo-sparc-64 systems, running either xfree-4.3.0-r2 or xfree-4.3.0-r3. Problem is verified on non-sparc systems, and I will make attachments of the relevant e-mails confirming (all my systems are sparc). Here's the 'emerge info' from the U60: ======================================== antaresia mozilla # emerge info Portage 2.0.49-r15 (default-sparc64-1.4, gcc-3.2.3, glibc-2.3.2-r1, 2.4.21-sparc-r1) ================================================================= System uname: 2.4.21-sparc-r1 sparc64 sun4u Gentoo Base System version 1.4.3.10p1 ccache version 2.2 [enabled] ACCEPT_KEYWORDS="sparc" AUTOCLEAN="yes" CFLAGS="-mcpu=ultrasparc -O3 -pipe" CHOST="sparc-unknown-linux-gnu" COMPILER="gcc3" 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" CXXFLAGS="-mcpu=ultrasparc -O3 -pipe -Wno-deprecated" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="sparc avi crypt encode fbcon foomaticdb gif jpeg mad mikmod mpeg ncurses nls oss png pdflib spell truetype xv xml2 xmms zlib gdbm berkdb slang readline arts tetex java mysql tcpd pam libwww ssl perl python imlib gtk qt motif opengl mozilla X ruby ruby18 tcltk tiff -gnome -kde cups bidi cjk stroke -oggvorbis -esd -sdl" antaresia mozilla # =================================
Created attachment 20907 [details] e-mails confirming reproduction on systems other than mine. This started as e-mail, because I didn't know if I was seeing something sparc-specific or not. My original e-mail is reproduced at the end of the attachment.
One further observation, which is completely subjective and perhaps a red herring. mozilla seems to handle garbage better the SLOWER the internet connection. The systems referenced <lacewing, antaresia> in my e-mail are DSL-connected, and seem to do better if our ISP gets very busy. The system <terciopelo> is pertty much a clone of <lacewing>, except that instead of 2x400Mhz (SMP sparc-v9-ultra2), it is 2x300Mhz. More relevant, it is a slow dial-up system. (56Khz modem on a good day.) It "seems" to handle the garbage better, but as I said in the e-mail, I am not setting there reloading over & over again.
And also (on sparc, at least) mozilla-1.4.1, mozilla-1.5-r1 show same silent death.
The 'http://...' is important; 'ftp://... .iso' works fine. Since this came up under #33923 (mozilla-1.5-r1, mozilla-firebird-0.7 look OK for sparc), I'll try to clarify here, too. All my mozillas handle 'ftp://... .iso' correctly. It's when I go down the 'http://... .iso' path that mozilla gets in trouble. If I left-click instead of right-click in order to save the file, mozilla decides it's text and tries to display it. So, it is poor reaction from mozilla following a user's (my) mistake.
Ferris, does this continue to be a problem with current versions of mozilla and mozilla-firefox?
Aron, it is with mozilla-1.6-r1 (or it was a few days ago when I tried it). I don't know about firefox yet. Unfortunately, I can't think of a way to narrow it down to "if you try to display a file that looks like <...> then mozilla has fatal difficulties."
Ok, I'm unable to repro this on x86 (pentium4). I'll try on alpha. Though of course... I don't know what I'll do with a reproduction. This is beyond the time investment I can put into problems at the distribution level. It really needs to go upstream to bugzilla.mozilla.org I'll try to repro anyway, just for the sake of seeing it myself. Then I'd recommend pushing it upstream.
With xorg-x11, mozilla-1.6-r1, this does not occur. So I can no longer reproduce (or, I won't be able to). So, so far as I am concerned, it may be closed.
Good enough...
