118914 - Browser crashes on startup on monocrome-only Xservers

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX: Gtk, defect)

Description

[Christopher Allen]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122108

When starting Mozilla (configured to open a browser window on startup), it
crashes if $DISPLAY points at an NCD 15r (black and white, 1024x768) X Terminal.

Sometimes I am able to see some of the chrome drawn before the window closes;
other times, the window closes too quickly to observe anything being drawn in it.

Nothing is printed on standard output or standard error.




Reproducible: Always
Steps to Reproduce:
1. Log in on X Terminal
2. $ mozilla
3. Wait for window to open

Actual Results:  Window immediately closes; mozilla exits without error message

Expected Results:  Browser should remain open and be usable

My window manager is twm.

I suspect either a colour depth or font-related problem.

- Mozilla ought to work in black and white, even if it doesn't look too pretty.

- The fonts available on the display server are different than the fonts
provided by X as installed on the client host.

- The behaviour is identical when I tried using an NCD 19r X terminal (same
server software / fonts, just a 1280x1024 screen)

I tested mozilla 0.9, which crashes in the same way.

Comment 1

[Christopher Allen]

My initial assertion that no error messages appear on std{out,err} seems to be
wrong.  Re-testing on an NCD 19r, I go tthe following error messages (repeated
five times, as shown):

------------------------------------------------------------------------------

Gtk-CRITICAL **: file gtkwidget.c: line 2728 (gtk_widget_event): assertion
`GTK_IS_WIDGET (widget)' failed.

Gtk-CRITICAL **: file gtkwidget.c: line 2728 (gtk_widget_event): assertion
`GTK_IS_WIDGET (widget)' failed.

Gtk-CRITICAL **: file gtkwidget.c: line 2728 (gtk_widget_event): assertion
`GTK_IS_WIDGET (widget)' failed.

Gtk-CRITICAL **: file gtkwidget.c: line 2728 (gtk_widget_event): assertion
`GTK_IS_WIDGET (widget)' failed.

Gtk-CRITICAL **: file gtkwidget.c: line 2728 (gtk_widget_event): assertion
`GTK_IS_WIDGET (widget)' failed.
------------------------------------------------------------------------------

Comment 2

[Doron Rosenberg (IBM)]

cc:gisburn, who might have an idea

Comment 3

[Roland Mainz]

Raw guessing - I assume that libGDK/GTK+ goes nuts for some reason... ;-(

Reporter:
Can you please attach the following program outputs:
- Output of "xdpyinfo"
- Output of "xlsfonts"
(Please attach the outputs as _files_ to this bug (e.g. click on
http://bugzilla.mozilla.org/attachment.cgi?bugid=118914&action=enter for each
output file and create a new attachment for this bug...))

Reporter:
Are you building your Zilla yourself ? If yes: Can you please pull a up-to-date
source and build it with "./configure --enable-toolkit=xlib; gmake", please ?
Mozilla's Xlib port has some has some additional diag code and test options for
such cases...

Comment 4

[Christopher Allen]

Attachment: Output of xdpyinfo on one of several displays which cause mozilla to crash

This is the output from xdpyinfo for my NCD 15r (1024x800x1 X
Terminal)

Comment 5

[Christopher Allen]

Attachment: Output of xlsfonts for same display

Just in case it's a font-related problem (because Mozilla is claimed
to work on 1-bit displays), here's the list of fonts that the display
has.  (That's the only other thing I can think of off the top of my
head.  Mozilla certainly works fine when using another Linux box as a
display, so it's not just a local vs. remote problem.)

Comment 6

[Roland Mainz]

Oh... that's easy.
Per xdpyinfo output (attachment 66243 [details]) these are Xterminals with monocrome
visuals (StaticGray, 1bit). AFAIK GDK/GTK+ do not support such visuals - and
because Mozilla's default build is GDK/GTK+-based Mozilla has problems with
this, too... ;-(

However, you may try the Xlib port which may work (if not I can fix it...) ...

Comment 7

[Christopher Allen]

I will attempt to try the Xlib build as you suggest.

Should this bug be marked 4xp (or whatever it is)?  Because Netscape
4.x definitely worked[1] without crashing on both the terminals I've
tested Mozilla on, and it would be nice if this feature wasn't lost!


[1] For definitions of 'worked' which include rendering images in the
negative, because 4.x didn't bother to query the display to see if
1=black/0=white or 0=black/1=white, and NCDs apparently use the
opposite of whatever the 4.x authors tested on.  But in any case, it
didn't crash.  Well, not on startup, anyway, and no more than it did
on a colour terminal!

Comment 8

[Roland Mainz]

Reporter:
Any test results ?

Comment 9

[Greg K.]

Adding 4xp per comment #7.

Comment 10

[Torben]

This bug is old. Christopher, can you please check with a recent build?

Comment 11

[Christopher Allen]

As I no longer have access to my monochrome X server - it's in a box in a
basement on the other side of the Atlantic - and I can't seem to persuade
XFree86 to run in 1bpp mode on my iBook, I can't actually verify that this bug
hasn't been fixed.  (Nor can I verify that the Xlib port works, unfortunately!)


I do suspect that it might be a GTK/GDK problem, though, as I started having
trouble with various other programs (including notably XMMS) on that terminal at
around the same time this bug appeared.

Anyone else have a monochrome X server they can test on?

Comment 12

[Pontus Freyhult]

It is still broken - with latest-trunk I get

pont@machia:/space/1/moz/dl/mozilla$ ./run-mozilla.sh 
Gdk-ERROR **: BadValue (integer parameter out of range for operation)
  serial 519 error_code 2 request_code 72 minor_code 0
pont@machia:/space/1/moz/dl/mozilla$ 

It certainly seems possible to support monochrome screens with Gtk, 
although a lot of programs function badly with them. I intended to have 
a go at fixing this myself (for Gtk-2), but I can't 
build from CVS on my debian box, gcc (both 2.95 and 3.2) fails (as 
in "either gcc is buggy or the hardware is broken").

If I can get a pre-built (linux x86) Xlib-build somewhere, I can check 
whatever that works (I'll try to build it myself but guess that won't work either).

Comment 13

[Torben]

Maybe related to bug 104550?

Comment 14

[Pontus Freyhult]

I can now verify that the xlib port works (as suggested in comment 6) on my 1
plane/StaticGray display.

Comment 15

[Henri Sivonen (:hsivonen)]

*** Bug 199166 has been marked as a duplicate of this bug. ***

Comment 16

[unglorious]

Attachment: Stack trace of core file.

I'm setting up of a monocrhome NCD19 X terminal and found this old bug after
mozilla kept crashing on startup.  I rebuilt using
--enable-default-toolkit=xlib based on the information here.  That build opened
successfully on the X terminal with some oddities:  some graphical elements
were corrupted, the Home/Bookmarks line did not contain the three other buttons
normally seen, the bookmarks menu contained no bookmarks.

When I opened a link in a new window, the new window appeared briefly then
mozilla crashed.  I've attached the stack trace from the resulting core file.

Comment 17

[Andrew Schultz]

unglorious: please file a new bug on component GFX:Gtk for what you're seeing.

dumping this in gtk since that's where the originally reported bug is.

Comment 18

[Andrew Schultz]

(In reply to comment #17)
> unglorious: please file a new bug on component GFX:Gtk for what you're seeing.

ugh.  I meant GFX: xlib

Comment 19

[Mats Palmgren (inactive)]

gfx/src/gtk/ has been removed on trunk.
Is this bug reproducible in a recent (cairo) trunk build?

Comment 20

[Mats Palmgren (inactive)]

-> WORKSFORME