76699 - N6 is unresponsive on a freshly re-booted HPUX machine

Status: VERIFIED DUPLICATE of bug 83920

(SeaMonkey :: General, defect, P4)

Description

[Barrett Lindstrom]

Kind of a wierd one, but if you start up a trunk build on an HPUX box that was 
freshly re-booted, it will be completely unresponsive to any mouse use.  Buttons 
will not function, menus will not respond, and links will not be active.

STEPS TO REPRODUCE:
1.  Reboot your HPUX box.
2.  After the system is back, log in as yourself.
3.  Start up a trunk build.  

RESULTS:  N6 will be completly locked up.  You will have to CTRL-C at the 
terminal or close the browser using the window buttons.

In order to fix this, you will have to log out of the machine (NOT REBOOT!!!), 
and then log back in as yourself.  If you start a trunk build now, it will work 
as expected.

This was found on HPUX 11.00 on trunk build #2001041821 (and older builds too).

Comment 1

[Barrett Lindstrom]

Updating QA contact

Comment 2

[Barrett Lindstrom]

Adding blocker

Comment 3

[Shannon Diener]

yeah, I see it.  Not seeing this on linux.

Comment 4

[Jim Dunn]

This is what I am seeing here also, logging out and logging back fixes
my unresponsive problem.

Comment 5

[Barrett Lindstrom]

Ok, this doesn't happen to mozilla builds.  Closing this bug and creating one in 
bugscape.

Comment 6

[Barrett Lindstrom]

closing as invalid

Comment 7

[Shannon Diener]

I'm not seeing this problem with mozilla either but Jim still is, so I'm
reopening this one.

Comment 8

[Shanjian Li]

I trace the debug for a little while. It happens very consistently. 
When the browser is started, everything just seems fine. But after I 
direct the browser to a new website through url bar, the object associated
with event->any.window in widget/src/gtk/nsGtkEventHandler.cpp:805 
is null, and GDK_BUTTON_PRESS event can no long be routed to superwin. 
But the strange thing is, GDK_MOTION_NOTIFY (ie. Mouse Move) just works
fine. I will spend some time tomorrow to see if I can go any further.

Comment 9

[Barrett Lindstrom]

Strange.  For me, the browser is never just fine.  As soon as it is started, it
is locked completely up.

Comment 10

[Shanjian Li]

SIGTERM (15) could not be handled by browser correctly. That might be the cause of 
this problem. I am still struggling to find why it does not work the way as it should.

Comment 11

[Shanjian Li]

Please ignore my previous comment, it is for another bug.

Comment 12

[Shanjian Li]

I recorded all the windows created through gdk_window_new. They are within range of 4xxxxxx. 
After the first website(www.mozilla.org) is loaded correct, I load cn.yahoo.com. Everything
is displayed fine, but the button press event is sent to window 0x79xxxxxx. 

Comment 13

[Shanjian Li]

A little progress but still not clear about the preblem. The window value of xevent 
for the problematic button press event is 43, while normal one is 0x7xxxxxxx. The 
one return after gdk_window_lookup is not within normal range of a gdk window value.

Comment 14

[Shanjian Li]

The xwindow identified by 43 is root window. I do not understand why 
root window received the event instead of superwin. I need to read 
some X book to get some idea. 

Comment 15

[Shanjian Li]

Some new finding. The problem seems only happening with certain website. No matter that page is loaded 
first or not. cn.yahoo.com is a good test case. 

Comment 16

[Shanjian Li]

Attachment: minimum testcase

Comment 17

[Shanjian Li]

It seems to be that the embeded image caused the problem. I created a 
testcase. Barrett or jimmy, could you try it in campus?

Comment 18

[Jimmy Uen]

I'm not quite sure about what is the test case, but I downloaded your "minimum
testcase" attachment to some .html file and make the homepage to point to this
file. Rebooted my machine and ran N6, it locks up the browser.

Comment 19

[Shanjian Li]

That's what I need to know. thanks.

Comment 20

[Jim Dunn]

Now the question is...
if you take a simple testcase... and use that
does it NOT lock up the browser like this one does...

Comment 21

[Jim Dunn]

Attachment: simple htmlfile that shouldn't lock up computer based on shanjian's comments

Comment 22

[Shanjian Li]

In fact, if you remove the line which contains the embedded image, the problem 
will go away. That line make the difference.

Comment 23

[Jimmy Uen]

Tried jdunn's attachment and same thing happened, it locks up the browser too.

Comment 24

[Shanjian Li]

jdunn's simple html does not lock up my browser. I thought I finally 
narrowed the problem. Now it is still looks complicated.

Comment 25

[Barrett Lindstrom]

Ok, I've figured out what's going on here with the different behaviors.  Most of 
us have our home page set to http://home.netscape.com .  For those of us who 
have this set, we see the browser lock up immediatly.  If you have your home 
page set to blank, or to jdunn's html file, it does NOT lock up immediatly.  If 
you then go to http://home.netscape.com it will lock up as usual.  

I believe the lock up during activation is probably a different problem.

Comment 26

[Shanjian Li]

by using xwininfo, I checked the windows hierarchy. I also compared the one from my tracing 
result by breaking at gdk_window_new and those from Linux. It seems to me that the windows 
hierachy is incorrect in problematic page. 

Comment 27

[Jim Dunn]

my guess is that sometime last week a change went into some of
mozilla's gtk code and we are the only platform experiencing
problems from it.  While it is alot of tracking, I would suggest
finding out which day's checkins caused this and then look at
the checkins and fixing it that way.

Comment 28

[Shannon Diener]

This problem was introduced somewhere between 2/26/2001 and 3/30/2001 ... still
narrowing down ...

Comment 29

[Shannon Diener]

It looks like this is related to pavlov's checkin on 3/29 around 23:05 of an
imagelib fix for bug 73161.  This included the following files from
mozilla/gfx/src/gtk:  Makefile.in, XIE.c, drawers.h, nsImageGTK.cpp, and
nsImageGTK.h

Comment 30

[Jim Dunn]

Thanks to Shannon's detective work I traced this to linking and using
XIE.  If we don't build with XIE (config/autoconf.mk HAVE_XIE=1
and turn off the XIE_LIB line) then we run the first time.

Additionally if you set MOZ_DISABLE_XIE=1 in your env, you also get
past this problem.

Either the XIE changes aren't working correct, or they don't work correctly
on HP...  need further info.

So for now I suggest putting MOZ_DISABLE_XIE=1 in your env so you don't
hit this

Comment 31

[Jim Dunn]

Attachment: turn off HAVE_XIE for HPUX

Comment 32

[Jim Dunn]

cc'ing pav, syd & cls

Until we can figure this out, I want to turn off HAVE_XIE on hpux.
What I have found so far is that this is intermittent.  If mozilla
comes up pointing to certain websites (www.mozilla.org) the input
works, going to others (my.netscape.com) input doesn't work.

My guess it is an initialization thing along with a X timing issue.
I played around with XSync's and gdk_flush's but nothing seems to help.

Comment 33

[cls]

If I'm not mistaken, doesn't not having XIE mean that you must have gdk-pixbuf? 
Or does it just mean that you don't get image scaling?

Comment 34

[Stuart Parmenter]

we added scaling that works without XIE or gdkpixbuf...  r=pavlov i suppose on
the patch.

Comment 35

[Jim Dunn]

Looking at the code and at pav's comment it seems you don't need
XIE or pixbuf to do image scaling.  I will keep this bug open,
because I would like to see XIE working on hpux, it is just that
right now, we lock up on startup.

Comment 36

[Shannon Diener]

Setting priority for the radar. (for Rob who does not have permission to do so)

Comment 37

[Jim Dunn]

I am going to mark this as a dup of 83920.
[e-mail] checked in the code to
gfx/src/gtk to remove XIE so we should no
longer be bumping into this.



*** This bug has been marked as a duplicate of 83920 ***

Comment 38

[Barrett Lindstrom]

Ok then.  Verified Duplicate.