⚠️ This PR originates from a fork. Due to security restrictions, pipelines from forks are no longer triggered automatically. Learn more.

If the changes appear safe, you can manually trigger the pipeline by commenting /AzurePipelines run.

⚠️ This PR originates from a fork. Due to security restrictions, pipelines from forks are no longer triggered automatically. Learn more.

If the changes appear safe, you can manually trigger the pipeline by commenting /AzurePipelines run.

@bpasero would appreciate a review on this one, since I had to make a small change or two to the contextmenuService. The issue was that without changing how we computed the anchor position, it would anchor itself well below the dropdown button when zoomed in, regardless of whether or not it was on screen.

The change was

const elementPosition = dom.getDomNodePagePosition(anchor);

to

const clientRect = anchor.getBoundingClientRect();
const elementPosition = { left: clientRect.left, top: clientRect.top, width: clientRect.width, height: clientRect.height };

I've checked as many context menus throughout the product as I could find, but not sure if there could be an edge case I'm missing.

Can we see for a simpler fix if possible specifically for the zooming issue (which seems to be the real issue here) and/or understand if it impacts browser as well or differently?

@bpasero I'll see if there's any implications with browser, however I do want to clarify that it's actually not an issue with zoom. It's just an issue with where the button is positioned in the DOM vs the viewport. Zooming into the issue reporter just makes the issue more apparent since it pushes the button off the form.

To test this, I reverted all changes to the contextMenu service, and then changed the issue reporter window size from 700x800 to 700x300. Here's what we end up getting with how the context menu anchor is currently computed:

and then when I simply expand the issue reporter window manually, we can see that it was "correctly" anchored, just on the initial DOM position.

I'm not an expert with the front end work involved in a lot of the DOM structure and the differences with this and the browser implementation but I'll see if it's effected. Could be that we can bring this logic over to it as well, unsure. The clipping logic seems like something we could/should use regardless of how we want to get the anchor position (via either DOM.getDomNodePagePosition(anchor) or my proposed anchor.getBoundingClientRect(); + rect position/width/height)

Maybe the deeper issue is that the we don't recompute the anchor position as the window resizes. I know a lot of this code has been around for quite a while, so not sure how much relies on the nuance of the anchor hueristics we have right now.

I did notice that I couldn't really find any buttons with dropdowns that could be scrolled off the screen, so I wonder if this could've just been us exposing an edge case that we've never really had any reason to see until now.

⚠️ This PR originates from a fork. Due to security restrictions, pipelines from forks are no longer triggered automatically. Learn more.

If the changes appear safe, you can manually trigger the pipeline by commenting /AzurePipelines run.

Tested all reporting action flows (preview + create) on native and custom context menus, windows + macOS as well. Changes to contextView and contextMenuService necessary now that we have a case where we can scroll a dropdown context menu off screen (calculations hadn't been built out to do viewport relative calculations and scroll offsets)