Barrett Lindstrom Reporter
	Description • 24 years ago

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).

	Barrett Lindstrom Reporter
	Comment 1 • 24 years ago

Updating QA contact

	Barrett Lindstrom Reporter
	Comment 2 • 24 years ago

Adding blocker

	Shannon Diener Assignee
	Comment 3 • 24 years ago

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

	Jim Dunn
	Comment 4 • 24 years ago

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

	Barrett Lindstrom Reporter
	Comment 5 • 24 years ago

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

	Barrett Lindstrom Reporter
	Comment 6 • 24 years ago

closing as invalid

	Shannon Diener Assignee
	Comment 7 • 24 years ago

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

	Shanjian Li
	Comment 8 • 24 years ago

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.

	Barrett Lindstrom Reporter
	Comment 9 • 24 years ago

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

	Shanjian Li
	Comment 10 • 24 years ago

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.

	Shanjian Li
	Comment 11 • 24 years ago

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

	Shanjian Li
	Comment 12 • 24 years ago

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. 

	Shanjian Li
	Comment 13 • 24 years ago

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.

	Shanjian Li
	Comment 14 • 24 years ago

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. 

	Shanjian Li
	Comment 15 • 24 years ago

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. 

	Shanjian Li
	Comment 17 • 24 years ago

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

	Jimmy Uen
	Comment 18 • 24 years ago

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.

	Shanjian Li
	Comment 19 • 24 years ago

That's what I need to know. thanks.

	Jim Dunn
	Comment 20 • 24 years ago

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

	Shanjian Li
	Comment 22 • 24 years ago

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

	Jimmy Uen
	Comment 23 • 24 years ago

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

	Shanjian Li
	Comment 24 • 24 years ago

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

	Barrett Lindstrom Reporter
	Comment 25 • 24 years ago

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.

	Shanjian Li
	Comment 26 • 24 years ago

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. 

	Jim Dunn
	Comment 27 • 24 years ago

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.

	Shannon Diener Assignee
	Comment 28 • 24 years ago

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

	Shannon Diener Assignee
	Comment 29 • 24 years ago

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

	Jim Dunn
	Comment 30 • 24 years ago

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

	Jim Dunn
	Comment 32 • 24 years ago

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.

	cls
	Comment 33 • 24 years ago

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?

	Stuart Parmenter
	Comment 34 • 24 years ago

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

	Jim Dunn
	Comment 35 • 24 years ago

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.

	Shannon Diener Assignee
	Comment 36 • 23 years ago

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

	Jim Dunn
	Comment 37 • 23 years ago

I am going to mark this as a dup of 83920.
tor@cs.brown.edu 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 ***

	Barrett Lindstrom Reporter
	Comment 38 • 23 years ago

Ok then.  Verified Duplicate.