Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rightclick context menu generation uses screen offset instead of window offset. #38591

Closed
Tracked by #37734
Anutrix opened this issue May 9, 2020 · 3 comments · Fixed by #40028
Closed
Tracked by #37734

Rightclick context menu generation uses screen offset instead of window offset. #38591

Anutrix opened this issue May 9, 2020 · 3 comments · Fixed by #40028

Comments

@Anutrix
Copy link
Contributor

Anutrix commented May 9, 2020

Alternative Title: Rightclick context menu generation uses the active window's parent's window offset instead of active window offset.

Godot version:
Latest master 46f1d4f

OS/device including version:
Windows 10 1909

Issue description:
Rightclick context menu generation uses screen offset instead of window offset.
Thus, even making context menu outside window depending on the position.

Steps to reproduce:

  1. Move window anywhere accept top left default position.
  2. Right-click any right-clickable thing.
  3. It will be generated at the same XY offset that it should have from screen's top-left(actual) instead of window's top-left(expected).
    godot-issue

Update: Another way to reproduce this is to right-click anything in the file dialogue e.g,

  1. Click any node.
  2. In the inspector, click the Load button for the Material property.
  3. Move this EditorFileDialog to any position other than the default position.
  4. Right-click anything.
  5. This time it will use the main window's offset instead of the EditorFileDialog's offset.

Minimal reproduction project:
Any project.

@bruvzg
Copy link
Member

bruvzg commented May 9, 2020

Should be fixed by #37506

@Anutrix
Copy link
Contributor Author

Anutrix commented May 11, 2020

Should be fixed by #37506

Confirmed that #37506 indeed fixes this issue.
Update: Confirmed that it fixes the 2nd issue too.

@Anutrix
Copy link
Contributor Author

Anutrix commented May 29, 2020

Don't know which commit fixed this but I can no longer reproduce this. If someone can confirm I'll close this issue. I tested with 0f1da72.
I couldn't reproduce in the same way as earlier though. I added another way to reproduce it in the first comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants