956356 - displaced selection and style activation on treeitems

Status: RESOLVED DUPLICATE of bug 835044

(Firefox :: Untriaged, defect)

Description

[u462496]

Attachment: Demonstrates this bug.

On linux, If Firefox is opened not in fullscreen mode, -moz-tree-row(hover) style activates treeitem elements in a displaced manner, eg, when an item is hovered over, the style rule is applied to an element several pixels below. The amount of displacement seems to correspond with the amount of offset the window is from the top of the screen.  When in fullscreen mode, the proper items are activated as expected.

To use the demo:



1) Make sure Firefox is not in full screen mode, and that the window is a little below the top of the screen.
2) find "Tree Element Bug Test" in Tools menu and click.  A Panel will open with several tree elements.
3) Begin hovering over the items

expected behavior would be that the items receive yellow background as they are hovered.  In fact, however, observe that it is items below the cursor that are highlighted instead.

4) Switch to full screen mode and repeat 2 and 3.

Observe that items are now highlighted as expected.

Comment 1

[u462496]

Hello,  Please someone check into this bug.  It affects my addon.  It has been 4 months since it was filed and there has been no activity.

Comment 2

[u462496]

Also please note that not only is style activation displaced, but selection of items is displaced as well, ie, you click on an item at top of list, and item several rows below is selected.

This also affects drag operations the same way, although the demo does not demonstrate that.

Comment 4

[:Gijs (he/him)]

Do you know if this used to work in earlier versions?

Comment 5

[u462496]

I do not, I will check.

Comment 6

[u462496]

Works on 18.0.2, breaks on 19.0.1.  I'll try to get a tighter regression using nightlys.  Is there a regression tool for linux?

Comment 7

[:Gijs (he/him)]

mozregression should work - you can install it using pip or easy_install, see e.g. https://harthur.wordpress.com/2010/09/13/mozregression-update/

Thanks for helping figure this out!

Comment 8

[u462496]

regression:
19.0a1(2012-10-23) ok
19.0a1(2012-10-24) bug

Thanks for the link, I'll try it next time :-)

Comment 9

[:Gijs (he/him)]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=48502b61a63e&tochange=93cc1ee94291

Comment 10

[u462496]

(In reply to :Gijs Kruitbosch from comment #7)
> Thanks for helping figure this out!

Thanks for working on it :-)

Comment 11

[:Gijs (he/him)]

Finally having a chance to go through my needinfo queue... I'll keep this one in it for a bit, because I think I can do some more testing, but first, do you know if this only affects Linux?

Comment 12

[:Gijs (he/him)]

Karl, bug 793501 is in that regression range, any chance it's related? (assuming this is indeed GTK-toolkit (ie Linux) specific)
It seems like that changed some of how we create/deal with windows, and considering that this only reproduces in non-fullscreen mode... :-)

Comment 13

[u462496]

Seems to work okay on Windows and Mac.

Comment 14

[u462496]

(In reply to :Gijs Kruitbosch from comment #12)
> ...and considering that this only reproduces in non-fullscreen mode... :-)

Judging by this fact, and also the relative displacement when in non-fullscreen, makes me wonder if this is a clientY/screenY discrepancy.

Comment 16

[Or Schiro]

I can confirm this bug with the add-on Tab Group Helper as reported by Allasso Travesser above.

Installed version:
firefox 33.1.1-1
Arch Linux 64-Bit

I hope this helps.

Regards,

Robert