Doesn't let go of the focus quickly




17 years ago
17 years ago


(Reporter: jxh, Assigned: joki)



Firefox Tracking Flags

(Not tracked)




17 years ago
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 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]

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

17 years ago
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, but I didn't have any problems
even when I tried their demo.

Comment 2

17 years ago
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

17 years ago
Virtually every page does this to some degree.  How about
"" ?  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

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

Comment 5

17 years ago
Confirming bug based on duplicate report.  Might library issue, since its been
observed on Solaris 8 and not on Solaris 7.
Ever confirmed: true

Comment 6

17 years ago
Having almost any page from the NY Times ( 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

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

Comment 8

17 years ago
wfm based on comment
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME


17 years ago
QA Contact: rakeshmishra → trix
You need to log in before you can comment on or make changes to this bug.