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

Use more predictable units for offset positions #204

Open
Andarist opened this issue Dec 6, 2021 · 2 comments
Open

Use more predictable units for offset positions #204

Andarist opened this issue Dec 6, 2021 · 2 comments

Comments

@Andarist
Copy link
Collaborator

Andarist commented Dec 6, 2021

@dmtrKovalenko has mentioned that the used coordinate system is not intuitive to Cypress users. I partially agree with that - I think though that the internal coordinate system is mostly hidden from users and they don't have to care about it that much because cypress-real-events is taking care of the heavy-lifting and computes the screen positions of AUT elements.
#198 (comment)

I think though that there is one thing that could be done to make interacting with this library more intuitive and preditable

Currently, if we do smth like:

cy.get('div').realClick({ position: {  x: 5, y: 5 } })

then the computed position will use { x: 5, y: 5 } as a screen offset of the element's position. I don't think this is what users expect though, for the majority of use cases. This is especially less-than-ideal as the final position is depending on the screen size and can vary based on the whole window being resized or devtools being open etc

I propose to redefine what this offset means - IMHO this should be an offset from the el.getBoundingClientRect(). That way we'd end up with more consistent results, independent from the root viewport size.

The change should be pretty trivial (but breaking!) - we'd have to essentially shift the logic from getPositionedCoordinates to getElementPositionXY (the latter should probably be renamed in the process).

@dmtrKovalenko
Copy link
Owner

I agree with that but I do actually aware of breaking changes. I think that any “plug-in” should avoid breaking changes as much as possible.

So we can wait for somebody to actually get really mad because of this or some other breaking changes to group them together.

@Andarist
Copy link
Collaborator Author

Andarist commented Feb 1, 2022

Can I count as somebody who got really mad because of this? 😅 It really makes writing some tests quite cumbersome.

For instance, I need to write a test that clicks close to the right side of an element. The problem is that for some reason position: 'right' doesn't work because sometimes I end up with a very minor px difference and the browser "responds" with a click on the background element. It's like I'm hitting very close to the "edge value" in the hit target algorithm. To fix this kind of stuff I would grab the element, calculate its width and just click on something like x: el.width - 5. The problem is that this doesn't work as expected because where the click will actually be dispatched depends on the window size and thus the test written like that is not reliable. However, it would be reliable if only those offsets would be reliable - if they would be expressed in the in-app values.

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

No branches or pull requests

2 participants