Interestingly.. the textfield context menu in edit mode is not offset - just the treeview context menu.

Deleted: Screen Shot 2018-05-07 at 11.15.17 am.png 64.2 KB

	Screen Shot 2018-05-07 at 11.15.17 am.png 64.2 KB View Download

Ah, actually this affects both directions, and it's not as bad as I thought.

I think the problem occurs only when the (right) mouse-down also triggers the code in TreeView::SetSelectedNode() that will invoke ScrollRectToVisible() AND scrolling actually needs to occur in that case (in any direction).

View::ProcessMousePressed() does OnMousePressed(event) before showing the context menu. So scrolling occurs first. But when View::ProcessMousePressed() tries to ConvertPointToScreen() it's using the old scroll position -- not the new one.

The problem is probably that the value of event.location() in View::ProcessMousePressed(const ui::MouseEvent& event) effectively needs to change when scrolling occurs (i.e. after the call to OnMousePressed() in ProcessMousePressed()).

I dunno whether that's worth fixing directly, or if TreeView::ShowContextMenu() should just ignore its |Point| argument and instead use display::Screen::GetScreen()->GetCursorScreenPoint() since it is TreeView that invokes ScrollRectToVisible() and is messing with things.

tapted: Do you plan to work on this?

So.... this problem actually went away on Mac when we switched back to native context menus \o/.

Either:
 - Those are always anchored to the cursor, or
 - Those are synchronous, so anchor themselves before the ScrollView adjusts its visible rect, rather than after
 - or something else.

But when we roll out layered scrolling to other platforms, this will likely bite again.

Updating labels, and added Issue 873923 to track.