Closed
Bug 78928
Opened 24 years ago
Closed 11 years ago
twm or no wm: Cannot type into dialog text fields [gtk1 builds only]
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: terra, Assigned: blizzard)
References
(Blocks 2 open bugs)
Details
(Keywords: relnote)
Attachments
(1 file)
(deleted),
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".
Comment 1•24 years ago
|
||
this works for me on Mac
Comment 2•24 years ago
|
||
Works for me on Linux.
Comment 3•24 years ago
|
||
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
Reporter | ||
Comment 4•24 years ago
|
||
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?
Comment 5•24 years ago
|
||
Sounds like something is up with dialogs, marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
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
Comment 8•24 years ago
|
||
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.
Comment 9•24 years ago
|
||
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".
Comment 10•24 years ago
|
||
adding blizzard, pavlov for some X11 help
Assignee | ||
Comment 11•24 years ago
|
||
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.
Comment 12•23 years ago
|
||
Bug still occurs with Mozilla/5.0 (X11; U; Linux 2.2.17-8 i686; en-US; rv:0.9+) Gecko/20010518.
Comment 13•23 years ago
|
||
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.
Reporter | ||
Comment 14•23 years ago
|
||
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.
Comment 15•23 years ago
|
||
Still occurs in Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; rv:0.9+) Gecko/20010521
Comment 16•23 years ago
|
||
toolkit, over to trudelle to find an owner. Adding myself to cc list.
Assignee: mcafee → trudelle
Component: Preferences → XP Toolkit/Widgets
Updated•23 years ago
|
QA Contact: sairuh → jrgm
Comment 18•23 years ago
|
||
*** Bug 71920 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 19•23 years ago
|
||
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.
Comment 20•23 years ago
|
||
Release notes are available - created for Bug 71920, though that does mention VTWM as the problem window manager.
Comment 21•23 years ago
|
||
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
Comment 22•23 years ago
|
||
we could assign to nobody@mozilla.org, agreed this is an edge case now that it's 2001 and not 1987.
Comment 23•23 years ago
|
||
ooo. never done that before. it might get more attention there. off it goes.
Comment 24•23 years ago
|
||
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.
Comment 25•23 years ago
|
||
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!
Comment 26•23 years ago
|
||
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
Comment 27•23 years ago
|
||
(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
Comment 28•23 years ago
|
||
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
Comment 29•23 years ago
|
||
check the http://bugzilla.mozilla.org/show_bug.cgi?id=91446 for testcase about focus problem and fullscreen might be the same bug
Comment 30•23 years ago
|
||
*** Bug 93565 has been marked as a duplicate of this bug. ***
Comment 31•23 years ago
|
||
*** Bug 93587 has been marked as a duplicate of this bug. ***
Comment 32•23 years ago
|
||
*** Bug 93637 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
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).
Comment 34•23 years ago
|
||
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
Comment 35•23 years ago
|
||
is this the same as bug 73727 or bug 76854 maybe?
Reporter | ||
Comment 36•23 years ago
|
||
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.)
Comment 37•23 years ago
|
||
*** Bug 92445 has been marked as a duplicate of this bug. ***
Comment 38•23 years ago
|
||
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.
Comment 39•23 years ago
|
||
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.
Comment 40•23 years ago
|
||
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.)
Comment 41•23 years ago
|
||
*** Bug 100306 has been marked as a duplicate of this bug. ***
Comment 42•23 years ago
|
||
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.
Comment 43•23 years ago
|
||
*** Bug 108006 has been marked as a duplicate of this bug. ***
Comment 44•23 years ago
|
||
If you add NoTitleFocus to your .twmrc, it makes it much worse: you cannot even type in a url.
Comment 45•23 years ago
|
||
Please note the cousin of this bug: bug 76854
Comment 46•23 years ago
|
||
*** Bug 114273 has been marked as a duplicate of this bug. ***
Comment 47•23 years ago
|
||
*** Bug 129413 has been marked as a duplicate of this bug. ***
Comment 48•23 years ago
|
||
*** Bug 125290 has been marked as a duplicate of this bug. ***
Comment 49•23 years ago
|
||
*** Bug 138033 has been marked as a duplicate of this bug. ***
Comment 50•23 years ago
|
||
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.
Comment 51•22 years ago
|
||
This bug is still present in rc2 (we're using twm).
Comment 52•22 years ago
|
||
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?
Comment 53•22 years ago
|
||
*** Bug 145395 has been marked as a duplicate of this bug. ***
Comment 54•22 years ago
|
||
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
Comment 55•22 years ago
|
||
*** Bug 148615 has been marked as a duplicate of this bug. ***
Comment 56•22 years ago
|
||
*** Bug 157732 has been marked as a duplicate of this bug. ***
Comment 57•22 years ago
|
||
*** Bug 157732 has been marked as a duplicate of this bug. ***
Comment 58•22 years ago
|
||
*** Bug 165011 has been marked as a duplicate of this bug. ***
Comment 59•22 years ago
|
||
*** Bug 165013 has been marked as a duplicate of this bug. ***
Comment 60•22 years ago
|
||
*** Bug 175571 has been marked as a duplicate of this bug. ***
Comment 61•22 years ago
|
||
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?
Comment 62•22 years ago
|
||
*** Bug 177582 has been marked as a duplicate of this bug. ***
Comment 63•22 years ago
|
||
*** Bug 181209 has been marked as a duplicate of this bug. ***
Comment 64•22 years ago
|
||
*** Bug 192788 has been marked as a duplicate of this bug. ***
Comment 65•22 years ago
|
||
*** Bug 197126 has been marked as a duplicate of this bug. ***
Comment 66•22 years ago
|
||
As of version 1.4a, the problem with TWM window manager is still present.
Comment 67•22 years ago
|
||
*** Bug 204595 has been marked as a duplicate of this bug. ***
Comment 68•21 years ago
|
||
*** Bug 210280 has been marked as a duplicate of this bug. ***
Comment 69•21 years ago
|
||
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.
Comment 70•21 years ago
|
||
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.
Comment 71•21 years ago
|
||
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?
Comment 72•21 years ago
|
||
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.
Comment 73•21 years ago
|
||
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)
Comment 74•21 years ago
|
||
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.
Comment 75•21 years ago
|
||
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?
Comment 76•21 years ago
|
||
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?
Comment 77•21 years ago
|
||
*** Bug 237445 has been marked as a duplicate of this bug. ***
Comment 78•21 years ago
|
||
(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.
Comment 79•21 years ago
|
||
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.
Comment 80•21 years ago
|
||
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!
Comment 81•21 years ago
|
||
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.
Comment 82•21 years ago
|
||
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.
Comment 83•21 years ago
|
||
I applied your patch to ctwm (required minor modification). No dice. My Mozilla windows have titles anyway. I wish it had worked!
Comment 84•21 years ago
|
||
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".
Comment 85•21 years ago
|
||
*** Bug 234542 has been marked as a duplicate of this bug. ***
Comment 86•20 years ago
|
||
*** Bug 243401 has been marked as a duplicate of this bug. ***
Comment 87•20 years ago
|
||
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?
Comment 88•20 years ago
|
||
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.
Comment 89•20 years ago
|
||
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.
Comment 90•20 years ago
|
||
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.
Comment 91•20 years ago
|
||
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.
Comment 92•20 years ago
|
||
Yes, f.focus always works. I haven't tried the patch because it didn't sound like it helped someone else.
Comment 93•20 years ago
|
||
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.
Comment 94•20 years ago
|
||
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?
Comment 95•20 years ago
|
||
(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.
Comment 96•20 years ago
|
||
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.
Assignee | ||
Comment 97•20 years ago
|
||
Does this still happen with a gtk2 build?
Comment 98•20 years ago
|
||
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
Comment 99•20 years ago
|
||
This bug is back, even with my twm patch, now that I have upgraded from OpenBSD 3.3 to 3.6.
Comment 100•19 years ago
|
||
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.
Comment 101•19 years ago
|
||
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.
Comment 102•19 years ago
|
||
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?
Comment 103•19 years ago
|
||
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.
Comment 104•19 years ago
|
||
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)
Comment 105•18 years ago
|
||
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.
Comment 106•18 years ago
|
||
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!
Comment 107•16 years ago
|
||
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?
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Updated•11 years ago
|
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.
Description
•