The bookmark tree jumps unexpectedly to the bottom of its view when the the first visible row is not the first one

VERIFIED FIXED in Firebird0.6

Status

()

Firefox
Bookmarks & History
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: Pierre Chanial, Assigned: David Hyatt)

Tracking

unspecified
Firebird0.6
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
This is the nastiest bug.
Step to reproduce: 
- open the bookmark manager
- expand your folders eventually so that there is a scrollbar
- scroll some rows
- select an item and remove it

expected: first row visible still visible
current: view jumps to the bottom

The removal of the row is wrapped in a batch (doCommand in bookmarksTree.xml)
The relevent part is here:

this.mOuter.treeBoxObject.selection.selectEventsSuppressed = true;
var observer =
this.mOuter.tree.builder.QueryInterface(Components.interfaces.nsIRDFObserver);
observer.beginUpdateBatch(this.db);
ookmarksController.doCommand(aCommand, selection, target);
observer.endUpdateBatch(this.db);
this.mOuter.tree.builder.rebuild();
this.mOuter.updateTreeSelection();
this.mOuter.treeBoxObject.selection.selectEventsSuppressed = false;

For phoenix 0.1, I could disable the batching, but it will slow down the things.
(Reporter)

Updated

16 years ago
Target Milestone: --- → Phoenix0.3
(Reporter)

Comment 1

16 years ago
-> hyatt, he will take care of it
Assignee: blaker → hyatt
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: Phoenix0.3 → Phoenix0.4
(Reporter)

Comment 2

16 years ago
*** Bug 176401 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 3

16 years ago
Checked in a hack fix for 0.4. --> 0.5.
Target Milestone: Phoenix0.4 → Phoenix0.5

Comment 4

16 years ago
hyatt, "additional patch" in bug 162542 fixes this problem.

Comment 5

16 years ago
So this is fixed now.  Thanks Jan!
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 6

16 years ago
Oops, I thought it was a C++ patch but it's not.  We'll have to port that fix
over to Phoenix.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 7

16 years ago
I haven't tested new builds, but iirc Jan's fix for this issue is in attachment
101158 [details] [diff] [review]. It patches nsXULTreeBuilder.cpp and it's been checked in.
(Reporter)

Comment 8

16 years ago
tested 11/10 build. if one comments the hack
this.mOuter.treeBoxObject.scrollToRow(firstVisibleRow);
in bookmarksTree.xml, the tree scrolls to the first row when rebuilding (before
Jan's fix, it was scrolling to the bottom).
That's still not what we want.

Comment 9

16 years ago
setting status to New
Status: REOPENED → NEW

Updated

16 years ago
Target Milestone: Phoenix0.5 → Phoenix0.6

Comment 10

15 years ago
Works for me. It jumps back and forth a bit, probably because of its hack-ness,
but the overall result is satisfactory for now?

Is there a better way to do this?

Comment 11

15 years ago
Is this still a problem?

Comment 12

15 years ago
This is no longer a problem. If pch wants to continue work here then feel free
to reopen and adjust the summary or file a new bug to work on a better fix.
Status: NEW → RESOLVED
Last Resolved: 16 years ago15 years ago
Resolution: --- → FIXED

Comment 13

15 years ago
The XUL tree builder behaves correctly. I think it's up to the caller what to do
after a batch operation (save/restore selection/scroll position).

Comment 14

15 years ago
Verified in latest nightly as of today.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.