1727557 - Left clicking on a symbol near the end of a file results in some of the menu being hidden

Status: RESOLVED FIXED

(Webtools :: Searchfox, defect)

Description

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Attachment: SearchFoxMenuOffEndOfWindow.png

STR:

• Navigate to a file and find a symbol on the last few lines of the file (e.g. GMPLoader::CanSandbox at time of writing).
• Left click that symbol to open the context menu.

Result:
Some options of the context menu are off screen/outside the window and cannot be selected. See attached screenshot showing this.

Desired outcome:
The menu is shifted upwards so that all options are displayed within the window.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

The https://github.com/mozsearch/mozsearch/blob/master/static/js/context-menu.js logic doesn't ever consider the implications of the height (or width) of the resulting context menu and a need to displace the popup to account for that.

That said, in the mega-menu branch and the "fancy" branch libraries did provide the expected popup displacement and in those instances where the menu was displaced, the interaction was made more awkward by the muscle memory for interacting with the menu being broken.

A more hacky approach that provides uniformity of interaction might be for us to ensure additional effective padding at the bottom of the source listing. The current searchfox footer is extremely tiny, but, if it was made more generous and we addressed the very legitimate enhancement request to provide more data in the footer in bug 1509263, we could provide for some minimum number of menu lines without it necessarily being obvious that it's being done in service of a hack.

As an example, the github source for context-menu provides a pop-up that is always displayed below the click point and if the viewport is scrolled so that the menu is outside the viewport, the onus is on the user to scroll down so it's displayed. It's also the case that the "end" symbol which generates a 5-line popup menu always has space to be displayed because of the generous footer. A limitation is that our menus definitely don't have a hard height limit, but our mitigation in that case might just be to explicitly have a div at the bottom of the code listing area that we explicitly increase in size to ensure the scroll area can always fit the menu, allowing the user to scroll-wheel down to see the entire menu. And in that case, the silly hack only appears on demand.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Should be fixed by https://github.com/mozsearch/mozsearch/pull/471.