Closed Bug 78928 Opened 23 years ago Closed 11 years ago

twm or no wm: Cannot type into dialog text fields [gtk1 builds only]

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: terra, Assigned: blizzard)

References

(Blocks 2 open bugs)

Details

(Keywords: relnote)

Attachments

(1 file)

workaround patch to twm
642 bytes, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS 5.8 sun4u; en-US; rv:0.9+) Gecko/20010503
BuildID:    2001050322

For some time I have been unable to type into text fields
in the preferences dialog.  I am sometimes able to get by
using mouse cut-and-paste.

The text cursor never shows in the text fields, when I
click in them.  I can double-click and thus select
existing text in there.  (That still does not give me 
any cursor, but I would not expect that.)

Text fields in (say) forms work fine for me.


Reproducible: Always
Steps to Reproduce:
1. Open preferences.
2. Select advanced->proxies->manual.
3. click in ftp proxy text field.
4. Type "xyz".


Actual Results:  Nothing appears in text field.


Expected Results:  Expected "xyz".
this works for me on Mac

Works for me on Linux.
Is it just the prefs dialog?  What about other dialogs, or the browser window
itself?
Summary: Cannot type into preference text fields → Solaris: Cannot type into preference text fields
forms on pages: ok
url in toolbar: ok
preferences: not ok
search dialog: not ok
open file dialog: not ok

I have had this problem for a few months.  I realise that most people do
not see it, or there would have been a zillion bugs files on it.

More information, possibly irrelevant:

window manager: twm
os versions: Solaris 2.7 and Solaris 2.8
X modifiers active: none (no caps, no scroll lock, no num lock, no compose)

Anything else?


Sounds like something is up with dialogs, marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I too am using the TWM window manager under X, on Linux.  
I could not get a text cursor or type text into any dialog text boxes (find,
etc.) until I told TWM to decorate transient windows (like dialogs).  In other
words I set the DecorateTransients variable in .twmrc.  Without this setting TWM
does not add a title bar or other decorations to transient windows.  With this
setting I get a text cursor in the text boxes and can enter text.
moving over to linux so that we can get more help.
resummarizing
OS: Solaris → Linux
Hardware: Sun → PC
Summary: Solaris: Cannot type into preference text fields → twm: Cannot type into dialog text fields
To reproduce:

+ If twm is not installed, install it.

+ In your home directory, create an empty file named .twmrc.

+ Create a file named xtwm containing

twm &
exec xterm

+ Start X with the command

  xinit ~/xtwm

  Point and click to position the xterm window.

+ In xterm, start mozilla, e.g.

  ~/mozilla/mozilla

  Point and click to position the mozilla window.

+ From the Search menu, choose Find.

  The Find dialog appears.

+ Try to focus and enter text in the Find dialog.

  You can't.  Though you can copy and paste text into it.
  Even then, the find button is not activated.

+ Repeat the experiment with a single line in ~/.twmrc:

DecorateTransients

  Now you can enter text in Mozilla dialog text fields.


A similar experiment with fvwm2 did not show the problem.
In other words, even without transient window decoration,
you can enter text into dialog text fields normally.

Still occurs with Mozilla/5.0 (X11; U; Linux 2.2.17-8 i686; en-US; rv:0.9+)
Gecko/20010518.

Suggest changing component to "XP Toolkit/Widgets".
adding blizzard, pavlov for some X11 help

This might actually be a gtk bug.  Also, it might be fixed since I checked in
some focus related fixes in the last few days.  The reporter and anyone who can
reproduce it should try it with a build from, say, today.
Bug still occurs with Mozilla/5.0 (X11; U; Linux 2.2.17-8 i686; en-US; rv:0.9+)
Gecko/20010518.
I tried an 05-19-09 nightly and it appears to work. When mozilla starts,
you can see a cursor in the location field. However, a couple of times
the system got wedged so I couldn't switch away from the mozilla window,
even with the mouse. I don't know if it's a mozilla bug, or twm, or the
fact that I was using xwd to take screenshots.

I don't think it's a gtk bug. I've always been able to use Gimp, or any
other gtk app, with twm or any other window manager without problem.
Only mozilla failed.
I still see the problem in 2001052022.

An extra tidbit of information: the affected windows all appear at the top
left corner.   Demonstrating my X ignorance, I would say that this suggests
that the windows are not parented at twm wants them to be.

Still occurs in Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; rv:0.9+)
Gecko/20010521
toolkit, over to trudelle to find an owner.  Adding myself to cc list.
Assignee: mcafee → trudelle
Component: Preferences → XP Toolkit/Widgets
QA Contact: sairuh → jrgm
->danm
Assignee: trudelle → danm
*** Bug 71920 has been marked as a duplicate of this bug. ***
Can anyone arrange for priority and target assignment, please?  And perhaps
this should be released-noted -- having prefs and search not work is a bit
unexpected.
Release notes are available - created for Bug 71920, though that does mention
VTWM as the problem window manager.
  I can see this problem if I hobble my machine in the manner described above by 
David. But man it's a lot of trouble. Anything normal (switch to twm while 
already running or egad, just xinit using the default startup script) doesn't 
show the bug. Here's where I demonstrate my own ignorance of X. But my reading of 
this bug is, if I go to the trouble of improperly initializing X and then run 
Mozilla under twm, it doesn't quite work. (Note it does work under, for example, 
sawfish.)
  Oy. Alright, it's a bug. Whether the bug is in Mozilla or twm is a useful 
question. Could be that under such circumstances the window manager isn't sending 
us the sequence of window activation messages we expect. Or something. This bug 
slips thoroughly under my radar, into the "future/helpwanted" bin. Any real X-
heads out there interested in tracking this down, do please chime in.
Keywords: helpwanted
Target Milestone: --- → Future
we could assign to nobody@mozilla.org, agreed this is an edge case
now that it's 2001 and not 1987.

ooo. never done that before. it might get more attention there. off it goes.
Assignee: danm → nobody
Keywords: helpwanted
Target Milestone: Future → ---
If this is truely the same problem as Bug 71920 then it occurs without needing
to make unusual changes to X setup. However I also agree that this is a minor
problem given the easy work-around (now that it's 2001 and not 1998  :)

Perhaps an update to the release notes changing "VTWM" into "TWM and descendants"?

As for the positioning of windows - the "what to do with mime type X", file
download progress and composer table editing windows appear in the correct
location, ie. not top-left corner, but still don't get text focus when not
docorated.
Minor correction:  Danm says, "But my reading of this bug is, if I go to the
trouble of improperly initializing X and then run Mozilla under twm, it doesn't
quite work."  The test case above is just the simplest possible way to start X
and demonstrate the bug.  I don't think it is improperly initializing X.  It is
using the maximum number of defaults with the window manager that is shipped in
the core X Consortium distribution.  In other words, X in its most native form.

Having got that off my chest, I'll go along with the opinion that this is not
the most pressing problem on anybody's plate, given an easy workaround.  If I
ever find time, I'll look into it myself.  Hey, that's it, assign it to me! 
It'd make me feel so important!
David Olsson--I'm happy to help (and reassign this bug); please reassign back to 
nobody@mozilla.org if you decide you aren't interested in working on this bug 
after all.
Assignee: nobody → dolsson
(accepted assignment) I'll be away until September, and I'll be slow even then,
but as long as nobody is in a big hurry I'd love to explore this.
Status: NEW → ASSIGNED
dolivari says this also happens for the no-Window Manager case,
e.g. full screen mode.
Summary: twm: Cannot type into dialog text fields → twm or no wm: Cannot type into dialog text fields
check the http://bugzilla.mozilla.org/show_bug.cgi?id=91446 for testcase about
focus problem and fullscreen might be the same bug


*** Bug 93565 has been marked as a duplicate of this bug. ***
*** Bug 93587 has been marked as a duplicate of this bug. ***
*** Bug 93637 has been marked as a duplicate of this bug. ***
The bug I submitted does seem to be a duplicate of this bug, however, I have
always had DecorateTransients enabled in my .twmrc.  That does NOT fix the
problem for me (using the build listed in my bug #93587).
jatin: there are ~4 open bugs about this issue, and i couldn't find it in the 
current release notes.  My current advice would be to _use_ a window manager 
that is not a twm derivative.  -- please add this to the 093 relnotes there 
have been too many recent filings.
Keywords: relnote
is this the same as 

bug 73727 or
bug 76854 maybe?


Asa: yes, although those have titles that fail to mention twm.

(This "yes" assumes that the twm and no-wm cases are really the same.)

*** Bug 92445 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
Does this still need to be in the 0.9.3 and RTM release notes? If so, please add
a comment to the tracking bug (Bug 90577) with a one line description of the bug
and the workaround. 


I added description and workaround text to the release notes tracking bug.  Here
is a copy:

Bug 78928:

One-line description:

You may not be able to type in dialog box text fields if
you are running X Windows with (a) no window manager or (b) a window
manager from the twm family without the DecorateTransients option.

Workaround:

Run a window manager.  If using a window manager from the twm family,
set the DecorateTransients option in the window manager's rc file.

Some additional information:

If you are running twm and have NoTitleFocus set, or are running without
a WM, then mozilla will also ignore keyboard events in the main browser
window.  (In particular, you won't be able to type into html forms, and
keyboard shortcuts such as Ctrl-Q won't work.)

*** Bug 100306 has been marked as a duplicate of this bug. ***
Blocks: 76854
Still occurs with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011027.

More information:

Fire up mozilla, choose Search/Find in This Page.

In an xterm, run xwininfo, then click on the Find dialog window.
Note the window id, in hex.

In the xterm, run

   xev -id 0xblahblah

substituting the window id of the Find dialog.

Now move the mouse in and out of the Find dialog window.
Note events.

With twm,

DecorateTransients    -->  FocusIn, KeymapNotify, EnterNotify
                           LeaveNotify, FocusOut

no DecorateTransients -->  EnterNotify, KeymapNotify
                           LeaveNotify

DecorateTransients
    *and*
NoTitleFocus          -->  EnterNotify, KeymapNotify
                           LeaveNotify

I suspect the no-window-manager and other cases are similar, in that the window
is getting enter and leave events but not focus in and out events, and that is
where Mozilla dialogs (and with NoTitleFocus, even Mozilla's main window) fail
to get keyboard focus in text controls.  Note that most other apps work under
these conditions.
*** Bug 108006 has been marked as a duplicate of this bug. ***
If you add NoTitleFocus to your .twmrc, it makes it much worse: you cannot even
type in a url.
Please note the cousin of this bug: bug 76854

*** Bug 114273 has been marked as a duplicate of this bug. ***
*** Bug 129413 has been marked as a duplicate of this bug. ***
*** Bug 125290 has been marked as a duplicate of this bug. ***
*** Bug 138033 has been marked as a duplicate of this bug. ***
Blocks: keydead
The patch that Chris Blizzard attached to bug #76854 is meant to fix this bug as
well.  Please, anyone who can, try the patch and report findings.
This bug is still present in rc2 (we're using twm).
comment #50
> Please, anyone who can, try the patch and report findings

Can someone perhaps create a test build with the fix so that we can test
the fix?  Perhaps someone can verify it does not *break* anything and it
can be checked in so it can be tested in a nightly build?
*** Bug 145395 has been marked as a duplicate of this bug. ***
I'm not seeing any time to work on this.  Since it's the same as bug #76854, I'm
handing this to you, Chris Blizzard.  If that's inappropriate, curse me and
reassign it appropriately.
Assignee: dolsson → blizzard
Status: ASSIGNED → NEW
*** Bug 148615 has been marked as a duplicate of this bug. ***
*** Bug 157732 has been marked as a duplicate of this bug. ***
*** Bug 157732 has been marked as a duplicate of this bug. ***
*** Bug 165011 has been marked as a duplicate of this bug. ***
*** Bug 165013 has been marked as a duplicate of this bug. ***
*** Bug 175571 has been marked as a duplicate of this bug. ***
I would just like to clarify that this has never worked for me (from early
testing to 1.2beta), but I have never tried with DecorateTransients (I am
running the twm from XFree 4.2 on Linux/x86). As this is still obviously
troubling people; perhaps there is some way for Mozilla to work around this?
*** Bug 177582 has been marked as a duplicate of this bug. ***
*** Bug 181209 has been marked as a duplicate of this bug. ***
Blocks: 187935
*** Bug 192788 has been marked as a duplicate of this bug. ***
*** Bug 197126 has been marked as a duplicate of this bug. ***
As of version 1.4a, the problem with TWM window manager is still present.
*** Bug 204595 has been marked as a duplicate of this bug. ***
*** Bug 210280 has been marked as a duplicate of this bug. ***
This also occurs for me. I can usually type into the URL box for a little while 
and then randomly it just stops accepting focus. It's extremely annoying not 
being able to type new URLs. I have to create a new window and then I can 
usually type into the URL field. Sometimes I have to create two or three 
windows before I get one that works. Even then it only works for a one or two 
URLs before it stops. 
 
It seems using drop-down menus or other widgets that grab the mouse are more 
apt to trigger it. Also, when i run under xmon it seems to trigger the bug much 
faster, usually after only a couple keystrokes in the URL field. 
 
This leads me to believe it's a race condition. Somehow xmon slowing down the 
events makes the problem more likely. My hunch is that some toolkit code is 
using X as if it were synchronous, grabbing the keyboard in response to an 
event (drop-downs for example) and then getting confused if it loses focus 
before the grab is acknowledged. Or something like that. 
 
I have NoTitleFocus disabled because it was alleged to fix the problem but it 
hasn't helped for me. Perhaps because I have titlebars themselves disabled as 
well. I'm not about to turn them on and change my whole desktop for one broken 
application. 
I believe gsstark is describing a separate bug that I've also seen, though only
on one system.  If you are unable to type in a regular Mozilla window (for
example, to submit a form), then I find that if you click on the background of
the page so that the focus is no longer in a text entry box, iconify the
browser, then deiconify it, it works fine.

The system having problems is running Gentoo, and I was using the pentium4
optimizations which are known to cause problems.  This is totally separate from
the twm (or no window manager) bug.
I have no idea what you mean by saying it's a different bug, the symptoms 
certainly match exactly.  
 
It does seem that if I tap my toes and spin around three times the way you 
described it does indeed appear to fix the problem at least for a moment. I'm 
certainly happy to have a better work-around than the "keep opening windows 
until one works" technique. 
 
However this is the first time anybody's suggested this dance, and none of the 
other people on this bug have mentioned trying it. It would be interesting to 
know if it helps everyone or only some people, though I don't see how it brings 
us any closer to fixing the bug. 
 
Do the mozilla developers who have looked at this believe it's a gtk toolkit 
bug? Have they inquired at gtk-app-devel-list@gnome.org or 
gtk-devel-list@gnome.org to see what they think? 
I've seen this problem in Mozilla 1.2-1.4 compiled from NetBSD's (1.5.x) and
1.6.x pkgsrc on SPARC and Alpha. (Using TWM from the NetBSD-supplied X installation)

I've also just found the bug manifests with MozillaFirebird (binary supplied by
mozilla.org) on Solaris 9.

 I've also seen the bug on FreeBSD 4.8 (Intel), with Mozilla 1.4.

 TMW is still a fairly popular web browser.  I have been using it for 10+ years,
it does everything i need and i have no intention of changing.

Thanks for the workaround suggestion ("DecorateTransients") is does solve the
problem for me, but it's an obscure option and not on by default, so many TWM
users are bound to be stymied and give up on Mozilla when they discover that the
"Find" dialogue does not work.
Blocks: 216199
this bug is also present running mozilla in afterstep, on a solaris 9 box with all 
appropriate patches, the right jre, etc etc.

i dont suppose there is any sort of workaround for afterstep users? (similar to the one for 
TWM. maybe it's just my ignorance but i couldn't find an analog to the 
DecorateTransients parameter)
There are two related bugs: the first is is that you can't type in temporary
dialogs.  I first ran into this quite a while ago using twm on FreeBSD.
Switching to ctwm fixed that, but with the most recent versions of Mozilla
there is a new problem: some of the time I cannot type in form, or on the
URL line.  This is true for twm, ctwm, and tvtwm.  

I'm sure this could be fixed in *twm instead, but none of the twm's seem to
actively developed.

Still occurs in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4 Gecko/20030821 
 
Mozilla-RPM: V. 1.4-72 
HW: Pentium 4 /Compaq Evo610n Notebook, 
OS: SuSE 9 professional; Kernel 2.4-21 
WM: KDE 3.1.4 
 
I can't get the Browser to accept any input by the using the keyboard, neither 
in any dialog nor in the address field, unless I performed some really strange  
selections using the mouse. This can't even be considered as a workaround.  
  
Any ideas how to proceed? 
 
Still occurs in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4 Gecko/20030821 
 
Mozilla-RPM: V. 1.4-72 
HW: Pentium 4 /Compaq Evo610n Notebook, 
OS: SuSE 9 professional; Kernel 2.4-21 
WM: KDE 3.1.4 
 
I can't get the Browser to accept any input by the using the keyboard, neither 
in any dialog nor in the address field, unless I performed some really strange  
selections using the mouse. This can't even be considered as a workaround.  
  
Any ideas how to proceed? 
 
*** Bug 237445 has been marked as a duplicate of this bug. ***
(In reply to comment #76)
> I can't get the Browser to accept any input by the using the keyboard, neither 
> in any dialog nor in the address field, unless I performed some really strange  
> selections using the mouse. This can't even be considered as a workaround.  
> Any ideas how to proceed? 

The latest Mozilla (1.7a) will not accept any keyboard text at all, in any
windows, boxes, or dialogs, unless you are running *some* window manager.

Some window managers misbehave, even at that.  I run vtwm and found
that eventually Mozilla 1.5 stopped accepting any keyboard text input.
By random chance I found that if I go to the main browser web page window,
select some displayed text with the mouse, then click on the selected
text and drag it a few pixels and drop it (doing apparently nothing),
it un-jams the interface and I can again enter text, until some future
point where it jams up again.  I haven't experimented enough with 1.7a
yet to know how it behaves.

When Mozilla locked up and not accepting text, it also misbehaves with 
mouse selections in menus, often ignoring the menus, requiring double
clicks to open the menus, or refusing to leave the menus up when I try
to drag my mouse into them.  The above "trick" un-jams the menus also,
for a limited period of time. 

I think this new Mozilla behaviour is wrong; X11 applications should not
start depending on the existence of a window manager, or on a particular
type of window manager, to accept keyboard text input.  Alas, I also 
think that you shouldn't send HTML email or top-post your replies - 
both lost causes in this modern world.  

"Gracefully surrender the things of youth..."  I started using twm some
time in the 1980's and went to vtwm only a few years ago.  Mozilla is 
the only application I know that misbehaves this way.

So this bug has been around since early 2001 (actually there are earlier reports than this 
particular bug. The earliest I can find is Bug 71920.). It seems kind of silly that an application 
would be unusable for years and the bug get so little attention. 
 
If there's a feeling this is one of those phantom bugs that annoying users keep reopening even 
though there's no problem, well, trust me it isn't. This is the main reason I've been using 
konqueror for years. I would like to use mozilla at least part of the time, but it's only usable for 
a few seconds before it gets confused about input focus and stops working. 
 
This is an easy bug to reproduce, just run twm or no window manager. Various people report 
the bug with different configurations, I can say first-hand that turning off titlebars in twm reliably 
causes mozilla to get confused fairly quickly. 
 
The random nature of the behaviour makes me think it's a race condition in the order window 
focus events arrive relative to the library calls being made. But it doesn't take long to be 
triggered. 
 
I can understand that it's hard to debug something in the event handling, especially with so 
much abstraction hiding the low levels. And if it's a race condition that would make it doubly 
hard to track down, race conditions are always the hardest bugs to debug. But like I say, it's 
pretty silly to spend this much work on an application and have it all be unusable because of a 
bug nobody bothers fixing in the ui code. 
Perhaps we can use this bug as a forum for discussing alternative window 
managers that work around Mozilla's problem.  This bug is also why I use 
konquerer. 
 
I tried a whole pile of window managers but I could not find one that 
out-of-the-box allowed me to do the things that twm does: maintain a compact 
vertical list of windows with both visible & iconified windows always present 
AND allows keyboard binding for raise, lower, move, resize, iconify etc.  I'm 
pretty sure my search was conclusive so my question is: are there any modern 
window managers (gwm has the same problem as twm) that can be reconfigured to 
do what I'm looking for?  I imagine most of the rest of you who are watching 
this bug are looking for similar things or you wouldn't have triggered the bug 
yourself. 
 
I thank Ian Allen for the unjam trick.  I havn't used it yet, but it sounds 
good! 
What would that accomplish? The bug would still be there.  
 
In any case, I'm not interested in other window managers. twm does what i want, namely 
doesn't get in my way and I'm happy with it. It's mozilla I'm unhappy with. 
This twm patch seems to fix the problem. I have no idea why it works. All it
does is create a title window even if the window doesn't need a title. Then if
we're not going to need a title, it immediately destroys the title window,
without even mapping it.

The fact that this works suggests strongly that this is a gtk or mozilla bug,
not a twm bug.
I applied your patch to ctwm (required minor modification).  No dice. 
My Mozilla windows have titles anyway.  I wish it had worked! 
I really think this is two different bugs.

1. Is completely reproducible, not random, and can't be unjammed. It only
affects transient windows, like "Find." Can be fixed with "DecorateTransients"
in twm.

2. Is random, probably a race, and affects any window that accepts input. Not
affected by my patch or by "DecorateTransients".
*** Bug 234542 has been marked as a duplicate of this bug. ***
*** Bug 243401 has been marked as a duplicate of this bug. ***
Chris, I see 15 votes on this bug, which is quite significant, but no activity.
Can you take a look at it or mark it helpwanted if you have no intentions to do so?
Blocks: focusnav, atfmeta, aix-access
I don't know how to make this any easier to reproduce. I just ran mozilla from  
the debian mozilla-snapshot package (Mozilla 1.6a  
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031002) and it refused  
input right away. I had to iconify and deiconify it to get it to accept any  
input. I just went back to it again and it was refusing keyboard input again.  
  
I'll attach my .twmrc in case that helps. It seems which other application I  
move the mouse into when i move it out of mozilla is a factor. But I'm not  
running anything special now, just emacs, xterm, and konqueror (for obvious  
reasons)  
  
I'm a bit puzzled why mozilla cares about enter/leave notifications at all. It  
seems like if it gets keyboard focus it should trust the X server sent it to  
the right place and handle it based on the window it was sent to. not try to  
second-guess the x server and keep track of what window the mouse is in as it  
moves around.  
Actually, nevermind. I don't have to attach my .twmrc I can reproduce this bug 
reliably with no .twmrc at all, ie, all default config. 
 
I'm correct though that which other application you come from seems to matter. 
When I move the mouse from emacs into mozilla the focus is always fine. When I 
move the mouse from konqueror with a text input active into mozilla the text 
input is always fubar'd. 
 
So to reproduce: start a mozilla, go to www.google.com. Start a konqueror, go 
to www.google.com. Click in the text input field of the google page in 
konqueror so you have a flashing caret. Move the mouse directly into mozilla 
without passing through any other windows. Click in the text input field of 
mozilla. (notice mozilla spontaneously raises itself -- that seems to be a 
related bug.) Try typing. 
 
I've long noticed that whenever mozilla spontaneously raises itself on a mouse 
click it's telling me that its focus is going to be fubar'd. Applications 
really ought not ever be fooling with their stacking order, and mozilla usually 
doesn't. It only seems to do it when this bug is triggered. 
Hm, actually doing some further experiments. moving from xterm into mozilla 
seems to freeze the text input about half the time. moving from emacs into 
mozilla also sometimes freezes the text input. moving from xterm into the 
titlebar of mozilla into the mozilla window seems to unfreeze the input. I'm 
not sure this is 100% reproducible though. I think there may be more things 
going on. 
 
Also, when the focus is about to be fubar'd another symptom i've noticed is 
that double-clicking in a text input widget appears to select the entire widget 
normally but then it immediately deselects itself. 
Can you unfreeze the input by using twm's f.focus function? You might have to
add this function to one of your menus (in .twmrc), I don't think it's there by
default.

Also, have you tried my twm patch? Did it help?

I'm trying to figure out if the bug you're seeing is the same as the one I'm seeing.
Yes, f.focus always works. 
 
I haven't tried the patch because it didn't sound like it helped someone else. 
Your patch seems to only be relevant for either undecorated windows or twm with 
notitlefocus. But I see the problem even with the default twm config. So I 
suspect it's another way to trigger the same bug. 
 
I'm pretty convinced that the right solution to this problem is going to be to 
remove some moderate swath of code. There's some code in mozilla or in gtk, 
that's trying to manage focus manually where it should just trust the X server. 
Rather than try to fix the logic to mirror the X server perfectly in every case 
it would be better to just excise the cancer entirely. 
This is off-topic, but my god bugzilla is slow to update this bug. Is it trying 
to update the entire bug history as one big denormalized text field or 
something? Or is it sending dozens of individual mails directly from the web 
server? Or is there just some missing index on some foreign key for bug 
comments or something? 
(In reply to comment #93)
You're right, my twm patch wouldn't make any difference for top-level decorated
windows, which is where you are seeing this problem.

I agree that the fix is likely to involve removing the offending code rather
than adding more code. Unfortunately, mozilla does need to keep track of focus
itself. To get some idea of how complicated focus management is, take a look at
bug 124750, which may even be related. Also, a bugzilla search on "focus" shows
plenty of other focus bugs.

I think it would help if some of the focus experts, like maybe bryner, could
take a look at this one.

On your other topic, yes, bugzilla is very slow to update this bug. But I don't
usually wait around for the update to complete.
I think bug 124750 is actually just more evidence for my point of view. There 
probably just shouldn't *be* a focus controller "active" flag. That code should 
probably just go entirely. Anything that consults such a flag should probably 
be making an X call (indirectly through some abstraction) to check whether the 
focus *really is* active in that window. Not using some locally maintained flag 
that can get out of sync. 
Does this still happen with a gtk2 build?
I think the mozilla-snapshot debian package is a gtk2 build.  
 
bash-2.05b$ ldd /usr/lib/mozilla-snapshot/mozilla-bin 
		libmozjs.so => /usr/lib/libmozjs.so (0x4002d000) 
	libplds4.so => /usr/lib/libplds4.so (0x400ad000) 
	libplc4.so => /usr/lib/libplc4.so (0x400b1000) 
	libnspr4.so => /usr/lib/libnspr4.so (0x400b6000) 
	libpthread.so.0 => /lib/tls/libpthread.so.0 (0x400ea000) 
	libdl.so.2 => /lib/tls/libdl.so.2 (0x400f9000) 
	libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x400fc000) 
	libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x4034d000) 
	libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x403bb000) 
	libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x403d5000) 
	libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x403e8000) 
	libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x40409000) 
	libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x40416000) 
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x40449000) 
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x40484000) 
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40488000) 
	libm.so.6 => /lib/tls/libm.so.6 (0x40506000) 
	libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40529000) 
	libc.so.6 => /lib/tls/libc.so.6 (0x405e2000) 
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4071d000) 
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 
	libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40726000) 
	libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x407ed000) 
	libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x407f1000) 
	libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x407f9000) 
	libXft.so.2 => /usr/lib/libXft.so.2 (0x40807000) 
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0x40819000) 
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40822000) 
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40849000) 
	libz.so.1 => /usr/lib/libz.so.1 (0x408b6000) 
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0x408c7000) 
bash-2.05b$ dpkg -S /usr/lib/libgtk-x11-2.0.so 
libgtk2.0-dev: /usr/lib/libgtk-x11-2.0.so 
 
 
This bug is back, even with my twm patch, now that I have upgraded from OpenBSD
3.3 to 3.6.
I used to have this bug all the time.  For the last year or so I have not had
the bug.  I've mostly been using firefox.
This bug is still there in Firefox 1.5rc1/OpenBSD 3.6/gtk 1.2. I will be throwing a five year anniversary party for this bug next May. All are invited.
As far as I can tell this is fixed.   
I'm using ctwm on Debian sid with XFree86 and XOrg.

Did the Debian folks fix it?
I would guess that either ctwm (vs twm) or gtk2 fixes it.

Note that there are two different bugs. This one only hits undecorated dialog boxes. Bug 76854 hits all text input fields, including forms and the url bar. I used to think they were the same bug, now I think they're different. I believe the other one has been fixed, but it's still open because it's been confused with this bug.
I have had no more Mozilla/vtwm input problems for the past many months,
perhaps going on a year or two.  I don't know what changed.

Mandrake "Cooker" Linux
Linux home 2.6.12-12mdk-i686-up-4GB #1 Fri Sep 9 17:59:21 CEST 2005 i686
   AMD Athlon(tm) XP 3200+ unknown GNU/Linux
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
mozilla-1.7.12-5mdk
xorg-x11-6.9-1.cvs20051011.2mdk.i586.rpm
vtwm 5.4.7 (compiled from source)
I have now tried two different versions of firefox 1.0.8 on OpenBSD with twm. One is a gtk1 build and exhibits this bug. The other is a gtk2 build and does not exhibit this bug. So I think something in gtk2 makes the bug go away.

If anyone can report seeing this bug with gtk2, let's leave it open. Otherwise mark it "won't fix" and close it.
I tried to reproduce this on debian (with firefox 1.5.0.1, with some debian mods), built against gtk2.0, and I could not.

Perhaps this bug is finally dead.  Long Live 78928!
Having used many versions of Firefox on many different versions of X in the last three years, and still on twm, I'm almost certain now that this bug only shows up in gtk1 builds. I suggest we close this as "won't fix" unless someone thinks gtk1 has a future. Is anyone still seeing this bug?
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Keywords: qawanted
Summary: twm or no wm: Cannot type into dialog text fields → twm or no wm: Cannot type into dialog text fields [gtk1 builds only]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: