In Chrome and Firefox, if you press "enter" on the results page, it will progress you to the next vocab word. However, if you do this in Safari, it does not progress the view. If you press enter, it doesn't progress, and then click "Show the next question," the vocab page has the warning "Press 'Enter' again to submit. (Don't show this warning again.)"
Additionally, when clicking through on "Show the next question," the text input does not gain focus. It makes Safari a nearly unusable browser for vocab review.
Thanks for the report! There have been some related (or possible same) issues that have been patched up in the beta version of the site. Before I dig into this, could you please join the beta (it's under the Help menu, and you can leave anytime) and see if the problems still persist?
This may require some trial and error, as I don't have an operating Mac device in front of me anymore, but I'm sure I can get it taken care of! Will let you know when I've made some progress.
and press the enter/return key (whatever you are trying to press) and see what it tells you. I'd also love to know if it returns something different depending on the browser you are using.
No change in study behavior. I didn't notice this before, but I did notice in my most recent testing that numbers no longer work for selecting multiple choice answers in Safari. Was unable to verify the bug in Chrome at this time. But the "enter" key I'm pressing on the internal keyboard returns the same keycode in Safari as it does in Chrome.
event.key: Enter event.location: 0 event.which: 13 event.code: Enter
Same story with the numbers. They are identical to their chrome equivalents.
I'll run my review with chrome on macOS in beta to see if I can duplicate the multiple choice answer bug when I get a chance and get back to you.
I've got good news! Your "the number shortcuts don't work" was a BIG hint, thank you.
Please test it and see if it works.
If you're interested, here is the craziness that caused the issue:
When anything (app, browser, carrier pigeon) connects to the site, it does a quick check to see if it is a mobile device or not. A few things change on the site if you are mobile. One of them is that it doesn't bother to load up the keyboard shortcuts since there is no keyboard.
Now, there is an additional check to see if it is coming from the android app. App is considered mobile (of course). The way that safari presents itself to the browser was tripping up my app check, and renshuu assumed that safari was the app, so it was therefore mobile, which means no shortcuts!
Going to go ahead and bump this post since I think I found an identical bug, and I left the beta so I can’t tell if your fix resolved it or not. On iOS, when using a Bluetooth keyboard, I also lose shortcuts. I’d check out the beta and confirm for myself, but it appears I can’t re-join.
The beta isn't active at the moment - the next beta round will begin in November, most likely. The previous fix in the beta is in the current, main site.
Let's try this outside of the quiz environment - jump to your dashboard, and press z, and see if the dictionary slides open.
If those changes are supposed to be in mainline then I guess there’s a couple more problems.
So Safari desktop: Press z at dashboard: Works Original enter during study issues: Still present/text input does not automatically receive focus Using numbers to make multiple selection choices: Works
Safari iPadOS with keyboard: Press z at dashboard: Works Original enter during study issues: Still present/text input does not automatically receive focus Using numbers to make multiple selection choices: Works
Looks like they’re both currently acting the same. I had just assumed that the Safari fixes previously implemented in the beta hadn’t been pushed to mainline yet, so that’s why it was still broken. But if there’s no beta and the changes should all be in mainline, then I guess this fix didn’t actually get implemented. Sorry that Safari is such a problem child.
So, interestingly (unfortunately), I could not replicate it in Safari on desktop - I'm using an emulation service, but this is the same service that did replicate the issue when we first had it.
I made one *very small* change, but I do not expect it to affect anything on desktop - on mobile at best.
Let me first clarify and make sure we are going through the same steps.
I'm testing on Catalina, but if you're on a different version of the os, let me know!
1. Go to Quiz, vocabulary, fill in the blank.
2. Answer a question.
3. Result appears with button to show next question.
3b. (optional) Click somewhere else on the page to remove focus from the "show the next question" button.
4. Press Enter/Return (the key that results in a keycode of 13 on the webpage linked in the earlier post).
5. Results disappear/next question appears
6. Focus goes to the fill-in-the-blank field.
I'd like to nail down the desktop version first (desktop Safari has much better debugging tools), and hopefully we'll see the fix work on iOS as well.
No change in behavior today. I'm testing on Catalina, Big Sur, and iOS 14. Behavior is identical across Big Sur and Catalina.
It's worth noting that actually answering a question isn't necessary. As soon as you open a quiz, you can tell whether or not it's going to be broken by whether or not the cursor is blinking in the fill-in-the-blank field.
So steps to reproduce: 1. Go to Quiz, vocabulary, fill in the blank. 2. Type and see if the fill-in-the-blank field receives text events.
If need be, I know that you're in need of a Mac for the iOS version of the crossword app. It's that time of year when Apple announces some new Mac devices, so after the announcement I'd be happy to buy you a Mac for your troubles. I'm sure this can wait till then, since I'm apparently the only person crazy enough to use Safari with Renshuu. 🙃
Oh wow, so that might simplify things - less steps to reproduce is always helpful. I'll check out my emulator, see what happens.
Also, that is an incredibly generous offer from you (if I'm reading your message correctly and am not in a delirium from trying to get ready to move 6000km from where we are now). I was actually tossing around a Kickstarter to try and fund the iOS development - a Mac is needed to compile and deploy iOS apps :(, but I haven't had even the slightest bit of time to think about it.
So if you're serious, I'd be more than happy to talk with you via email about it.
Back to the original issue, will let you know if I can tease out a fix to this situation!
I've yet been able to replicate the focus issue, including testing on your account specifically. Although I do not think this is the case, would you mind giving me an exact set of steps for replication, including what lesson you choose, and what specific quiz options you select? Thanks.
Additionally, have you had the chance to test in private browsing mode, just to ensure that there is nothing external that is interfering with it?
Steps to replicate: 1. Log in to Renshuu 2. Click "study" on the one currently non-frozen lesson called "Vocab," which is just a standard vocab list. 3. Attempt to type into the input field, noticing that it does not have focus and does not receive input.
The active quiz options on "Vocab" are: - Sentence questions: off - Fill-in-the-blank kanji: off - Fill-in-the-blank kana: on - Introduce new terms: on Quiz size: 40 Daily study goal: "Study as much as I can" is checked New terms per quiz (min): 0 New terms per quiz (max): 0 Max new terms: 0 terms per day for this schedule, 0 terms per week for all words schedules combined Order of new terms: in order of lessons Mix in terms for review: All the way to " a lot" Include study pad terms: All the way to "none" Active study vectors: - Kanji question -> Kana answer - Kana question -> Kanji answer - Meaning question -> Kana answer
My settings are a little strange, since I'm just maintaining right now and focusing on using the Heisig method for kanji elsewhere right now. I'm in too deep to swap over to the new renshuu Kanji system. Sorry. 🙃
Fully replicated in private browsing mode with all extensions turned off. Even tested on a freshly wiped device, so I'm not sure it's my local configuration. I'm amazed your emulation service doesn't replicate it.
I'm amazed as well. I need to push out an update to the crossword app, but I do plan on trying to replicate using your steps given above. Will report back!
*grumbles* I'm deeply questioning the value of browserstack.com if it's emulators (which it claims are real machines that you are effectively remotely connecting to) can't replicate this. I just followed your steps to the letter, and it gained focus immediately. For what it's worth, the version of Safari was 13.1, although I would be shocked if it is a specific version of Safari causing this. My guess is that because it's a "real machine", but possibly not one with a real keyboard attached to it, that is causing the difference in behavior.
I'm really sorry I haven't been able to make headway on this! With the number of iPad's being used as "pseudo" laptops and a non-insignificant number of desktop users, I can only imagine how frustrating this is for someone who wants to make the most of their time.
My move to the US is in just over a week, and after our self-imposed quarantine post-flight, I might be able to get my hands on my brother's Macbook Pro and replicate it there. I do have an iPad and could pick up a bluetooth keyboard, but it'll be tricky without a proper set of developers tools.
Well, after my family's move to the US, I found an iMac I could borrow - and I found out that Safari is disabling the focus() action when it is not tied to a user action (although it is - something might be getting unlinked), so the website cannot control certain things (similar to not allowing sites to auto play audio). Looks like the big thing is iOS, since having this control would allow websites to use it to force open your soft keyboard.
But this is good news, and probably why the emulator didn't work, since it was emulating a physical keyboard, instead of not having an actual keyboard.
Will report when I have a fix! It might be that the first question will not focus, but all subsequent questions will. Will see!
