#37 URL drop down does not work with any browser and makes KeePass 2 crash

[Raúl Núñez de Arenas Coronado]

Hi!

I don't know when did the problem start, because I've not been adding or modifying entries needing URL matches, but now if I try to add a new URL match using the dropdown in the AutoType tab of an entry, that dropdown is empty (tested with latest stable Chrome, Firefox and Edge).

The dropdown is empty no matter if I activate --force-renderer-accessibility in Chrome or not, if I launch the browsers before or after launching KeePass, etc.

The URL match works if entered by hand, though, so the plugin seems to actually access tab titles and match against them.

I can't find the crash log for KeePass so I can't provide more information, but I'm ready to carry any need test if it is in my hands.

Thanks in advance!

[AlexVallat]

Hi, thanks for reporting this. I haven't been able to reproduce it here. Are you using Windows 10, or 11? Can you try setting up and using the Create Entry from Web Page hotkey and see if the URL is correctly filled in when creating a new entry from a web page?

[Raúl Núñez de Arenas Coronado]

Windows 10, 21H1, build 19043.1320.

I've set things up and tried what you suggested. It fails for Chrome and Edge, works for Firefox. If fails for Chrome EVEN launching Chrome with --force-renderer-accessibility.

After this test I tried again and the dropdown again causes a crash.

I could not locate the crash logs for KeePass BUT it appears in my Event Viewer, where it appeared as TWO errors, one in KeePass 2 itself, the other in the .NET runtime. I'm attaching the XML versions of the two errors.

If you need me to carry more tests, just ask. I'm not familiar with C# so I'm afraid I won't be of much help by checking the code, you're much more familiar with it. But anyway, if I can be of any help just ask.

[AlexVallat]

Thanks for the additional logs, the dotnet.xml one is useful, in that it at least tells me where the error is, if not why! Please try the attached 6.8.1 and see if you get any better result.

If not, my best idea is that there is some running software that WebAutoType is trying to read as a browser, but it isn't a browser and is causing a crash of some sort. If you can try closing any other software to see if it resolves the issue, then we might be able to narrow down which one is causing the incompatibility and then I can put in a special case for it.

[Raúl Núñez de Arenas Coronado]

OK, now KeePass 2 does not crash as frequently, but it crashes. Took me a few tries but it crashed. I'm attaching the new logs, just in case.

On the other hand, the dropdown tests were as follows:

• Firefox: the dropdown works, and adding a new entry works, too. Switching tabs properly updates the URLs shown in the new entry when the hotkey is pressed.
• Chrome, launched with --force-renderer-accessibility: the dropdown only shows the active tab, and adding a new entry works. If tabs are switched, nothing works anymore, the drop down is empty, not even showing Firefox tabs, and adding a new entry using the hotkey shows an empty URL.
• Edge: does not work. Probably because accessibility can't be enabled like in Chrome.

If you want, you can send me a new plgx which dumps some kind of log, listing the apps it founds, no matter if they will be used to populate the dropdown or not, to check which one is causing the problem. Just an idea, since you can't access my system to carry tests! I can test whatever you send me.

The only thing I can't do is building the plgx myself: the computer I'm using now does not have development tools, I'm not allowed to install such tools (at least for now) and I can't access other computers right now (long story short: ankle sprain, I can't move from home for the time being). Other than that, I'll try to test anything you want me to.

Thanks A LOT for your help, really :)

[AlexVallat]

Strange. My best guess based on those errors is that the population of the dropdown is stalled or taking too long, then you close the window and when it finally tries to add the items to the list it crashes because the list doesn't exist any more.

I've added a guard to just not add items to the list if it doesn't exist, this should hopefully resolve the crashing, but may possibly mean that when it would have crashed, the list is empty. Still better than crashing.

[Raúl Núñez de Arenas Coronado]

Before testing the new version, I have to tell you that you NAILED IT! Effectively, the problem was the list was taking ages to populate, probably more than one minute in this otherwise fast computer. And the problem was caused by Chrome (probably Edge will cause the problem, too). Chrome active tab can be obtained even if launched without --force-renderer-accessibility, but the dropdown list was taking too long to populate.

Funnily enough, when the list was finally populated, any tab switching caused it to refresh almost instantly even when the tab switching happened in Chrome.

So, now that the cause of the problem has been identified, and even though the guard was a very good idea anyway, do you want me to test why is this happening with Chrome? I mean, it should be quite fast to access the list of tabs, so if you want me to test anything so you can spot where the list population is stalled, just ask.

I've tested the new version and it seems to have fixed the crashing issue, yes. Or at least, I'm not able to reproduce it easily as before.

Oh, and of course, THANKS a lot :)

[AlexVallat]

Accessibility can be fickle, unless I can reproduce it here (and quite often, even when I can) there's not a lot I can do about browsers giving slow, wrong, or absent information. I will poke around with Chrome, though, see if I can find anything.

So, the issue is, slow population of the list when Chrome 95(?) is running, without --force-renderer-accessibility enabled. Do you have any extensions installed, or a large number of tabs open, or anything else unusual that I should try and replicate to make the problem occur?

[Raúl Núñez de Arenas Coronado]

Yes, I'm using Chrome 95. The list is populated slowly without --force-renderer-accessibility, but with it enabled it happened too: the active tab was found fast, but after a tab switching the list didn't reflect the change and the updating was slow, too.

I don't have any extensions in Chrome apart from Chrome Remote Desktop (inactive) and Google Drive App Menu (inactive, too), and usually I have a couple tabs opened. I mean, sometimes when working I can have even 20-30 tabs opened, but right now I only had GMail, WhatsApp and a couple others for testing purposes, so I don't know why the list is populated slowly.

As for any other unusual things in my Chrome setup, I can't think of nothing else. This is a temporary computer I'm forced to use so it's quite a simple setup. Also, the problem happens with Edge, too, so it may be related to some Chromium behaviour.

Frankly, I'm at a loss here, I don't know if there's some safe, standard way of getting the url for the current tab in a browser. I've searched a bit and it seems like there various ways depending on the browser, at least in C#, but I'm no expert and haven't even read WebAutoType code yet, so there's nothing I can suggest at this point.