231408 - Attempt to open a 0x0 chrome window silently fails on Linux

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Nigel McFarlane]

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.

Comment 1

[Nigel McFarlane]

Attachment: topcrash.xul

Comment 2

[Nigel McFarlane]

Attachment: test data - notetaker.rdf

Comment 3

[Nigel McFarlane]

Attachment: test data - notetaker.rdf

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Nigel McFarlane]

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.

Comment 6

[Nigel McFarlane]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[Nigel McFarlane]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

OK, this shows the problem here...

Comment 10

[Boris Zbarsky [:bzbarsky]]

Changing summary accordingly.

Comment 11

[Nigel McFarlane]

Confirmed on Firefox PR1. Downgrading severity to major to
get this off the user-features radar.

- N.

Comment 12

[Nigel McFarlane]

Attachment: Test case with non-zero content

Test case showing bug when <window> tag has child tags.

Comment 13

[Nigel McFarlane]

Attachment: Test case in plain XML

Also applies to plain (non-XUL) XML files.

firefox -chrome file:///tmp/test.xml

Comment 14

[Christopher Blizzard (:blizzard)]

You can't create zero-sized windows in X.  It causes an X protocol error, iirc.

http://lxr.mozilla.org/seamonkey/ident?i=AreBoundsSane

Comment 15

[Nigel McFarlane]

Attachment: 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.

Comment 16

[Negritas Sergiu, Desktop QA]

Hello! I have tried to reproduce the issue with Firefox 96.0a1(2021-11-23) with the test case provided in comment 15 but unfortunately I wasn't able to reproduce it on Ubuntu 20.

Since no work has been done in the recent years I will mark this issue as RESOLVED->WORKSFORME. If the issue is still valid please feel free to reopen it or file another bug.