nsITreeBoxObject.ensureRowIsVisible selects wrong row for a tree inside a stack

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
10 years ago
Last year

People

(Reporter: gaubugzilla, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

1.45 KB, application/vnd.mozilla.xul+xml
Details
5.12 KB, image/png
Details
Posted file Testcase
nsITreeBoxObject.ensureRowIsVisible seems to have a one-off bug in the following scenario:

1. Chrome dialog
2. xul:tree inside a xul:stack
3. ensureRowIsVisible is called from window's load event

In this setup ensureRowIsVisible will make row 1 visible instead of row 0. It is similar with other values being passed in - always the row index that is higher by 1 becomes visible while the row that should become visible is scrolled away.

To test download the testcase and open it from chrome://:

  openDialog("chrome://.../ensureRowIsVisible_test.xul");

Issue exists both in trunk builds (build 20090423031603) and on 1.9.1 branch (build 20090422031238). Works fine in Firefox 3.0.9 however.
Posted image Screenshot
Attaching screenshot - that's what the testcase looks like after opening the window. The first row is scrolled out of view instead of being made visible.

Same issue can be seen with Adblock Plus 1.0.2 - when the preferences windows is opened (Ctrl+Shift+E) the first row is scrolled out of view.
The obvious work-around is not calling ensureRowIsVisible in this case since the first row should always be visible when the window comes up. Unfortunately, there are other cases where Adblock Plus needs to select a different row during window initialization - and the behavior is broken there as well.
This regressed on trunk between build 20090113021344 and build 20090114021407. Which makes bug 473042 and bug 140759 the likely suspects.
Backing out various patches from the range in question didn't make the bug go away. I wonder whether http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-01-13+02%3A13%3A44+&enddate=2009-01-14+02%3A14%3A07 isn't what I should be looking at...
Verified that the issue still exists in Firefox 3.6.13. Works correctly in Minefield 4.0b10pre build 20110125 however (both on Windows 7 x64). Given that the likeliness of this fix being backported to branch is zero I will resolve this bug as WORKSFORME.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336
Component: XP Toolkit/Widgets: XUL → XUL
You need to log in before you can comment on or make changes to this bug.