I have a task to automate password creation where the mouse should be moved about 10 times in certain area in any direction. I was trying to use mouseover but it doesn't work.
cy.get('.form')
.trigger('mouseover')
.trigger('mousedown')
.trigger('mousemove', 50, 10)
If you expect your operating system mouse pointer to move, it won't happen in Cypress at all. In Cypress you can trigger events and it should be sufficient way to reach what you want.
The code you posted does trigger events properly, you can use it, it is fine. Depending on your implementation just trigger mousemove multiple times or trigger mouseoverand mouseout and repeat the sequence as many times you need.
If you want to see the mouse "pointer" in cypress, you can select a test execution snapshot at the left side of cypress execution window and see small red circle with white dot inside, which visualize the coordinates of the event triggered.
Related
I see the point of the "timeline" feature (I mean when you point the cursor on an item in Cypress log).
In my case, it is quite annoying: as soon as you hover on an entry in the Cypress log, all the previous steps of that test are repeated.
This means every time I point the mouse over an entry there (by mistake) I flood the server with dozens of unnecessary calls.
Is there a way to disable the hover action?
I have a paper-button with the on-tap function that opens a paper-dialog that contains a "Accept" paper-button that will close it when clicked.
The problem i'm getting is if depending on my screen resolution, and the dialog's "Accept" button is over the initial button to open the dialog, when clicked, the dialog opens and closes. I'm assuming the on-tap event is being fired to both.
I've tried these 2 methods but they do not seem to help.
event.cancelBubble = true;
event.stopPropagation();
The problem is that a capacitive screens or even mouses can generate multiple tap event on the same spot within a few milisec.
The mouses because a quick change in a high and low voltage (logical 1 and 0) generating an AC signal wich can jump trough on a capacitator (which can be the button two contactor between the air) if the conditions matching. But the onclick event is already catching this case and you does not require to do anything to solve it.
The capacitve screens are capacitators and just rolling your finger should trigger multiple tap events because your skin has different depth of insulation and hard to mark the tap begin and end in some cases.
This physical problem should be solved by the platform, but it is not in every situation currently (but most of the devices are filtering this). Im usally solving this isse with a transparent overlay element wich can catch the pointer events for a little duration so I could catch the "prelling" of a button or the capacitive screen for a few ms.
If a 10-20ms is enough for you then wait a frame in your on-tap function with requestAnimationFrame and then show the dialog. Cheap trick, but it does what it has to, but ultimately you can wait a fix timeout to show the dialog, because you have 100ms to respond a user interaction.
You cannot fix this by manipulating the browser events options though because as I know you dont have option to how much time need to pass until the next same event should happend. But if you wait a frame thats could behave like you add a delay between the events.
I'm trying to understand how to pause and resume interaction in paper.js.
I have the metaball example on a page with an input element on top, and because paper.js steals focus for driving the metaball generation onMouseMove... bad things happen. Like not able to select what you typed.
I understood I could use item.locked = true;, but I don't know what to apply it to because nothing works.
What is the parent Item for paper.js and can I lock it so that everything stops responding to the mouse?
I also couldn't reattach the mousemove event from the Tool, which is why I came to look into item.locked. What's the correct way to remove and reattach mouse events?
I'm using WM_MOUSEMOVE to get changes in mouse position. When simulating "knobs" for example it's desired to let the user go up/down with mouse without any limits. In this cases I hide cursor and use SetCursorPos to change its position every time user moves with it and detect just the difference from the original position.
Unfortunately it doesn't seem to work - if I set the mouse position, it sometimes works, but sometimes is one or more pixels away, which is just wrong. And even bigger trouble is that after the call another WM_MOUSEMOVE seems to be delivered, which unfortunately does the same thing as it wants to move the cursor back to the original position again. So it ends up in an infinite cycle or settings mouse position and receiving messages until the user releases the mouse button.
What's the correct approach or what's the problem?
The raw input system can do this - it lets you register for raw mouse input that isn't clipped or confined to the screen boundaries.
Broadly speaking, you register for raw input using RegisterRawInputDevices(). Your window will then receive WM_INPUT messages, which you process using the GetRawInputData() function.
See Using Raw Input for an example.
I hide cursor and use SetCursorPos to change its position every time user moves with it and detect just the difference from the original position.
This is just plain wrong. Instead, use SetCapture() to capture the mouse. All movements will be reported as WM_MOUSEMOVE messages with coordinates that are relative to the specified window, even if the mouse is outside of that window, until you release the capture.
Asking the user to move the mouse continuously, even after the cursor hit the screen limit is a very bad idea in terms of User Interface, IMHO.
Some games have another approach: when the mouse hit the "limit", the game enter a special mode: things appears to function exactly as if the mouse was moving, even if the user don't move it. When the user wants to exit that mode, he just has to move the mouse of the limit.
Doing so requires a timer, armed when the mouse hit some limit, executing code periodically as if the mouse was moving. The timer is stopped when a real mouse movement makes it leaves the limit.
Ok folks, so I found a solution simple enough:
The main problem is that SetCursorPos may not set the coordinates accurately, I guess it's because of some high resolution processing, nevertheless it's probably a bug. Anyway if SetCursorPos doesn't set the coordinates correctly (but +-1 in x and/or y) it also sends WM_MOUSEMOVE to the target window. As a result the window performs the exact same operation as before and this goes on and on.
So the solution is to remove all WM_MOUSEMOVE messages right after SetCursorPos:
MSG msg;
while (::PeekMessage(&msg, NULL, WM_MOUSEMOVE, WM_MOUSEMOVE, PM_REMOVE)) { };
Then retrieving the current mouse cursor pos using ::GetCursorPos .
It's ugly but seems to fix the problem. It basically seems that in some position of the mouse, the system always adds or subtracts 1 in either coordinate, so this way you let system do the weird stuff and use the new coordinates without trying to persuade system that your coordinates are the correct ones :).
Whenever I write mouse handling code, the onmousedown/onmouseup/onmousemove model always seemed to force me to produce unnecessarily complex code that would still end up causing all sorts of UI bugs.
The main problem which I see even in major pieces of software these days is the "ghost mouse" event where you drag to outside the window and then let go. Once you return back into the window, the application still thinks you have the mouse down even though the button is up. This is especially annoying when you're trying to highlight something that goes to the border of the screen.
Is there a RIGHT way to write mouse code or is the entire model just flawed?
Ordinarily one captures the mouse events on mouse down so the mouse move and mouse up go through your code regardless of the caret moving out of you application window.
More recently this is a problem when running a VM or remote session, its difficult for apps in these to track the mouse outside of the machine screen area represented by a window on a host.
I'm not sure what environment you're attempting to track mouse buttons in, but the best way to handle this is to have a mouse listener that tracks onmouseup 100% of the time after you've detected onmousedown.
That way, it doesn't matter what screen region the user releases the mouse button in. It will reset no matter where it happens.