111 bytes, application/vnd.mozilla.xul+xml
118 bytes, application/vnd.mozilla.xul+xml
34 bytes, text/plain
123 bytes, text/html
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113 Use of a <bindings> section in a template query can hang Mozilla. Please see the attached files. This topcrash.xul file, when invoked using -chrome from the command line, used to cause a crash (1.5). Now it causes an instance hang, which is rather more inconvenient. It also erases all desktop icon images from the desktop on some Win Windows versions (try Win98SE). That is new behaviour. Reproducible: Always Steps to Reproduce: Save attachments to file:///tmp/. Run: mozilla -chrome file:///tmp/topcrash.xul Expected Results: In theory this code could be a legal template query. It is certainly a combination most developers will try at some point.
When I perform your steps to reproduce with a current linux trunk build, I correctly get a 0px by 0px transparent XUL window (since that's what you asked for). No hang. I can't test the icon thing, obviously.
Bear with me while I trudge through OS compatibility issues please. I've reduced things as follows: On Windows, icon image disappearance is caused if 1.5b and 1.6 are used in some specific order without a Windows reboot in between. Alternating the two versions is too much for Windows' little mind and for this special case of XUL. When I rebooted and stuck to 1.6 only, I saw a 0px height window, which is correct. The topcrash I saw in 1.2-1.5 is fixed in 1.6 and there is no issue for Windows. I used standard 1.6 for my test on Linux; I'll pull the latest trunk and see if Boris' results happen for me.
OS: All → Linux
Linux: I downloaded and tested this nightly build ... http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/ mozilla-i686-pc-linux-gnu.tar.gz 18-Jan-2004 12:59 12.9M mkdir -p /local/install/test cd /local/install/test gzip -bc /tmp/moz...tar.gz | tar xvf - cd /local/install/test/mozilla ./mozilla -chrome file:///tmp/test/topcrash.xul I get no window (GNOME 2.02, sawfish, vnc) and no process item in the GNOME user panel. I tested with a fresh GNOME/vnc session, no difference. GNOME 2.02 is self-compiled; I also have GNOME 1.2 out-of-the-red-hat-box. Test results the same under both. If I add <description>foo</description> as the first tag inside <window>, then I get both a window and a GNOME panel item. On one occassion I got a window that was resizable, but whose contents wasn't rendered before or after I played with the sawfish resize handles. I can't reproduce that. Creating and using a new profile does nothing. I've reviewed the runtime and compile time requirements for mozilla, and I meet all the specs except vnc. I use a lightly updated RedHat 7.3 as my "act like a lagging reader" test box. RH 7.3, kernel 2.4.7-10, GNOME 2.02, Xvnc 3.3.3r2 rpm -qa | grep glibc = 2.2.4 rpm -qa | grep libstdc = 2.96-98 and 3-3.0.1-3 bash 2.05.8(1), gcc 2.96-98, perl 5.6.0, gmake 3.79.1, cvs 1.11.1p1, autoconf 2.13 Any other positives? Should I blame Xvnc? Otherwise, a box comparison with bz is in order. - N.
Do you get a mozilla process in the "ps" list? With your exact steps I am still getting a 0px by 0px window; it may just be that your WM fails to deal with those. I'm using AftersStep as the WM on a RH 8.0 box.
A more general case: reduce the XUL to <window xmlns...></window>. It's nothing to do with templates (prolly), except that templates can reduce an apparently populated XUL document to zero final contents. I'm used to the 1.5 template bug; sorry for the circuitous route here. I think GNOME panels are part of GNOME, not the WM. I've tried Enlightenment (0.16.4) + GNOME. Same bug. For the first time since 1987 I tried twm (+ GNOME). Wow, twm's green. Same bug. I tried twm without any GNOME desktop, ie near-raw X. Same bug. The "TWM Icon Manager" (left click on background) does not report a Mozilla X client. Neither does Enlightenment's root toolbar (middle click). twm version = XFree86-twm-4.1.0-3 (from rpm -qa). Mozilla processes are there: ps -fHunrm reports in part: nrm 1966 1723 0 09:34 pts/0 00:00:00 /bin/sh /local/install/test/mozilla/run-mozilla.sh ./mozilla-bin -chrome file: nrm 1972 1966 5 09:34 pts/0 00:00:00 ./mozilla-bin -chrome file:///tmp/test/topcrash.xul nrm 1974 1972 0 09:34 pts/0 00:00:00 ./mozilla-bin -chrome file:///tmp/test/topcrash.xul nrm 1975 1974 0 09:34 pts/0 00:00:00 ./mozilla-bin -chrome file:///tmp/test/topcrash.xul nrm 1976 1974 0 09:34 pts/0 00:00:00 ./mozilla-bin -chrome file:///tmp/test/topcrash.xul nrm 1977 1974 0 09:34 pts/0 00:00:00 ./mozilla-bin -chrome file:///tmp/test/topcrash.xul Appears normal. Can you try raw twm over Xvnc and/or Xfree86? I used a second box to telnet to the x-server box and kill/start processes by hand that way. My only X processes are: xterm, Xvnc, twm. My Xvnc command line (mostly default values): Xvnc :1 -desktop X -httpd /usr/local/vnc/classes -auth /home/nrm/.Xauthority -geometry 1280x1024 -depth 24 -rfbwait 120000 -rfbauth /home/nrm/passwd -rf bport 5901 Xvnc uses the ~/.vnc/xstartup shellscript, should you choose to test Xvnc. You can strip that down to "twm &" and "xterm &". thanks, Nigel.
Created attachment 139532 [details] Testcase OK, this shows the problem here...
Changing summary accordingly.
Summary: Hang from cmdline on <template> with <bindings> only → Attempt to open a 0x0 chrome window silently fails on Linux
Confirmed on Firefox PR1. Downgrading severity to major to get this off the user-features radar. - N.
Severity: critical → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 160281 [details] Test case with non-zero content Test case showing bug when <window> tag has child tags.
Created attachment 160283 [details] Test case in plain XML Also applies to plain (non-XUL) XML files. firefox -chrome file:///tmp/test.xml
You can't create zero-sized windows in X. It causes an X protocol error, iirc. http://lxr.mozilla.org/seamonkey/ident?i=AreBoundsSane
Created attachment 160431 [details] Test case in tag soup HTML Hmm. Boris said he got a 0x0 window in comment 4 and comment 7. Not safe to rely on the WM saving the situation. Even if X is restrictive there's still a hang to fix; still under-performance against Windows; and confusion for XPFEers and HTMLers. A remote XUL app with full security or a chrome app can also hang the client using this feature. Speculation: AreBoundsSane() could be a per-window state flag or a wrapper rather than just a check. Then the X call args could be math-fu'ed to 1x1 at the last instant. Or whenever the window is dynamically adjusted to dimensions 0x0. A corner case that wouldn't alter the state information the app stores about the window - just an adjustment of the wire protocol data. - N.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.