Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Trying to enter text in comment box, typing `s` causes search to grab focus, eat letter. #1026
I added the "isso" self-administrated/serviced comment function to in place disqus and found the letter 's' (also 'S') can't be entered because that key causes the searchbox to grab the focus, eating the letter in the process.
I couldn't tell you if disqus avoids this because I haven't tried disqus.
I believe this is related to issue #400. One comment noted that
Indeed - that
I tried this both in the main text and overriding the
As long as I don't type 's' or 'f' (any others?) I can successfully send a message.
Any help would be greatly appreciated.
This really is a great piece of software - kudo to squidfunk and to the whole stack.
Description of the bug
What you expected to happen
Plain letters typed into a text don't cause another box to grab focus.
Steps to reproduce the bug
Go to (https://craigphicks.github.io/privca/) and scroll to bottom.
# Project information site_name: 'Server/Client 2-way Authentication w/ Private CA' site_description: 'Step by step guide to issuing private certs for Server and Client Side Authentication - specifically *lighttpd* and *Firefox*' site_author: 'Craig Hicks' site_url: 'https://craigphicks.github.io/privca' # Repository #repo_name: 'craigphicks/privca' #repo_url: 'https://github.com/craigphicks/privca' # Copyright copyright: 'Copyright © Craig Hicks 2019' # Configuration theme: name: 'material' language: 'en' palette: primary: 'indigo' accent: 'indigo' font: text: 'Roboto' code: 'Roboto Mono' # Customization extra: manifest: 'manifest.webmanifest' social: - type: 'github' link: 'https://github.com/craigphicks' # # - type: 'twitter' # # link: 'https://twitter.com/squidfunk' # # - type: 'linkedin' # # link: 'https://linkedin.com/in/squidfunk' # Google Analytics # google_analytics: # - 'UA-XXXXXXXX-X' # - 'auto' # Extensions markdown_extensions: - attr_list - admonition - codehilite: guess_lang: false - toc: permalink: true #extra: # disqus: 'your-shortname' theme: name: 'material' custom_dir: 'custom'
I still have the issue when contenteditable is set to "inherit" like in Hotjar feedback form.
I don’t really think going further into this direction will provide any value. Skipping textareas might work for your case but then other cases might emerge. I would really favor some research on what we need to do before adding more and more edge cases.
I agree, but I don't see what property we could target to prevent testing for this type of hedge case. Any idea ?
And I had this page as reference https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/contentEditable stating that inherit is a possible value.
This looks like a good candidate solution that is generic. Browser compatibility looks promising, though no data on Opera and Internet Explorer. Could you adjust the source, test it (also in those browsers), and if it works make a PR? Happy to merge.
Oh, didn't know that. Also I understand that Hotjar is widely used. As stated above - I'm happy to collaborate on a PR.
The issue I face is that TEXTAREA are not contentEditable, they are just natively capable to have text. So you can't base detection on these properties. It's the same thing for INPUT. The only thing is to test on tagName. What do you think ?
So my proposal would be to add :
added a commit
Apr 5, 2019
Well for a quick fix I tried to change
to any other keycode: 70 --> 10 etc.
This is my material pip setup: