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

NEW
Unassigned

Status

()

Core
XUL
--
major
15 years ago
9 years ago

People

(Reporter: Nigel McFarlane, Unassigned)

Tracking

Trunk
All
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
Created attachment 139390 [details]
topcrash.xul
(Reporter)

Comment 2

15 years ago
Created attachment 139391 [details]
test data - notetaker.rdf
(Reporter)

Comment 3

15 years ago
Created attachment 139392 [details]
test data - notetaker.rdf
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.
(Reporter)

Comment 5

15 years ago
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
(Reporter)

Comment 6

15 years ago
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.
(Reporter)

Comment 8

15 years ago
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...
Attachment #139390 - Attachment is obsolete: true
Attachment #139391 - Attachment is obsolete: true
Attachment #139392 - Attachment is obsolete: true
Changing summary accordingly.
Summary: Hang from cmdline on <template> with <bindings> only → Attempt to open a 0x0 chrome window silently fails on Linux
(Reporter)

Comment 11

14 years ago
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
(Reporter)

Comment 12

14 years ago
Created attachment 160281 [details]
Test case with non-zero content

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

Comment 13

14 years ago
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
(Reporter)

Comment 15

14 years ago
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.

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets

Updated

9 years ago
Assignee: hyatt → nobody
You need to log in before you can comment on or make changes to this bug.