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

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Wladimir Palant]

Attachment: 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.

Comment 1

[Wladimir Palant]

Attachment: 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.

Comment 2

[Wladimir Palant]

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.

Comment 3

[Wladimir Palant]

This regressed on trunk between build 20090113021344 and build 20090114021407. Which makes bug 473042 and bug 140759 the likely suspects.

Comment 4

[Wladimir Palant]

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

Comment 5

[Wladimir Palant]

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.

Comment 6

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336