From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; 0.8) Gecko/20010210 BuildID: 2001021020 Ok this is an edge case, but easy to reproduce. This has two bad consequences that I will be reporting in different bugs. I'll post the bug# later. Reproducible: Always Steps to Reproduce: 1) Launch Mozilla 2) Bookmarks|Bookmarks Manager (BM) 3) Resize the BM to have a vertical scrollbar (i.e. you don't see the last bookmarks) 4) Select your root bookmark directory ("Bookmarks for ") 5) Hit "New Folder" on the toolbar At this point you have a new folder but it is at the bottom of the list and the window hasn't scrolled on its own. That is bug number 1 here. Actual Results: The window didn't scroll to the new folder that is being created. Expected Results: The folder being edited should come into view

updating summarry sorry for that

Seen in the console as this bug is being reproduced: ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "[JavaScript Error: "field.select is not a function" {file: "chrome://global/content/treeBindings.xml#treecell-indented-folder-inline-edit-base.setMode()" line: 17}] [nsIController::doCommand]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "JS frame :: chrome://global/content/globalOverlay.js :: goDoCommand :: line 71" data: yes] ************************************************************ An error occurred executing the cmd_newfolder command

This is a problem in the Add Bookmark dialog as well.

I need to call ensureRowIsVisible. Accepting. .9

just tweaking summary so i know what the bug is w/o having to read it each time

Marking nsbeta1+ to get on radar

fix in tree.

Mass moving most of mozilla0.9 bugs to mozilla0.8.1

fix _not_ in tree btw, in case anyone was fooled by 02-27 comments (like me)

i meant fix in /my/ tree ;) If I had fixed it on the trunk, I'd have marked this fixed so I could have something to brag about on my status report ;)

Fix checked in.

Blank text field for new folder name appears at the bottom of the window, but the lower half of it is hidden.

worksforme build 2001032304 on win95, the window scrolls correctly to the bottom. However I can confirm that the name is not saved, even if I don't scroll the page.. argh! I believe someone reported this yesterday.. let me look

see bug 73184

throwing into .9 so this doesn't get lost.

Could this be related to the fact that inline editing just appears to be completely busted? *sharpens axe, goes off to find blake*

this patch does four things: - fixes value->label screwups in treeBindings.xml that was causing inline edit operations to fail (looks like blake was somewhat confused here so made some guesses, but didn't bother to check them ;) - fixes Shift+F2 inline-edit of the location field (mistyped variable name) - made new folders created offscreen be scrolled into view after their name has been entered. - made new folders created when the selected item is an open container be created at the end of the open folder rather than the start (fixes issue where inline edit of new folder name is at the end of the list, but confirmation of the name magically shifts folder to the start of the list). reviews, super-reviews? I'm sure this fixes more bugs than just this one, but this is the only one on my .9 list currently ;)

r=bzbarsky@mit.edu. This will also fix bug 73184 (inline edit being broken)

You probably should have looked at what Fabian said, since there's already a patch to do the first item in bug 73184.

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

fixed.

I've looked at an 04/26 Win98 build, a 2001050104 Mac build and a 2001050308 Linux build and this is still broken. Upon clicking 'New Folder' Nothing happens and I get the following error: ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "[Exception... "Component does not have requested interface" code: "-2147467262" nsresult: "0x80004002 (NS_NOINTERFACE)" location: "chrome://global/content/xulBindings.xml#textbox.select() Line: 1"] [nsIController::doCommand]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "JS frame :: chrome://global/content/globalOverlay.js :: goDoCommand :: line 70" data: no] ************************************************************ An error occurred executing the cmd_newfolder command after a second click I get a new folder but the view doesn't scroll it jumps and jumps back and then does the old wierd behavior where all the rows become spaced out stretching the vertical size.

yeah this is what is reported in bug 68539, but as I said there I can't reproduce at all as much as I tried to, and the code there looks as fine as can be... continuing to investigate...

SPAM: mozilla 0.9 (and M1, and 0.8.1, etc.) has left the building. please update the target milestone so we can get a good idea of what's left for 0.9.1.

I suggest we defer this until after the beta...

nav triage: not a beta stopper. It may not even be an rtm stopper, nav triage will look at this again after we get mozillz0.9.1 list under control.

nav triage team: Pushing out to mozilla0.9.3, marking p4. This one is kinda hard to produce (well, at least, for me).

This bug became invalid or worksforme. New folder name is asked by popup dialog now.

This is fixed for folders but not for new bookmarks and separators (although a minor issue). This is because the code that calls ensureIndexRowIsVisible or something like that is inside a if block that is called only if the new item is a folder, as I stated earlier in bug 68539.

nav triage: not necc for netscape rtm, deferring to m1.0.

Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter email notifications caused by this by searching for 'ilikegoats'.

moving to mozilla0.9.8

pushing out to mozilla1.0.1

it works for me. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120

mass reassign of pchen bookmark bugs to ben

I believe this bug should be RESOLVED, with WORKSFORME or FIXED as the resolution. This bug no longer exists in 1.4 RC3 on Win2k SP3 on my computer. The fix was to refuse to create new bookmarks/folders/separators when 'Bookmarks for ...' is selected!

Yep. Can't do those steps anymore... marking worksforme.