The computer that was working properly also became faulty after a few months of use. It seems that Kingsoft’s office software modifies the registry under certain conditions, which causes this issue. After a few months, the registry entry related to ksoapi.dll only contained the file name without the full path. Specifically, this software registers a ksoapi.dll UUID under HKEY_CLASSES_ROOT\Interface{618736E0-3C3D-11CF-810C-00AA00389B71} — the IAccessible TypeLib entry — which leads to the problem...
WebAutoType does not know anything about ksoapi.dll, so it must be being injected somehow by Kingsoft office software. It looks like on the non-working system the Kingsoft installer has not correctly registered the full location of their .dll, but I can't guess why not. Thank you for writing up all these details, hopefully they will be helpful if anyone else encounters this issue with Kingsoft Office.
Since I had already checked Chrome’s accessibility settings and KeePass-HTTP-Connector, and both were working fine but the issue was still not solved, I decided to use Procmon to monitor what KeePass was loading or trying to access without sufficient permissions. That’s when I discovered the ksoapi.dll problem.
Since my native language is Chinese, this post is translated with AI, so there may be some language issues. I’ll include both the original text (Chinese) and the translation. Summary: Using Procmon I found WebAutoType failed because KeePass tried to load xxx.dll from the wrong path; fixing the registry entry or placing the DLL in the KeePass folder solved it. English (Translation) Recently, I discovered an issue where WebAutoType does not work on one of my computers. On another computer, however,...
The hotkey is CTRL + SHIFT + A.
Since my native language is Chinese, this post is translated with AI, so there may be some language issues. I’ll include both the original text (Chinese) and the translation. Summary: Using Procmon I found WebAutoType failed because KeePass tried to load xxx.dll from the wrong path; fixing the registry entry or placing the DLL in the KeePass folder solved it. English (Translation) Recently, I discovered an issue where WebAutoType does not work on one of my computers. On another computer, however,...
Oh, I did not realize that that particular attribute was also Aria-related. I'll try to send their web team a message informing them of the situation, because it might be negatively affecting other people and, somewhat ironically, other applications. Thank you for all of your help on this!
Yes, it's there, <body role="application"> Setting a custom aria role on the body element stops it being exposed to accessibility.
Here's a screenshot of the web page.
It's odd that the site is not showing up for you, nor for downforeveryoneorjustme.com. Every time I go to the site, in any browser, it always displays fine. So I saved the web page and attached it to this message. In the page's tag, I do not see any Aria settings. There are four Aria attributes in two of the divs (but I don't know if they would have any effect): <div class="modal fade" id="defaultModal" tabindex="-1" role="dialog" aria-labelledby="defaultModalTitle" aria-hidden="true"> <div class="modal-dialog"...
I'm afraid I still can't get any response at all out of mygportal, and DownForEveryoneOrJustMe seems to indicate it isn't just me. So I can only offer guesswork at this point. I know some websites declare a weird Aria role on their body tag, which stops them being exposed to accessibility. I created https://addons.mozilla.org/firefox/addon/prevent-custom-document-role that fixes that, but I do recognise that part of the whole point of WebAutoType is to avoid the need to install any addons. Sadly...
For the Schwab site, an iframe was the first possibility I thought of, but when inspecting the page's source code, I looked only in the immediate area and forgot that the iframe open tag could be up much higher in the code. So that WebAutoType entry is working perfectly now. Thanks. For the GI portal site (https://tddctx.mygportal.com/), I'm baffled because the login fields don't appear to be inside an iframe, and when I use the WebAutoType hotkey combination to create a new KeePass entry (in my...
Sometimes websites use iframes to embed their login controls from a different website to that of the parent page. For security, WebAutoType matches against the actual URL of the login form it will be sending the auto-type sequence to. In the case of schwab this is https://sws-gateway-nr.schwab.com/ui/host/#/login-one-step . I could not load mygportal.com, the site appears to be down, but I expect it will be the same issue. In Firefox you can discover these by right clicking on one of the login boxes...
WebAutoType is working well for dozens of websites that I added to my KeePass database. However, for two websites (https://www.schwab.com and https://tddctx.mygportal.com), even though their entries are set with the correct URLs and correct Auto-Type sequences, when I press the global Auto-Type hotkeys (Ctrl + Alt + A), nothing happens. I checked the Firefox Developer Tools windows (Inspector, Console, Debugger, etc.) and do not see anything amiss. Does anyone know of any reasons why WebAutoType...
Your suggestion works perfectly. I hadn't seen any mention of that option anywhere. Perhaps it could be added to the Readme.txt instructions. Thank you! On Fri, Jul 25, 2025 at 2:25 AM AlexVallat alexvallat@users.sourceforge.net wrote: To prevent KeePass from matching using the title, go to Tools, Options, Advanced and uncheck "An entry matches if its title is contained in the target window title". You might also want uncheck other window title matching options there. [tickets:#47] https://sourceforge.net/p/webautotype/tickets/47/...
To prevent KeePass from matching using the title, go to Tools, Options, Advanced and uncheck "An entry matches if its title is contained in the target window title". You might also want uncheck other window title matching options there.
WebAutoType not matching on URLs
Yeah, both Chromium. Realized that after I posted. All clear 😁
Yeah, all Chromium. Realized that after I posted. All clear 😁
I mean that Chrome (well, Chromium) will have to fix it on their side, so that the accessibility request no longer throws that error. It did not use to, hopefully they will fix it in the future. Edge is just another Chrome variant so if Chrome fixes it the fix will end up in Edge too. Firefox is not a Chrome variant, so is not affected. Brave is another Chrome.
Hi. what do you mean with 'something that has to be fixed on Chrome'? That is why I reported that I had the issue with Edge this time 😁 I use Firefox, Brave and Ghostery too, but not that often. As soon as I encounter the problems on one of those, I will report it too. Thanks.
Thanks for reporting back. That's a shame that automatic retrying isn't going to help then. This might be something that has to be fixed on Chrome, unfortunately.
I just got the error with Edge! So ti happens both wih Edge as with Chrome (but of course, Edge runs on Chromium). The auto retry fix does nor work, because you explicitly click the 'OK' button in the error Window. I guess it is more of the same, but here is the error window message KeePass Specified cast is not valid. InvalidCastException (0x80004002) @ System.Object get_accRole(System.Object) at Accessibility.IAccessible.get_accRole(Object varChild) at WebAutoType.AccessibleObjectHelper.AccessibleObjectMatchesConditions(IAccessible...
Hi, I have the update installed, but the auto retry does not seem to work. I get a sound notification when I tried the autotype in Chrome, but still had to go to KeePass and click 'OK' in the message window 😁
Hi, I have the update installed, but the auto retry does not seem to work. I get a sound notification when I tried the autotype in Chrome, but still had to go to KeePass and click 'OK' in the message window 😁
Thanks for reporting back. I have created a possible workaround fix, as you say that if you just try again on the same site then it works. With the attached, WebAutoType will detect the error and automatically retry once to see if it is just an intermittent fault. If it still fails, the error will be reported normally. If you try this, and still see the error, then the only other option may be to have it simply ignore it, but having it silently fail to find the window is not necessarily an improvement...
Just had the issue this morning... With Chrome... Will let you know as soon as (and if) I experience the issue with Edge too.
My default browser is Edge, but I do use Chrome (and even some other browsers). Next time, I will pay attention which browser is concerns as it indeed might be browser specific.
OK, thanks for letting me know. If it doesn't actually cause KeePass to crash out or stop working then it's not so serious, but still irritating. Is it Chrome that you are using, or one of the other Chrome-based browsers?
This seems to happen randomly on various sites, hard to reproduce 😔. When it happens and I close the error window, I can just pres CTRL+ALT+A on my keyboard again for that same site and it just works fine.
My bad. It works after updating WebAutoType to 6.9.1. Thanks.
WebAutoType (file version 6.9) stopped working on two different Windows systems both using FireFox 138.0.3 (32/64 bit). It does not detect, anymore, URLs opened in FireFox. I don't think something has recently changed. KeePass has not been updated (2.58 64bit). Both systems (a PC and a Server) are managed by different persons, and connected to different networks. I am short of ideas, on what could have gone wrong, or what to do. Any suggestion is welcome. Tks.
This is certainly coming from WebAutoType, but I don't know whether it's a bug or not. Does it only happen with a specific website? Are there steps you can take which make it happen reliably? From the stack trace you've supplied it does not look like something WebAutoType can fix, as it's happening internally within the Windows accessibility code, but it should at least be possible to trap it and not crash when it happens, instead just failing to auto-type.
Sometimes, when I use the KeePass auto type, I get this error screen and KeePass blocks until I close the error window: specified cast is not valid I am now runnig KeePass with the debug option and got some more information. It looks like it has to to with this plugin. I just upgraded from version 6.9.0.0 to 6.9.1.0, so maybe the problem is solved now. I did not find any tickets regarding this subject, so I will post the error info here anyway: KeePass Specified cast is not valid. InvalidCastException...
Sometimes, when I use the KeePass auto type, I get this error screen and KeePass blocks until I close the error window: specified cast is not valid I am now runnig KeePass with the debug option and got some more information. It looks like it has to to with this plugin. I just upgraded from version 6.9.0.0 to 6.9.1.0, so maybe the problem is solved now. I did not find any tickets regarding this subject, so I will post the error info here anyway: KeePass Specified cast is not valid. InvalidCastException...
Sometimes, when I use the KeePass auto type, I get this error screen and KeePass blocks until I close the error window: specified cast is not valid I am no runnig KeePass with the debug option and got some more information. It looks like it has to to with this plugin. I just upgraded from version 6.9.0.0 to 6.9.1.0, so maybe the problem is solved now. I did not find any tickets regarding this subject, so I will post the error info here anyway: KeePass Specified cast is not valid. InvalidCastException...
Unwanted capitalization
No problem, thanks for letting me know
Thanks for your idea to isolate auto-type behavior. I have never used KeePass without your plugin , so it was hard to remember how to check this behavior without =). I checked the auto-type sequence by using "Perform auto-type" directly from the DB, and everything was OK. The real cause of the problem is related to the Windows setting "Touchpad > Advanced gestures ." I have a custom shortcut, "Shift + Alt + Z," for a four-finger tap. And I can reproduce this behavior only when using the touchpad,...
Are you sure this is related to WebAutoType? It should not affect the AutoType key-sending mechanism itself. Does it not happen if WebAutoType is not installed?
Unwanted capitalization
Oh great, good news, thanks.
The problem disappeared after a new browser update to version 6.7.3329.14
Thanks for letting me know, I will look into this next week.
WebAutoType relies on Windows accessibility interfaces to obtain the URL for the web page, so this will not work under Linux. There are probably equivalent accessibility mechanisms for Linux (possibly different for each different window manager), but I don't know them, or how to access them from mono.
Plugin can't be installed on Linux
WebAutoType relies on Windows accessibility interfaces to obtain the URL for the web page, so this will not work under Linux. There are probably equivalent accessibility mechanisms for Linux (possibly different for each different window manager), but I don't know them, or how to access them from monom
The plugin stopped working on Vivaldi 6.7.3329.9 x64 after updating the browser. Win11x64. Checkboxes ("Native accessibility API support" and "Web accessibility")both checked
The plugin stopped working on Vivaldi 6.7.3329.9 x64 after updating the browser. Win11x64.
The plugin stopped working on Vivaldi 6.7.3329.9 x64 after updating the browser
Plugin can't be installed on Linux
v9.6.1 Fix support for Firefox 125
Sorry to hear that. I'm afraid I'm out of ideas, though, I don't know why it isn't working for you.
Sorry I missed your comment somehow. Doesn't matter which options are checked. Doesn't work even if all of them are checked.
Doesn't work for me either way.
Thank you for the information. The docs you link to suggest that "complete" should be the default for that flag if unspecified, but if your experience is that it only works properly when included explicitly then that's good to know.
I wanted to note for anyone struggling that may help, the "--force-renderer-accessibility" flag in Chrome no longer works, this changed a little while back. The flag you actually want to use is "--force-renderer-accessibility=complete". Have had immensely better luck running this way. https://chromium.googlesource.com/chromium/src/+/main/docs/accessibility/overview.md#command-line-options Keep in mind though, if you edit your desktop shortcut for Chrome to add this flag it could stop working as the...
Drat. Thanks for all the fast answers though!
Yeah, basic authentication is a total pain because the dialog appears before the page loads at all, and there's no accessibility clues inside the dialog to say which url it belongs to. https://sourceforge.net/p/webautotype/tickets/43/ tracks this, but I don't have any way to fix it.
I only had about 5 tabs open in Firefox and four in Brave. In the drop down (open or closed) the cursor stops blinking after 6 blinks. WebAutoType Create Entry hotkey was unable to get any URLs. I did another test too. I logged in past the basic authentication prompt and then in a console window I ran some JavaScript to force a log out. var p = window.location.protocol + '//' // current location must return 200 OK for this GET window.location = window.location.href.replace(p, p + 'logout:password@')...
From your description it sounds like it is populating the URL dropdown, just slowly. Either Brave or Firefox is responding very slowly to the UIA requests - do you have hundreds of tabs open? In any case, try leaving the dropdown open for a while and see if it eventually populates. Of course manually typing the URL is a very valid approach too, particularly if you're going to need a wildcard! Another useful diagnosis is to set the WebAutoType Create Entry hotkey, then with the focus in the login...
Update: I've rebooted PC. Still no joy in Firefox When I have Firefox and Brave both open, the drop down in the Target URL auto populates with the URL from the active tab in Brave. Sometimes. It looks like the list fills up with several URLs and then blanks itself again really fast. Too fast to read what URLs showed up in there. Is there anything I can do to help diagnose the issue? I'm a developer, just not on Windows. So far I've been manually typing in https://my.url.org*since I can hit this server...
Update: I've rebooted PC. Still no joy in Firefox When I have Firefox and Brave both open, the drop down in the Target URL auto populates with the URL from the active tab in Brave. Sometimes. It looks like the list fills up with several URLs and then blanks itself again really fast. Too fast to read what URLs showed up in there. Is there anything I can do to help diagnose the issue? I'm a developer, just not on Windows. So far I've been manually typing in https://my.url.org*
Update: I've rebooted PC. Still no joy in Firefox When I have Firefox and Brave both open, the drop down in the Target URL auto populates with the URL from the active tab in Brave. Sometimes. It looks like the list fills up with several URLs and then blanks itself again really fast. Too fast to read what URLs showed up in there. Is there anything I can do to help diagnose the issue? I'm a developer, just not on Windows.
Update: I've rebooted PC. Still no joy in Firefox When I have Firefox and Brave both open, the drop down in the Target URL auto populates with the URL from the active tab in Brave. Sometimes. It looks like the list fills up with several URLs and then blanks itself again really fast. Too fast to read what URLs showed up in there.
Brave should work, it's just another Chromium browser. Might need to enable accessibility manually if they've disabled it, though, try going to chrome://accessibility/ and check Native Accessibility, Web accessibility are turned on. I've had some reports that Screen Reader Support is also needed, but it isn't for me. An alternative to chrome://accessibility is to add the "--force-renderer-accessibility" parameter to the browser command line. Addons shouldn't be an issue, I don't believe browsers...
So far the only thing I've not done is reboot the PC. That's next. Is this expected to work using the Brave browser? It does not on mine. I've tried in main windows and also "private windows" On both Brave and Firefox I have several script blocking programs (On each browser I have some combination of uBlock Origin, NoScript, Ghostery, Privacy Badger) and on Windows I have the Controlled Folder Access turned on - might these be interfering?
Those about:support values look OK for 121.0.1, the only difference with mine is that the Accessibility Instantiator starts "UNKNOWN" instead of "UIAUTOMATION", but that seems unlikely to indicate a problem. I don't know why it's not working for you, I've just tried on 121.0.1 successfully. I assume you've already tried things like restarting the browser, and KeePass?
Firefox 121.0.1 and the problem appears to have returned. The about:config Accessibility settings do not look like the ones you mention above. Activated true Prevent Accessibility 0 Accessibility Instantiator UIAUTOMATION|D:\Program Files\KeePass Password Safe 2\KeePass.exe WebAutoType v6.9.0
Firefox 121.0.1 and the problem appears to have returned. The about:config Accessibility settings do not look like the ones you mention above. Activated true Prevent Accessibility 0 Accessibility Instantiator UIAUTOMATION|D:\Program Files\KeePass Password Safe 2\KeePass.exe
Does it work if the "screen reader support" option is checked?
Despite a lot of tabs being open both in Chrome, and in Edge, Target URL drop-down is always empty. My auto-type rules created a few years back that were working back then, also don't work.
Despite a lot of tabs being open both in Chrome, and in Edge, Target URL drop-down is always empty.
Edge 120.0.2210.77 Chrome 120.0.6099.72 Windows 10 Pro 22H2
What version of Chrome, WebAutoType and Windows are you using?
I have the same problem both in Chrome, and in Edge. All accessibility features are enabled, but the plugin can't find any URLs. The URL dropdown is empty when I try to add a new AutoType entry, regardless of what is open in the browsers.
Thank you for your response! I am sure I checked both of the two boxes, but the plugin still couldn't work properly. However, after reinstalling the latest Chrome browser, the plugin is now working properly!
Check chrome://accessibility/, the first two checkboxes ("Native accessibility API support" and "Web accessibility") should both be checked. That should happen automatically, but in case it doesn't you can check them manually.
The plugin works fine on Firefox. Even though I've followed the instructions in the README(launching Chrome with the "--force-renderer-accessibility"), it still doesn't work on Chrome. Do you have any further suggestions to help me? My Chrome is version 118.0.5993.71.
I checked the about:config page but it seems like the default value for accessibility.cache.enabled on the latest version of mullvad (12.5.3) is true. The error i get is "The method or operation is not implemented."
I checked the about:config page but it seems like the default value for accessibility.cache.enabled on the latest version of mullvad (12.5.3) is true.
Great, thanks for letting me know. KeePass have changed their recommendation to use .dll instead of .plgx for plugins, unless using a custom build of KeePass. It doesn't really matter if you use either .dll or .plgx, or even both. The .dll should override the plgx if both are present in the plugins folder.
Works like a charm. Thumbs up for Alex. Great support.
O.K. - with the dll included and stored in the same directory as the plugin, it works as before!
I took only the plgx-file, not the dll - or do I have to? And if, where to place it! Only with the plgx it does not work!
WebAutoType should list active tabs, not background tabs, in the dropdown, so that behaviour is correct. I think the issue is the sidebar, whether that contains Bookmarks or Tree Style Tabs. Please give the attached v6.9.0 candidate a try and let me know if it resolves the issue for you.
v6.9.0 Release both plgx and dll
Support Tree Style Tabs in Firefox
I have a similar setup (without Free Style Tab) but using WebAuto Type and since last update of Firefox I also have an empty dropdown select box in KeePass selection of the URL for autotype. Update: Interesting! I also have the Bookmar sidebar open and after closing it the dropdown is filled with the URLs of the active Tab in Firefox. Not all URLs from all Tabs. This is probably worth a ticket!
I have a similar setup (without Free Style Tab) but using WebAuto Type and since last update of Firefox I also have an empty dropdown select box in KeePass selection of the URL for autotype. Update: Interesting! I also have the Bookmar sidebar open and after closing it the dropdown is filled with the URLs of the active Tab in Firefox. Not all URLs from all Tabs.
I have a similar setup (without Free Style Tab) but using WebAuto Type and since last update of Firefox I also have an empty dropdown select box in KeePass selection of the URL for autotype. Update: Interesting! I also have the Bookmar sidebar open and after closing it the dropdown is filled with all URLs used. But only the last Tab active. Not all URLs from all Tabs.