105776 - Unix build instructions contain references to mozilla-viewer.sh, etc.

Status: RESOLVED FIXED

(mozilla.org :: Miscellaneous, task)

Description

[Vince McIntyre]

To reproduce:
-------------
I just built mozilla-0.9.5 from source
 gmake -f client.mk
on solaris 2.6, with gtk-1.2.10
I did no manual configurations.

I start the 'viewer' like this:
cd dist/bin; ./run-mozilla.sh

Example 0 page appears & is correctly rendered.
Clicking on the forward button does nothing.
I move forward via File->Samples, to example1.
Back button works ok.
After moving back, Forward button works, but only to Example 1,
I can't use it to get to Example2.


Related detail:
----------------
The righthand part of the window renders poorly:
The menubar is ok as far right as Tools, the rest is not drawn.
The back/forward buttons and uri entry widget appear, but the dropdown
widget (looks like a light-grey triangle) doesn't get drawn.
The cursor changes shape to a hand with finger extended though.

At startup there is some beeping and this stuff appears:
MOZILLA_FIVE_HOME=.
  LD_LIBRARY_PATH=.:./plugins:/nfs/aips++/release-1_5/sun4sol_gnu/lib:/usr/local
/lib:/usr/openwin/lib:/usr/local/X11/lib:/usr/dt/lib:/opt/SUNWspro/lib:/usr/loca
l/gnu/lib:/usr/local/lib:/usr/lib:/usr/ucblib
     LIBRARY_PATH=.:./components
       SHLIB_PATH=.
          LIBPATH=.
       ADDON_PATH=.
      MOZ_PROGRAM=./viewer
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
nNCL: registering deferred (0)
Type Manifest File: /DATA/MAYHEM_2/vmcintyr/mozilla/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
Going to create the event queue
GFX: dpi=88 t2p=0.0625 p2t=16 depth=8
WEBSHELL+ = 1
nsPluginHostImpl ctor
********** Got plugins path: /DATA/MAYHEM_2/vmcintyr/mozilla/dist/bin/./plugins
IsPluginFile(/DATA/MAYHEM_2/vmcintyr/mozilla/modules/plugin/samples/default/unix
/libnullplugin.so) == TRUE
LoadPlugin() /DATA/MAYHEM_2/vmcintyr/mozilla/modules/plugin/samples/default/unix
/libnullplugin.so returned 216390
GetMIMEDescription() returned "*:.*:All types"
Start reading in bookmarks.html
###!!! ASSERTION: failed to create encoder: '0', file nsUNIXCharset.cpp, line 40
7
###!!! Break: at file nsUNIXCharset.cpp, line 407
###!!! ASSERTION: unable to use nl_langinfo(CODESET): '0', file nsUNIXCharset.cp
p, line 331

Comment 1

[Vince McIntyre]

OOPS.
The run-mozilla GUI is unfamiliar to be and I was unsure what the forward/back
buttons were for. They appear to move me through the URI history correctly.

The comments on the mis-drawing still stand however.
I've changed the bug as 
 Summary: run-mozilla.sh mis-drawing part of GUI in Solaris.
 Severity: minor
Or tried to. hope this works...

Comment 2

[R.K.Aa.]

run-mozilla is just a shell-script to invoke Mozilla with.
The binary product is normally referred to as Mozilla.
Thus, it isn't "run-mozilla.sh" that failes, but Mozilla.
"run-mozilla.sh" has no GUI. Mozilla does.

You say the dropdown widget isn't drawn, yet you refer to it as a "light grey
triangle". Does this mean you actually do see the arrow in the GUI, but that the
dropdown triggered by clicking it fails?

Is this something you see (or not see) in both themes? (classic and modern)

Comment 3

[R.K.Aa.]

oh.. one more thing: Can you try starting Mozilla by using the mozilla script
instead - simply by cd'ing to dist/bin and writing ./mozilla &
Does the same bug appear then?

Comment 4

[R.K.Aa.]

Got private e-mail from reporter:
--
> run-mozilla is just a shell-script to invoke Mozilla with.
> The binary product is normally referred to as Mozilla.
> Thus, it isn't "run-mozilla.sh" that failes, but Mozilla.
> "run-mozilla.sh" has no GUI. Mozilla does.

Closer inspection reveals this script starts up the 'viewer' gui.
It looks quite different to what appears when I do this:
 cd dist/bin; ./mozilla

For one thing there's the misdrawing.
For the other thing, the front/back buttons are also twice the size they
are in mozilla, there's no reload/search/print or logo.
And the bar across the bottom of the window is different too: no
nav/mail/composer icons, and the pane is white, with a status line in it.
I assume this is some kind of xpcom test rig, not the lizard herself?



> You say the dropdown widget isn't drawn, yet you refer to it as a "light grey
> triangle". Does this mean you actually do see the arrow in the GUI, but that
> the dropdown triggered by clicking it fails?

Sorry. I was inferring that is what I guessed it would look like, if it were
drawn. Let's back up.
The white url field is drawn correctly.
Whatever is supposed to appear to the right of that is not being drawn.
When I position the cursor in this area the cursor shape changes from an arrow
to a hand-pointing-left. Starting mozilla up, this happens when I put the
cursor over the mozilla logo. So it appears it's the logo that is not drawn.
Also the panel above the url field is not drawn correctly - nothing is drawn.
Possibly this is deliberate, if viewer is a test rig only...


> Is this something you see (or not see) in both themes? (classic and modern)

Trying... viewer doesn't show a menu item that lets me change themes,
when I invoke it with run-mozilla.sh



>can yo reproduce with ./mozilla?

no.
If I run mozilla, the Open File dialog opens with a pipe (|) cursor
positioned in the file name field, before I do anything. I can type in it
immediately. This works with the classic theme and the modern theme.

The reason I was defecting 'viewer' is that the instructions at
  www.mozilla.org/build/unix-details.html
say I should run mozilla-viewer.sh after I have built.
They also mention mozilla-aprunner.sh, which doesn't seem to exist
in dist/bin. There is such a script in xpfe/bootstrap.
Perhaps it only gets built/softlinked for some OS's?

I ran mozilla-viewer.sh and run-mozilla.sh to compare.
They both invoke 'viewer' and the UI looks the same; misdrawn in the same way.
'diff' says the scripts differ, it appears to be something to do with debug
environment variables.

The can't_type_in_filename_field_of_Open_File_dialog problem still occurs,
for either invocation.

If 'viewer' is just a debug tool then perhaps this bug can be left aside
in favour of getting mozilla licked into shape.
For example - either invocation of viewer, and even mozilla itself,
crash when I try to load the infamous example4 file attached to bugid=104550.

The web page mentioned above seems to need patching, but I'm unable to suggest
a patch without knowing what the viewer is for.

Comment 5

[Jim Crumley]

> The reason I was defecting 'viewer' is that the instructions at
>   www.mozilla.org/build/unix-details.html
> say I should run mozilla-viewer.sh after I have built.

This seems like a bug in the the web site. My understanding is that viewer and
the shell scripts you mention are just for testing mozilla's rendering engine. 
I don't think they should be mentioned in the build directions anymore.  The
average user only needs to run dist/bin/mozilla, so I think that should be
mentioned instead.

Setting Product to mozilla.org, confirming bug, CCing write of unix-details.html
[e-mail].  I'll attach a patch for this page in a moment.

Comment 6

[Jim Crumley]

Attachment: Patch to uniz-details web page to remove references to viewer, etc.

Comment 7

[Asa Dotzler [:asa]]

leaf, with your permission I'll make this change. What say you?

Comment 8

[Daniel Wang]

looks like somebody already checked the patch in -> fixed