80380 - file picker: unable to type in textfield after selecting from droplist

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[sairuh (rarely reading bugmail)]

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.

Comment 1

[eddyk]

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.

Comment 2

[HJ]

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

Comment 3

[saari (gone)]

Target 0.9.2

Comment 4

[saari (gone)]

jag has a work around

Comment 5

[jag (Peter Annema)]

Attachment: [patch] work around weird event stuff

Comment 6

[jag (Peter Annema)]

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.

Comment 7

[Brian Ryner (not reading)]

r=bryner

Comment 8

[jag (Peter Annema)]

Attachment: [patch] a slightly better fix, perhaps

Comment 9

[jag (Peter Annema)]

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.

Comment 10

[jag (Peter Annema)]

Attachment: [patch] slightly better && killed redundant code

Comment 11

[Brian Ryner (not reading)]

r=bryner

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

Sure.
sr=[e-mail]

Comment 13

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 14

[jag (Peter Annema)]

Checked in

Comment 15

[doctor__j]

Will this fix solve bug 84881?

Comment 16

[John Morrison]

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

Comment 17

[John Morrison]

verified fixed in 2001061121 Linux build. 

Comment 18

[Andreas Franke (gone)]

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?

Comment 19

[Andreas Franke (gone)]

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

Comment 20

[Andreas Franke (gone)]

Still seeing this in Mozilla 1.0 final. Reopening.

Comment 21

[Andreas Franke (gone)]

Really reopening. Sorry.

Comment 22

[Andreas Franke (gone)]

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.

Comment 23

[Andreas Franke (gone)]

Back to verified fixed. Sorry again.

Comment 24

[Andreas Franke (gone)]

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.

Comment 25

[Andreas Franke (gone)]

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?