"Mouse Move: To the Text Cursor Position" in browser windows

[acantor]

I have found this Macro Express instruction of limited use when automating tasks in web pages. That's because the instruction sends the mouse pointer to the upper left corner of the window, rather than to the location of the text cursor, also known as the insertion point.

 

To test, create a hotkey macro that issues the "Mouse Move: To the Text Cursor Position" command.

 

Then open a browser window to Google.com, ensure the insertion point (cursor) is in the "Search Google" field by typing a few characters, and then press your hotkey.

 

For as long as I can remember, for every browser I tried this on, the mouse pointer jumped to the upper left corner of the window.

 

Today a macro that I have been using daily stopped working properly. The macro runs in Firefox. As I tried to figure out what was happening, I noticed that the mouse pointer was jumping to the text field. Very strange! It's never done that before.

 

In Chrome, the command continues to cause the mouse pointer to jump to the upper left corner.

 

What might be responsible for this change in behaviour? Is this change due to a recent Macro Express update? Or perhaps a change in Firefox?

[Cory]

I don't have an answer to your question, but early on in my big batch automation projects i completely gave up on using the mouse in web pages and would learn to do everything by keyboard. Usually a bunch of tabbing. But even that was slow and frustrating so I started writing programs to automate web browsers instead, so I haven't even done that in ages. But you might try to use the keyboard more. 

[terrypin]

Yes, same here Alan. Seems to go consistently to (8,31)

 

I'm fairly sure it worked OK in previous version. Bug report?

[acantor]

 

1 hour ago, terrypin said:

I'm fairly sure it worked OK in previous version. Bug report?

 

Maybe, Terry, but it's hard to know how to describe a bug for something that has never worked correctly, but now does, at least in Firefox.

 

I have a few scripts that automate tasks in web-based applications that take advantage of the failure. I used the instruction to move the mouse pointer to a predictable position -- the coordinates were the same however the browser was configured: menus or no menus, toolbars or no toolbars, etc.

 

These scripts may fail now because the MEP instruction suddenly works! I'm not sure I can call this a bug.

[terrypin]

Digressing, but ... this is a rather similar scenario to a bizarre issue here. Two days ago I sent a formal bug report. When assigning a short key to a new macro, ALL generated the warning message, even though there was no conflict. IOW, that key was not already in use.

 

Support could not reproduce - but neither could I on the following day! However, essentially the opposite problem was now consistently occurring: NO shortkeys caused the error message!

 

I hate unsolved quirks like this so have spent most of today trying to solve it - in vain.

 

Back to your issue. My test was with Waterfox. Wherever the text cursor was, that command moves the mouse cursor to (8,31j on my 1920x1080 screen.

 

I’ll try other tests later.

 

What OS version do you have?

[terrypin]

I ran my test macro in a dozen applications, with the text cursor positioned at arbitrary locations. Eight worked correctly:

 

Firefox, MEP, TextPad, File Explorer, Quicken, Excel, GPS Utility, PaintShop Pro.

 

It did not work in these four, with the resulting consistent mouse cursor positions.

 

Waterfox browser: 8,31

Chrome browse:, 8,,0

Edge browser: 0,0

Google Earth: 8,31

 

 

[acantor]

Thank you Terry for checking with different programs. It's good to know that I am not hallucinating: the "mouse move to text cursor position" instruction works in some applications, but not in others.

 

Yet I am almost certain that it didn't work in Firefox yesterday. Last night I refined a script for Firefox that uses the instruction to move the mouse pointer to a fixed location in to the upper left corner of the window. Yet this morning, the pointer began jumping to the focused text field.

 

My first thought was that there has been an overnight change in Firefox. I have Firefox 68.0.1, which was released on 18 July. I checked the folder of Firefox Program files on my PC, and some are date-stamped 20 July. So it would appear the change in Macro Express's behaviour is not due to a Firefox update 11 days ago.

 

I just wrote the folks at Insight Software to ask if they might be able to shed light on this mystery.

[terrypin]

50 minutes ago, acantor said:

Quote

Thank you Terry for checking with different programs. It's good to know that I am not hallucinating: the "mouse move to text cursor position" instruction works in some applications, but not in others.

 

A bug in my view. Even if its ultimate cause is not down solely to MEP, a command has to be consistent or it’s effectively unusable.

 

Quote

Yet I am almost certain that it didn't work in Firefox yesterday. Last night I refined a script for Firefox that uses the instruction to move the mouse pointer to a fixed location in to the upper left corner of the window. Yet this morning, the pointer began jumping to the focused text field.

 

Referring back to my last but one post, my first thought about the strange ‘reversal’ of behaviour in shortkeys assignment was that it was an overnight MS OS change. But I have no evidence.

 

What is your OS version?

 

Have you tried the command in other applications?

 

 

[acantor]

I heard back from Insight Software. They say the change in behaviour is not related to Macro Express, but is more likely related to a Firefox update.

 

Quote

No, we have not made any changes to this [Macro Express] functionality. We instruct Windows to move the mouse. It is up to the receiving application to apply the move. Most likely Firefox has made a change that makes this work properly.

 

Now that the "Mouse Move to Text Cursor Position" works in Firefox, there are a lot of interesting possibilities!

 

I find this MEP instruction work in Word, Excel, PowerPoint, and Outlook. It even works on the Windows desktop provided one is editing the name of an icon. Otherwise, the mouse pointer jumps to the top left corner.

 

I'm using Windows 7.

[terrypin]

Thanks Alan. If so, I hope Waterfox will soon catch up, as the browser is a fruitful target for that command.

[acantor]

This is weird.

 

In Firefox, the "Move Move to the Text Cursor Position" command has resorted to its former behaviour. In other words, focus is going to the top left corner, not to the focused text field.

 

Something else must be happening!

[terrypin]

Indeed!

 

But I made a surprising discovery when I reloaded Firefox and tested again just now. I found that the command worked incorrectly only if it was positioned at the top left corner, (0,0)!

 

If instead you drag it away from there, the command does what it should. With it at (0,0) the mouse cursor now always jumps to (0,23). Note that that is different to the behaviour yesterday, when it was working correctly (assuming that I had Firefox maximised).

 

I found the same with Waterfox and Edge. And Google Earth. But not Chrome, in which the destination is always (0,0), regardless of the window size or position.

 

BTW, overnight I updated Windows 10 to version 1903, build 18362.267 in an (unsuccessful) attempt to fix the shortkeys problem I mentioned, although I still see no clear evidence that updates might be a factor.

 

I'm inclined to report it formally as a 'bug', referring to this thread for detail. But first I'd be interested to see if others can reproduce my results. To help, here's the simple macro I'm using:

// Assumes the text cursor has been placed directly before running the macro with the hotkey of choice, in this case Alt+F6.
For a browser, obvious locations are the Address or Search box, but any text field can be used.
Delay: 0.1 seconds
Mouse Move: To the Text Cursor Position
Delay: 0.1 seconds
Get Mouse Position into (nMouseX, nMouseY) Relative to Screen
Text Box Display: Mouse position at text cursor

CODE:

<COMMENT Value="Assumes the text cursor has been placed directly before running the macro with the hotkey of choice, in this case Alt+F6.\r\nFor a browser, obvious locations are the Address or Search box, but any text field can be used."/>
<DELAY Flags="\x01" Time="0.1"/>
<MOUSE MOVE Option="\x00" X="0" Y="0" _PROMPT="0x000A"/>
<DELAY Flags="\x01" Time="0.1"/>
<GET MOUSE POSITION Option="\x00" X="nMouseX" Y="nMouseY"/>
<TEXT BOX DISPLAY Title="Mouse position at text cursor" Content="{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang2057{\\fonttbl{\\f0\\fnil Tahoma;}{\\f1\\fnil\\fcharset0 Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs20 %nMouseX%\\f1 , %nMouseY%\\f0 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>

 

 

 

 

[acantor]

Hi Terry,

 

I've tried to reproduce your finding, without success. No matter whether Firefox is maximized, resized to be smaller, positioned at the top of the screen or somewhere else, the instruction causes the mouse pointer to jump to the top left corner of the menu bar or to the text field that has keyboard input focus.

 

The only consistency I have found is that the mouse pointer always goes to the top left corner when no text field is focused, e.g., focus-able web objects such as hypertext links, drop down lists, check boxes, radio buttons, etc.)

[terrypin]

And that includes when Firefox is not maximised and not located at (0,0)?

 

By 'top left corner' do you mean exactly (0,0)?

 

All very baffling! 🙂

[acantor]

Here's another aspect of this mystery:

 

1. Click into the Search box at the top right of a Firefox window. (The default hotkey to do this is Ctrl+E.). So keyboard focus is definitely in this text field.

 

2. Activate your macro to move the mouse pointer to the text cursor position.

 

The mouse pointer jumps to the upper left corner of the screen.

 

3 Click into the Search box, and type a few characters.

 

4. Activate your macro to move the mouse pointer to the text cursor position.

 

This time, the mouse pointer jumps into the Search box!

 

By the way, I made a minor change to your macro. I show coordinates relative to the window rather than to the screen.

[terrypin]

Yes, relative to the window is better than to the screen for this stuff, so I've changed to that too.

 

But I can't reproduce your latest mystery. In both Firefox and Waterfox the mouse cursor destination is always (8,31) regardless of whether there's been any typed entry or not. Wherever the text cursor is placed. (I find the most convenient locations are the Address or the Search box.)

 

Did you note that 'always'? Incredibly, this is suddenly no longer dependent on whether FF or WF are at (0,0)!

 

You didn't tell me what you meant by 'top left corner'. Knowing that (and your screen resolution) might offer clues about what's going on. I just pop up the MEP Mouse Locator for confirmation, before doing anything else, with this macro, which I activate with Alt+Shift+7. (Preceding it with a Mouse Left Click command would avoid the negative results you get against 'Active Window'. That's why I originally worked in 'relative to screen'.)

 

Keystroke Speed: 10 milliseconds
Program Launch: "MSLocate.exe" (Normal)
Parameters: -hex
Delay: 100 milliseconds

 

<KEYSTROKE SPEED Delay="10"/>
<PROGRAM LAUNCH Path="C:\\Program Files (x86)\\Macro Express Pro\\MSLocate.exe" Mode="\x00" Parameters="-hex" Default_Path="TRUE" Wait="1" Get_Console="FALSE"/>
<DELAY Flags="\x02" Time="100"/>

 

 

[acantor]

There are many factors that might account for the differences we are witnessing: we use different operating systems (Windows 7 vs. 10), display themes (I'm using a variation of the Classic theme, which isn't available in Windows 10), and perhaps the ways we have configured Macro Express and Firefox.

 

I first noticed this anomaly while running a Macro Express script that I have been using for years. Earlier this week, I added a routine to check for pixel colour changes; the routine begins with the "Mouse Move to Cursor Position" instruction, which I knew from prior experience would move the mouse cursor to the top left corner relative to the window. Over the years I have become accustomed to this command "failing" in web browsers, and have tried to take advantage of the fact that the instruction always moves the mouse pointer to the exact same location within the window. In my case, the target is (6,25) relative to the window, which is the top left corner of Firefox's menu bar.

 

But unexpectedly, the instruction began to move the mouse pointer to the cursor.

 

In my new routine, the instruction sometimes causes the pointer to jump to one location, and sometimes to the other.  I'll continue to explore as time allows. In the meantime, I've modified the routine so that it works in both situations: move the pointer to (6,25), or to the actual cursor position.

[acantor]

For the last two days, the instruction has worked as it has for years. I am out of ideas as to what may have caused  the instruction to temporarily work the way that it was supposed to!

[terrypin]

Here it still doesn't do what it should.

 

In Firefox and Waterfox always going to (8,31), relative to the window.

 

In MS Edge it goes to (0,0), the TL corner of the screen, regardless of where the Edge window is placed.

 

In Google Chrome it goes to screen (8,0), regardless of where the Chrome window is placed.

 

In Google Earth it always goes to (8,31), relative to the window.

 

In Notepad and my regular text editor, TextPad - it works correctly!

 

 

[acantor]

So it would appear we have come full circle.

 

The "Mouse Move to the Text Cursor Position" generally works as it should in text editors, word processors, spreadsheets, and the like. 

 

But in browsers (and in applications that run in browsers) the instruction usually moves the mouse pointer to a spot near the top-left corner of the window. The coordinates are application specific, so differ slightly in Chrome vs. Firefox vs Edge.

 

There may be conditions that cause "Mouse Move to the Text Cursor Position" to actually move to the text cursor position within the active window, at least in Firefox. After hours of experimentation, I still have no idea what these conditions are!

 

If you issue the instruction in, for example, the "Print" dialog in Firefox, the mouse pointer will jump to the text cursor position. But this may be due to the Print dialog being a Microsoft tool rather than a screen Mozilla created from scratch.

[terrypin]

I sent a formal ‘bug report’, referring to this thread for further detail.