found using 2001.05.08.08 comm verif bits and a debug from 16:44 y'day. following these steps you can get into a state where you won't be able to type within the xul file picker's textfield. for some reason it reminds me of bug 70742, but not sure if it is truly related --cc'ing eddyk, just in case. 1. open the xul file picker [File > Open File]. 2. navigate thru a few directories [so that there's more than one entry in the "Look in" droplist]. 3. drop down the droplist and select an item [i used the mouse to do this]. 4. click into the textfield next to "File name" --note that the textfield has both focus and a blinking cursor *and* the droplist appears "depressed" [well, darker, at least in modern3]. 5. attempt to type. result: unable to type anything. workaround [kinda wacky]: select [highlight/bring into focus] an item in the directory scrollist. hit Tab until the textfield is in focus [displays the focus ring]. now you can type.

probably not related. bug 70742 was because of a problem in nsWidgetStateManager. filepicker doesn't appear to use WSM, I could be wrong. I did notice an error when changing directories: JavaScript error: line 3: n.toggleOpenState is not a function Don't know what that means however.

toggleOpenState is a method in treeBindings.xml see: http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/treeBindings.xml#10 I'm using the patch for bug 70742 without problems, but i'm on WinNT4 and not Linux. note that this JS error is also reported in bug 80225 (DEC) "Can't import bookmarks, JavaScript error".

Target 0.9.2

jag has a work around

So, the deal here is that when you select an item in the droplist, the oncommand js code is executed, which rearranges the content of the droplist, thereby thoroughly confusing it and making the focus go all screwy... (If you look at it in the modern theme you can actually see the dropdown still being in a kind of depressed state). The timeout just moves the execution of the rearranging code out of the oncommand code, thereby avoiding major confusage and all is well... kinda... I think.

r=bryner

In the new patch I basically don't kill all the child nodes, replacing them with newly created ones in the new order... Instead I just remove the one that moves (i.e. the one that got selected), and insert it at the top. Actually, with this change, I no longer see the need for double administration of the directory history. I guess fetching those attributes is slightly slower, but not so much as to justify the extra code, so a new patch is coming up.

r=bryner

Sure. sr=ben@netscape.com

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

Checked in

Will this fix solve bug 84881?

> Will this fix solve bug 84881? Since this fix if for the filepicker dialog used on Linux, and the other bug is for the HTML <input type=file>, then, no, this will do nothing to address that other bug. Entirely separate code paths despite the nominal similarity.

verified fixed in 2001061121 Linux build.

I have a similar problem with Mozilla RC1 on Linux: After selecting something from the file picker dropdown, I can click into the filename text widget and get a blinking cursor there, but if I type on the keyboard none of the characters appear. But I couldn't say that the droplist appears "depressed" or something. jrgm: can you please test whether you can reproduce my problem, and if you can, file a new bug (or reopen this one), or paste a pointer to an exiting open bug here? jag: any idea?

Still seeing in RC3 what I described above in comment 18.

Still seeing this in Mozilla 1.0 final. Reopening.

Really reopening. Sorry.

Hm, using a trunk nightly (rv:1.1a Gecko/20020609), this bug doesn't occur, neither in a fresh profile nor in my day-to-day profile. With the 1.0 release build, I can't reproduce the bug in a fresh profile either. I only see it when I use it with my day-to-day profile. Thus putting it back to fixed, since I can neither reproduce it with a trunk build (at all) nor with a 1.0 build with a fresh profile.

Back to verified fixed. Sorry again.

Ok, here is some more detail for the record: - When this bug occurs, then clicking on the filepicker's dropdown for the first time will not make it drop down, but only 'focus' it or something. Only on the second mouse-click it will drop down so you can select a path prefix. This strangeness corresponds one-to-one with the "can't type in the textfield after using the dropdown box and navigating" problem; if you don't observe this strangeness, then you won't have the "can't type" problem. - Removing the following line from my profile repaired it so that everything works fine even with the 1.0 release build: > user_pref("nglayout.debug.disable_xul_cache", true); But I could not get the bug to occur on the trunk build, even with xul cache disabled.

But I can reproduce it with the 1.0 build with a fresh profile if I disable the xul cache manually in the prefs.js file (i.e. adding the line there). Adding note to status whiteboard. Anyone thinks that it is important to be able to run 1.0 branch builds with xul cache disabled?