Closed Bug 68537 Opened 24 years ago Closed 21 years ago

bookmarks view doesn't scroll automatically to the new folder

Categories

(SeaMonkey :: Bookmarks & History, defect, P4)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla1.0.1

People

(Reporter: fabian, Assigned: bugs)

References

Details

Attachments

(2 files)

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
Summary: Folder name change not saved if focus lost on inline edit → Doesn't scroll automatically to the new folder
Blocks: 68539
Blocks: 68550
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
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
just tweaking summary so i know what the bug is w/o having to read it each time
Summary: Doesn't scroll automatically to the new folder → bookmarks view doesn't scroll automatically to the new folder
Marking nsbeta1+ to get on radar
Keywords: nsbeta1+
fix in tree.
Mass moving most of mozilla0.9 bugs to mozilla0.8.1
Target Milestone: mozilla0.9 → 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. 
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Blank text field for new folder name appears at the bottom of the window,
but the lower half of it is hidden.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached image Screenshot
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. 
Target Milestone: mozilla0.8.1 → mozilla0.9
Could this be related to the fact that inline editing just appears to be 
completely busted? 

*sharpens axe, goes off to find blake*
Status: REOPENED → ASSIGNED
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. 
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Target Milestone: mozilla0.9 → mozilla0.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. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2
nav triage team:

Pushing out to mozilla0.9.3, marking p4. This one is kinda hard to produce (well, 
at least, for me).
Priority: -- → P4
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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. 
Target Milestone: mozilla0.9.3 → mozilla1.0
Paul Chen is now taking Bookmarks bugs. For your convenience, you can filter 
email notifications caused by this by searching for 'ilikegoats'.

Assignee: ben → pchen
Status: REOPENED → NEW
moving to mozilla0.9.8
Target Milestone: mozilla1.0 → mozilla0.9.8
pushing out to mozilla1.0.1
Target Milestone: mozilla0.9.8 → 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
Assignee: pchen → 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.
Status: NEW → RESOLVED
Closed: 23 years ago21 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: