Hello team,
I am usiing keyman keyboard for my shopify store, I have added the code and it’s working fine in the mac safari but when I switch to the chrome or Mozilla browser, its not working,
I am only showing it on my product input field.
here is my store URL: https://casadoriente.com/?&preview_theme_id=175978545479
and here is the password for my website: 01012025
I am attaching a screenshot of the field where I am showing the keyboard.
Hi, I am seeing the keyboard and it appears to be working in Chrome on my machine.
I can see that KeymanWeb is loading in your screenshot, because you have the language picker visible. It may be that something else is failing to load?
Can you use Developer Console in Chrome (… menu, More Tools, Developer Tools) to look for any console errors that may have been reported and let us know here?
I want it like, when someone clicks on the input field the keyboard should appear automaticaly without, even selecting the language at first place, so the English to Arabic should already selected by default. I don’t want them to select the lagugage first, but I don’t know how to disable the selector.
These help pages describe how to have more control over the keyboard and language selector (including creating your own language selector if you prefer): Additional KeymanWeb Usage Examples
Hello Marc, thanks for the help, but I have already tried them, in my website, and the problem is still persist, I have created a video for that, but I can only upload images to this reply board,
here is my code that I have implimented in my website:
I also want to share a video regarding my issue, can you please tell me from where I can share it.
script tag src=’ https request .keyman.com/kmw/engine/17.0.335/keymanweb.js" type=“text/javascript”> script tag ends
script tag src=“https request .keyman.com/kmw/engine/17.0.335/kmwuitoggle.js” type=“text/javascript”>script tag ends
script tag
keyman.init({attachType:'auto'});
keyman.addKeyboards({
name: 'SHIFT FOR EMOJIS',
id: 'sil_arabic_phonetic',
filename: 'file destination',
version: '1.0',
language: [{
name: 'English to Arabic',
id: 'arabic',
}]
});
keyman.addKeyboards({
name: 'SHIFT FOR EMOJIS',
id: 'basic_kbda2',
filename: 'file destination',
version: '1.0',
language: [{
name: 'Arabic',
id: 'basic',
}]
});
script tag ends
body tag onload=“SetupDocument()”
-----jquery cdn-----
script tag
$(document).ready(function(){
$(‘input.pplr_text.pplr_monogram.keymanweb-font’)
});
script tag ends
script tag type=“text/javascript”
function SetupDocument() {
keyman.init({
root: ‘./’,
ui: ‘toggle’,
resources: ‘./’
}).then(function() {
// loadKeyboards(); // Load keyboards AFTER Keyman initializes
keyman.setKeyboardForControl(
$(‘input.pplr_text.pplr_monogram.keymanweb-font’)[0],
‘sil_arabic_phonetic’,
‘arabic’
);
keyman.setActiveKeyboard(‘sil_arabic_phonetic’, ‘arabic’);
}).catch(function(err) {
console.error(“Keyman initialization error:”, err);
});
}
$(document).ready(function(){
window.addEventListener(‘load’, SetupDocument);
});
script tag ends
body tag ends
I have replace the tags with the alphabets
I just went and checked from my end - it’s working fine in Firefox and Chrome on macOS, the way you expect it to. The keyboard appeared the moment I clicked into the “Your Statement” field. I get the same on Firefox with Windows as well.
That said, I got lazy when trying it out on the last case at first, and I skipped the ?&preview_theme_id part. The site generally seemed to work well, except that it didn’t even try to load Keyman Engine for Web or the keyboard! (It looks like that part of the URL is indeed important.) This can’t lead to the reported circumstance, though, so I’ll leave this detail at that as a personal warning not to repeat my laziness error.
One other thing, though: I see that you have two separate init calls in your page: line 536 and line 1971 (when viewing source). This really shouldn’t affect things, but I did notice one case where part of your setup failed (thus causing the keyboard not to appear automatically) due to a possible side effect of the two inits. Again, we should be making sure things work fine regardless of the init count, but it looks like we missed something subtle in that regard - I’ll write up an issue for it.
The case in the paragraph above would in fact result in the screenshot you’re reporting here, so it’s certainly worth looking into on our end. The thing is, though… I can’t get it to cause a problem consistently. I only triggered it once, and it wouldn’t repeat when I tried to investigate it more closely. Is this happening consistently for you?
Fortunately, I remember enough about the errors I saw to record some pretty critical observations. The important error that I saw involved the following:
No matching stub has been registered” was the error message.keyman.setKeyboardForControl failed (line 1978) appeared in the stack trace as the triggering call, within the later init’s then clause.addKeyboards info to boot - no cloud query required… and outside of the Promise-chain of either init call.OK, I’ve written up an issue for that at bug(web): poor handling of multiple `init` calls; can lead to unexpected errors · Issue #13278 · keymanapp/keyman · GitHub.
I doubt we’ll backport a fix to Keyman 17 at this time, so it may be wise to rewrite things to use a single init call if possible.
Took some time today to investigate more thoroughly, and I think I’ve figured out what the issue is. Your dual init scheme is fine, but I’d change change your earlier Keyman initialization block like so:
keyman.init({
attachType: 'auto'
}).then(function() {
keyman.addKeyboards({
name: 'SHIFT FOR EMOJIS',
id: 'sil_arabic_phonetic',
filename: '//casadoriente.com/cdn/shop/t/40/assets/sil_arabic_phonetic.js?v=90679577857814663911738067428',
version: '1.0',
language: [{
name: 'English to Arabic',
id: 'arabic',
}]
});
keyman.addKeyboards({
name: 'SHIFT FOR EMOJIS',
id: 'basic_kbda2',
filename: '//casadoriente.com/cdn/shop/t/40/assets/basic_kbda2.js?v=155236329126653460221738067436',
version: '1.0',
language: [{
name: 'Arabic',
id: 'basic',
}]
});
});
Putting the addKeyboards calls within that then() clause will prevent the error I was able to find and reproduce.
Hi there @joshua_horton and @Marc many thanks for your help so far - it has been a tricky one. It seems to be now working correctly on Windows. On MacOs however the occuring problems depend on the used browser.
Chrome on MacOs: KeymanWeb does not appear / work at all. When the Keyman UI appears and one tries to choose a keyboard it simply does not appear and makes the user jump back to the top of the page.
Safari on MacOS: If the KeymanWeb loads then it does so without the toggle UI to choose between the keyboards. This is very random. Sometimes it works, sometimes not. Sometimes only on one of the two pages.
Attached you can find screenshots of the console from chrome and safari on windows and macOs.
We are trying to have KeymanWeb working on www.casadoriente.com and iPhone 15 Pro Case - Smaragd Green.
Thank you very much for your help guys!
Hi @Mohamed_Mohamed, @joshua_horton is away this week but he’ll take a look when he gets back next week; he’ll be able to dig into the issues with you. (I am mostly on Windows so I can’t really investigate deeply.)
Hi @Marc, thanks for letting me know!
Hello again, just getting back to this.
Using the provided URLs, I’m not getting those errors at this point. Did you continue to work on it and find a solution for the issues? I’m using macOS Sequoia 15.3, in case that matters. While I’m at it, the browser versions are Safari 18.3 (20620.2.4.11.5) & Chrome 134.0.6998.89.
I did note this appear in the console at one point:
keymanweb.js:30 Error: Sorry, the SHIFT FOR EMOJIS keyboard for English to Arabic is not currently available.
at keymanweb.js:4:12918
keymanweb.js:4 Uncaught (in promise) Error: Sorry, the SHIFT FOR EMOJIS keyboard for English to Arabic is not currently available.
at keymanweb.js:4:12918
If something is causing the script to load slowly, this can result. I remember my initial visits to your site requiring a significant wait time for pages to load - if that’s still happening for the keyboard script files, that’d do it. That said, the site does feel like it’s loading much more quickly than a few weeks ago.
Also, I happened across a lot of these:
(index):2397 Uncaught TypeError: Cannot read properties of null (reading 'classList')
at HTMLDocument.<anonymous> ((index):2397:26)
Viewing the page’s source and inspecting it points to the following block:
document.addEventListener("scroll", function () {
const scrollColorSection = document.querySelector(".scroll-color-section");
const footer = document.querySelector("footer");
const footerBottom = footer.getBoundingClientRect().bottom;
if (window.scrollY > footerBottom) {
scrollColorSection.classList.add("scroll-color-active");
} else {
// scrollColorSection.classList.remove("scroll-color-active");
}
});
Putting document.querySelector(".scroll-color-section") into the JS console returns null; it looks like some recent changes dropped or renamed your element and have led to this error.
Hello @joshua_horton,
I have resolved the “classList” issue.
I also noticed a large white space appearing right after the footer in the mobile view of the website. I believe this is caused by a <div> element generated from the Keyman code. To verify, I commented out the Keyman code and refreshed the website, and the white space disappeared.
Please check this issue as well.
Is the Keyman code still commented out? It appears to be when I try to check this out in Chrome, and that makes it hard to investigate the issue.
That said, we do tend to add such a “large white space” on touch devices. If we didn’t add any space after the footer, it would not be possible to see (at least part of) the footer while the keyboard is active - which can be quite a problem if you’re using the keyboard to type into an element in the footer!
I think I see what you’d be calling an issue, though: we don’t hide this “page trailer” when the keyboard isn’t active, meaning a user can still scroll past what should be the bottom of the page. We also do nothing to help it match your page’s formatting at that location.
(Internal note: search for buildPageTrailer().)
Does this sound like it describes the behavior you saw?
Yes, I have commented the code, because of the old issues on MacOs and the big white space after the footer.
However, I have now reopened the comment tags so you can check the issue.
Please have a look and let me know if you need any additional details from my side.
theme URL: CASA d'ORIENTE
Password: 01012025
Yep, seems like that lines up.
I’ve gone ahead and documented this as bug(web): blank space at bottom of page in mobile use is visible when keyboard is not active · Issue #13588 · keymanapp/keyman · GitHub.