857357 - arrowscrollbox.ensureElementIsVisible() in menupopup / MacOS : autorepeatbutton blocks element

Status: RESOLVED WONTFIX

(Toolkit :: UI Widgets, defect)

Description

[u462496]

Attachment: extension demonstrating the bug

(testing was done on Mac OS X 10.7.5)

When calling arrowscroll.ensureElementIsVisible() on an element that is out of visibility, if the autorepeatbutton at the end of the menu where the element should appear is or becomes enabled and visible, it obscures the element.

This behavior does not occur on Windows XP, and upon investigation, it appears that on WindowsOS, arrowscroll.scrollClientRect (used in the scrolling calculation) excludes the autorepeatbuttons, whereas on MacOS scrollClientRect encloses the buttons if they are visible.  This was verified by dumping the values for scrollClientRect and comparing to actual pixel dimensions from screenshots of the menus on both OSs.  I suspect the difference in behavior is related to the fact that on WindowsOS, the autorepeatbuttons are always visible, even if disabled, whereas on MacOS, they are hidden when disabled.

Attached is a demo extension, which will put a large menu (181 items) on the Addons bar.  The items are labeled "item N" where N correlates to the position in the menu.  keypress event listener is placed on the window, and pressing the number keys on the keyboard will call ensureElementIsVisible() on the anonymous arrowscroll element in the menupopup.  The element this method is called for is determined by the number key pressed, the element called being position N * 20;
ie, pressing 2 will call ensureElementIsVisible on item 40, pressing 4 - item 80, etc.

You should quickly see the problem if you install the extension (and enable addons bar), open the menu by clicking the "ensureElementIsVisible" menu button, and press "5".  You should see "item 099" appear at the bottom of the menu, with "item 100" obscured by the autorepeatbutton.  'dump' output to the console will reveal that "item 100" was the element ensureElementIsVisible() was called for.

Comment 1

[u462496]

EDIT: arrowscroll --> arrowscrollbox in summary.

This bug refers to arrowscrollbox within menupopup

Comment 2

[u462496]

On MacOS, for autorepeatbutton in menupopup, there is a -15px margin placed on the scrollbox sides of each, causing the buttons to obscure the inside edges of the scrollbox when they are visible.  WindowsOS does not have this -15px margin.

It appears that this is not being accounted for in the amountToScroll calculation.

chrome://global/skin/global.css:

.popup-internal-box > .autorepeatbutton-up {
  margin-bottom: -15px;
}

.popup-internal-box > .autorepeatbutton-down {
  margin-top: -15px;
}

Comment 3

[Loic]

I installed the demo extension in Firefox 23 on Win 7. I see the button "ensureElementIsVisible" in the add-on bar but if I click on it, I'm not able to open the menu to show the items (screenshot: http://i.imgur.com/vKpdCva.png).

In addition, I get this error in the Error Console: 

Error: TypeError: cs is null
Source File: chrome://global/content/bindings/button.xml
Line: 94

Any idea?

Comment 4

[u462496]

I'll check into it right now.  Maybe I uploaded the wrong version...

Comment 5

[u462496]

Have you tried on Mac?

Comment 6

[Loic]

(In reply to Allasso Travesser from comment #5)
> Have you tried on Mac?

Sorry, I don't have any Mac machine.

Comment 7

[u462496]

Attachment: extension demonstrating the bug

Extension fixed to work properly on WindowsOS

Comment 8

[u462496]

I uploaded another extension, please try it again.

Of course you are aware the bug only manifests on MacOS

Comment 9

[u462496]

I don't understand why my extension attachments end up being application/octet-stream. I always upload them as application/x-xpinstall.

Comment 10

[Loic]

Yes, I tested the new add-on and it works fine. When I press 5, "item100" appears at the top/bottom (depends on the selection in the menu).

Comment 11

[u462496]

If you try it on MacOS, you will only see "item 099".  The "item 100" item is obscured by the scroll button.

Comment 12

[u462496]

Anything happening?  Been 4 months.

Did anyone try this on MacOS?

Comment 13

[Loic]

(In reply to Allasso Travesser from comment #12)
> Anything happening?  Been 4 months.
> 
> Did anyone try this on MacOS?

Did it use to work in previous versions of Firefox?

Comment 14

[u462496]

Problem does not appear in 3.6, because 3.6 does not hide autorepeatbutton, and works the same as in Windows.

In 4.0, only on MacOS, FF began hiding the autorepeatbutton when menu is scrolled to the respective end, ie, when menu is scrolled all the way to the top, top autorepeatbutton is hidden, when scrolled to bottom, bottom autorepeatbutton is hidden.  This is where the problem started happening.

Windows does not hide autorepeatbuttons, and the problem doesn't occur in Windows.

The problem is related to the un-hiding of the autorepeatbutton.  Firefox uses negative margins (eg, top button has {margin_bottom: -15px} and vice-versa) on the autorepeatbutton, causing it to float over the top of the element at top/bottom, and thus when it is made visible, obscures it, rather than shifting the elements up or down.

The behavior is more apparent if you do the following:

(You will need to use a mouse scrollwheel or device which has 1px control over scrolling to demonstrate this)

1) Scroll to very top of menu, observing that top autorepeatbutton disappears.

2) Scroll the menu down 1px using scrollwheel.

3) Observe that when the autorepeatbutton appears, it suddenly appears over the top of the top element, obscuring it.

This issue does not present a problem with manual scrolling, but when trying to scroll menu programatically using built-in methods, it creates a problem.

Again, please note, the problem does not occur on WindowsOS.  Please try it on MacOS.

Comment 15

[Dão Gottwald [:dao]]

XUL extension support has been removed.