Title change of bookmarks not saved when using inline edit

VERIFIED FIXED

Status

defect
--
major
VERIFIED FIXED
19 years ago
14 years ago

People

(Reporter: fabian, Assigned: bugs)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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.
It is dependant on bug 68537.
This has a bad consequence that I will be reporting in a different bug. 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. 
(bug 68537).
6) Scroll down to the new folder using the vertical scrollbar
7) The inline edit cell has lost focus. Click on it to get the focus back on it
8) Type some name
9) Hit enter or click outside the cell

Actual Results:  The name change is not saved

Expected Results:  The name change is saved

Happens on all platform
*** Bug 67942 has been marked as a duplicate of this bug. ***
Not only is the name change not saved but the folder will disappear after
closing the bookmark manager. A work around for this is to create the new folder
in a sub folder so that it is on the screen after being created.

Comment 3

18 years ago
I can't get inline edit renaming to work in any way now. Upping severity to
major and resummarizing. I will merge this bug with that because the problems
are similar and will probably be fixed with the same fix.

Please let me know if I should file another bug on this...
Severity: normal → major
Summary: Title change not saved if focus lost of inline edit → Title change of bookmarks not saved when using inline edit

Comment 4

18 years ago
Is this a duplicate of bug 68612 - "Cannot edit bookmarks inline"?
(Reporter)

Comment 5

18 years ago
No. Inline editing works. Just the name is not saved because I scrolled downwards.

Comment 6

18 years ago
*** Bug 69133 has been marked as a duplicate of this bug. ***

Comment 7

18 years ago
*** Bug 71443 has been marked as a duplicate of this bug. ***
Fixed.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 9

18 years ago
2001032208/Linux doesn't save the new title.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 10

18 years ago
Details please? What exactly did you to not have the title saved? Please read
the original bug report carefully. It used to happen when you had to scroll the
bookmark window before renaming the bookmark. But Ben Goodger in his infinite
kindness made it that the bookmarks manager now scrolls automatically (bug
68537), so this bug has to be fixed, if not the cause, at least the symptoms.
Thanks.

Comment 11

18 years ago
I reopened bug 68537 and attached a screenshot.

Steps to reproduce is the same as the original report.
(Reporter)

Comment 12

18 years ago
Is this fixed now Koike, since bug 68537 is fixed?

Comment 13

18 years ago
No, this bug and bug 68537 aren't fixed.
*** Bug 77879 has been marked as a duplicate of this bug. ***
Comments from bug 77879:

1) 

I don't know if it is related, but when trying to add the new folder, the
following gets output on the console

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

2) Long bookmark file to reproduce the problem is attachment 32428 [details]

3)

I can reproduce it consistently using the following steps:
1) Replace your bookmarks.html file with the one I attached
2) Run mozilla
3) Launch bookmark manager
4) Expand Folder
5) Select Folder
6) Click "New Folder" button
7) Enter new name
8) Hit enter

Comment 16

18 years ago
*** Bug 78335 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 17

18 years ago
I don't understand!! I swear on the love of me that it works!! (on win2k anyway)

Comment 18

18 years ago
Fabian,

Have you tried using the bookmarks.html file I sent in as attachment 32428 [details]?  The
daily linux build from the trunk still exhibits this problem for me :(

-bmh

Comment 19

18 years ago
*** Bug 78952 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
*** Bug 77688 has been marked as a duplicate of this bug. ***

Comment 21

18 years ago
Nominating nsbeta1

Updated

18 years ago
Keywords: nsbeta1

Comment 22

18 years ago
nav triage team:

Can't reproduce using a fairly stock mozilla profile with a recent mac build on 
my powerbook. Unless we can get a test case with a brand new profile, not a beta 
stopper.
Keywords: nsbeta1nsbeta1-

Comment 23

18 years ago
Using US Windows 98, 2001050904 build, Works4me

I was able to add a new folder and give it a new name no matter where it 
appeared in my list of bookmarks:  near the top, in the middle, near the bottom. 
 With the scrollbar showing.
(Reporter)

Comment 24

18 years ago
arglblblblblbl! I got this this morning but creating a new profile fixed it.
Ben G, by the way, is there any reason you put this code
var index = gBookmarksShell.tree.getIndexOfItem(dummyItem);
gBookmarksShell.tree.ensureIndexIsVisible(index);
in the if (aSelectedItem.getAttribute("container") == "true")
instead of calling it for every new item? 
This causes the proper behavior when adding folders, but when adding separators
or bookmarks to the bottom of the window, it doesn't scroll (since the function
is not called).
Personnaly I think we should move this back downwards to call it for each new
item regardless of its type.

Comment 25

18 years ago
I think this was fixed anyways, but if it wasn't, it is now that ile is 
disabled.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 26

18 years ago
*** Bug 84108 has been marked as a duplicate of this bug. ***

Comment 27

18 years ago
what Blake said
VERIFIED Fixed
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.