#2 · closed · 11 comments
Firefox 83.0 32-bit, Windows 10. 1. On New Tab command (via toolbar button or Ctrl-T or mouse gesture) the new tab opens with the LocationBar focused, but the Keyboard Layout doesn't change to the set layout. If the new tab was opened by middle-clicking on the Home button (LocationBar is not focused) then the layout changes.
2. LocationBar and FindinPage are not recognised and thus layout is not being changed accordingly.
Thanks for reporting this. Could you give the attached 1.2 candidate a try and let me know if it works for you? [KeyLayoutAutoSwitch.zip](https://github.com/AlexVallat/KeyLayoutAutoSwitch/files/5658335/KeyLayoutAutoSwitch.zip)
V. 1.2 works in general though I am experiencing some difficulties with it. Maybe it's all by design, but here they are: Baseline: All integrated rules are set to English except for "Find in Page". No custom rules. 1. "Find in Page" = "Do Not Change Keyboard Layout" Open tab with some web page. Switch to alternative keyboard layout. Open Find in Page bar. Layout does not change. Return to web page. Layout of tab-content changes to English. Expected behaviour - keep the original layout of the tab-content. 2. "Find in Page" = "Use the same keyboard layout as the web page" Open tab with some web page. Switch to alternative keyboard layout. Open Find in Page bar. Layout changes to English. Expected behaviour - keep the keyboard layout which was selected for the tab-content. Return to web page. Layout stays English. Expected behaviour - keep the original layout of the tab-content. Suggestion Is it possible for the rule "Previously visited web page" to be available a third option "Remember current tab-set layouts" (or something along the lines) which allows KeyLayoutAutoSwitch to remember the layouts for the currently opened tabs (and change layout when tabs get activated), but to "forget" the layout of a tab when it gets closed (or the browser gets closed, too). I.e. some sort of a Volatile tab layout memory. In this case the layouts maybe should be attached to the tab-id, not the web-page URL, or at least to the site part of the URL (not the full URL). For example, stick the layout to www.yahoo.com or www.cnn.com and keep it while browsing this whole site regardless of the current html page/level/directory.
For case 1, if you have "Previously Visited Web Page" set to "Restore previously set layout", then when returning from Find in Page to the web page, the layout will be set back to whatever it was immediately before entering Find in Page. If "Previously Visited Web Page" is not set, then the normal rules will apply: either a layout will be chosen based on the URL or the "Other web pages" entry. For case 2, yes, the behaviour with "Use same layout as web page" doesn't seem to be working properly, I will investigate.
OK, I think the attached should fix the issue with "Find in Page" and "Use same layout as web page", it will now correctly apply the rule for the web page to the "Find in Page" box when selected. I don't think I can attach to a tab instead of a URL, there's no useful ID that I can access. If you want a language to apply to a whole site, that's what the rules are for! You can make them specific to just the site part, or even just the domain part. [KeyLayoutAutoSwitch.zip](https://github.com/AlexVallat/KeyLayoutAutoSwitch/files/5659810/KeyLayoutAutoSwitch.zip)
Wow, you are really dedicated to this project! Such a quick response! Thank You very very much for this usefull tool!! OK, tomorrow I will try the new version. The reasons for me asking for this third option are these: My primary language is Bulgarian. Not all bulgarian web sites are in the .bg domain. Many are registered in .com or .org or .net. I cannot possibly pick those one by one and create specific rules for them. Plus, very often I use english language even on bulgarian sites in the .bg domain. Would it be too much to ask for this third option **based on site** and not on the whole URL (for example www.google.com, mail.yahoo.com, www.government.bg etc.). More often than not it would be usefull to keep the layout when clicking on links pointing to a page on the same site. Also if it is possible to make the remembering of the layouts between browser restarts optional would be great, otherwise one could never be sure what was the layout when they last visited this site/URL. Even if nothing of this is possible, at least it was nice to dream about it ;-) Thanks again!
I'm certainly interested in hearing your workflow, to try and improve this app if possible. From what I can tell, the actual switching behaviour already meets your requirements, it's just too inconvenient to create site rules. How about if there was an option for a hotkey to create a rule for the current site and keyboard layout? So if your were on a .com site which you wanted to be in Bulgarian or a .bg site you wanted in English, then the workflow would be that, when you have a tab of that site open, you switch to they keyboard you want and then hit the hotkey. A window would open allowing you to customise the URL and language (or just accept the defaults) and a rule would be created for that site. Which would, of course, persist over browser restarts.
Find in Page works as intended now. A hotkey (and I would suggest a tray-icon menu item) for creating site-specific rules would be very helpful! I am filing another issue regarding situations with multiple layouts for the same Language.
Hotkeys are a complete pain to do, so I'll do a tray-icon menu item first, when I get some time, and see whether that's sufficient. I will investigate your other issue #3
A question: Wouldn't it be usefull to have another integrated rule "Previously visited web sites", which would work just as the "Previously visited web page" rule, but based on the site and not on the entire URL? I.e. all web pages under the same site (e.g. www.google.com) should stay on the same layout (default or user-selected). Maybe those two should be made alternatively selectable (one or the other)? I should have opened a new Issue with this topic a few posts ago...
I have moved discussion to #4 as this is not really relevant to the original issue here, you're right. Unfortunately GitHub doesn't make that easy...