124212 - issues with "open/save file" filepicker and XUL cache disabled

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[Jeremy M. Dolan]

After the checkin of bug 121354, my 2 month old profile has a few issues in Open
File:

It takes two clicks to expand the ancestor list ("Look in:"). Doesn't matter is
the clicks are on the text or down arrow.

After expanding the list, I can no longer enter text on "File name:". I can
focus it, and the cursor blinks, but nothing can be entered until I cancel and
come back in.

A new profile has no problems. Don't know if bugs caused by old profiles are
considered worth reporting, but I expect other users with slightly aged profiles
will see this behavior too.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Please attach your prefs.js/user.js to this bug.

Comment 2

[Jeremy M. Dolan]

Attachment: prefs.js

I deleted XUL.mfasl but I still see this. I don't know what users.js is but I
don't have one (I assume a js file that's sourced by Moz, but never overwritten
like prefs.js). Using Classic theme, if that matters.

Comment 3

[John Morrison]

> user_pref("nglayout.debug.disable_xul_cache", true);

try removing that line (although, if that cures it, note that there is, in 
general, no obligation to fix bugs that are only reproducible with the xul 
cache disabled).

Comment 4

[Jeremy M. Dolan]

Yep, that's it jrgm! Resummarizing.

I enable XUL cache, works normally. I go back and disable it, and it's back to
two-clicks for the select box and impossible to give focus. Tryed this with both
2002020809 and a build from the day before. In both the open and save file dialogs.

Understand the "no obligation to fix", but it seems something underlying is
broke (specially the bit about not being able to type at all), so a Future would
be ideal over a WONTFIX.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Over to XUL stuff.  This likely has something to do with the dynamic
construction of that dropdown...

Comment 6

[John Morrison]

Okeley-dokely. Future it is...

There is something wrong, I suppose, but since it is travelling a code path
that is never intended for users to encounter, and it works in the normal 
case, then it's not a priority to fix.

Comment 7

[James Paige]

*** Bug 129751 has been marked as a duplicate of this bug. ***

Comment 8

[Boris Zbarsky [:bzbarsky]]

Copying James' comments from bug 129751:

The following javascript error does appears in the javascript
console *after* the save-as dialog has been closed, but it *only* appears
if the directory-picker widget thingy recieved focus at some point while the
Save-As dialog was open:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIMenuBoxObject.activeChild]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: <unknown filename> ::
onxblpopupshowing :: line 6"  data: no]
----------------------------------

The only way nsIMenuBoxObject.activeChild can return NS_ERROR_FAILURE is if the
nsMenuFrame's mPopupFrames.FirstChild() call returns a null pointer...

Comment 9

[Boris Zbarsky [:bzbarsky]]

*** Bug 132760 has been marked as a duplicate of this bug. ***

Comment 10

[John Morrison]

not gonna fix this.