152723 - Doesn't let go of the focus quickly

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Jim Hickstein]

Mozilla on Solaris takes too long to let go of the X11 focus.  When using
move-pointer mode (not click-to-type), if you move the mouse pointer from
Mozilla into another X window -- say, an xterm -- Mozilla keeps the focus far
too long.

[Mozilla 1.1a (2002061401) binary build from www.mozilla.org. Also 1.0.  Solaris
8/SPARC Generic_108528-09, sun4u (Ultra-10).   /usr/openwin/bin/Xsun and
WindowMaker 0.65.1.  gtk+-1.2.10 from www.sunfreeware.com.]

It seems to pay some attention to the X event queue while it is rendering
certain pages, but no attention at all on others.  Certain pages containing
Javascript (e.g. those at www.paytrust.com) can hang the user hard for minutes
at a time.  Even while sitting idle, it can take a long time to let go of the
focus.  This is especially noticeable if you move the pointer into Mozilla then
out again quickly: the focus lags the pointer by ~500ms.

This feels to me like it arises from something fundamental in the design, which
means I'm _still_ shopping for a new browser.  And Mozilla seems so promising
otherwise.  Someone please tell me it doesn't have to be this way.

Comment 1

[Jim Crumley]

I can't confirm this bug.  With Sparc Solaris 7 Mozilla nightly build 2002061722
and Windowmaker 0.65.0 on a Ultra 10 with 1GB I didn't have any problems
changing focus with the focus setting "focus follows mouse" (I don't usually
have that setting). I tried www.paytrust.com, but I didn't have any problems
even when I tried their demo.

Comment 2

[Jim Crumley]

Please put your comments directly into the bugzilla url in this message, so that
the record is there for any developers who have to look at this bug.

> FWIW, I tried the Paytrust demo, too (even though I first saw the problem 
> with my actual account there), and it behaves about the same: While it's 
> painting the main page, the event queue is totally stuck.

Strange.  Have you seen this probem on any other specific site?

> Do you suppose this could be a GTK thing?

My gtk 1.2.10 that I built myself.  It could be a gtk thing - I have no clue.

> Are you on Solaris 8 using the Sol 7 build?  Or are you using Sol 7?

Sorry, I was unclear.  I have Solaris 7, but actually the nightly build is a
Solaris 2.6 build.  I also just tried with my own personal build of Mozilla 1.0
and I don't see the problem with that either. I see no noticeable focus lag.

Comment 3

[Jim Hickstein]

Virtually every page does this to some degree.  How about
"http://bugzilla.mozilla.org/show_bug.cgi?id=152723" ?  While it was painting
this page, the focus wouldn't go out or in, for many seconds.  I could scroll
within the content area (for a while), then move the mouse to an xterm (no focus
change), then come back and scroll some more.  Very odd.  After a little while
doing that, it wouldn't scroll, either (or refresh anything).  After about a
minute, it woke up and the focus moved, and the xterm raised (?).  Then it was OK.

I've got half a dozen tabs open (maybe it's a tab thing), though none of them
are terribly complex.  (No Paytrust at the moment.)

Just sitting here idle, I can still get the 500ms lag if I move the pointer in
then out very quickly.  With this many tabs open, it's more like 1000ms now.

Comment 4

[Jim Crumley]

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

Comment 5

[Jim Crumley]

Confirming bug based on duplicate report.  Might library issue, since its been
observed on Solaris 8 and not on Solaris 7.

Comment 6

[Benn Oshrin]

Having almost any page from the NY Times (www.nytimes.com) open in one of the
tabs is also a good way to exacerbate the problem.  (At least through build
2002062222, Solaris 8, WindowMaker 0.65.0 or 0.80.0.)

truss shows several SIGALRMs interrupting calls during lockout:

 ioctl(6, FIONREAD, 0xFFBEEAEC)                  = 0
     Received signal #14, SIGALRM, in lwp_sema_wait() [caught]
 lwp_sema_wait(0xFEAEFA10)                       Err#91 ERESTART

Comment 7

[Benn Oshrin]

I downloaded 2002100122 this morning (the last update I downloaded was
2002081222), and the problem seems to now be resolved.

Comment 8

[Jim Crumley]

wfm based on comment