Closed mteep closed 1 year ago
Hi, this sounds interesting. I wasn't even aware that the cursor keys weren't working in UIWebView, but this may have to do with Apple no longer maintaining and testing UIWebView (as it is deprecated and might be removed completely from iOS in a future release). Definitely advisable to make your exam solution compatible with the modern WebView/WKWebView (see this page and release notes of SEB 3.x).
Do you want to send me your code or to create a pull request? Both options would be highly welcome, thanks!
Thanks, I'll prepare a pull request.
It is not my exam solution, but that of Inspera used at a local school. I have tried to get answers on why they don't use WKWebView, but haven't gotten any.
For the Mac version of SEB, they were testing SEB 3.2.x and want to enable SEB 3.2.4 (or better the just released 3.2.5) from April, I was told. I'm not sure though if that also applies to iOS (although there they can't not support the latest release, but they might not add the necessary setting to use the modern WebView).
I'm not sure I follow what you wrote. But I can tell you that the local school performed dummy tests using SEB 3.2.2 on iPads configured through Inspera.
Navigating or selecting text using the keyboard didn't work. Selecting text using touch was glitchy in multiple ways. Pasting was hard to do, and the app crashed occasionally. I urged them to ensure the "modern" web view (WKWebView
) was used going forward, to no avail. They couldn't even confirm that the "classical" web view had been used. I had to deduce that from the crash report and attempts to reproduce the problems.
Despite all the problems discovered, the school proceeded to use SEB 3.2.4 on iPads for a nationwide synchronized test requiring the use of physical keyboards and a writing environment known to the pupils. There is another upcoming nationwide synchronized test roughly two weeks from now, and as far as I can tell they will again use a setup that does not fulfill any reasonable interpretation of the requirements. That is, unless they can upgrade to a SEB release containing the two fixes I have suggested. Touch selection will still be glitchy, but at least there'll be an alternative.
Are you saying that you know for certain that Inspera does not support using the "modern" web view, WKWebView
on iPadOS? I assume the server work for "authentication" would be practically the same for macOS and iPadOS.
Until now, Inspera's settings didn't allow to use the modern WebView (similar to many systems having support for SEB built-in, but slowly most are updating their integrations to work with the modern WebView).
Inspera just confirmed to me that they will generally activate support for the modern WebView in their release right after Easter. So that should solve the issue you described for Inspera Assessment.
I will of course review and add your pull requests anyways in the next release (probably 3.3), as users with other exam solutions which still use UIWebView in SEB will benefit greatly. To be honest I didn't have a clue that keyboard support was so bad in UIWebView, as no SEB/iPad users reported it until now and we never did as thorough testing with external keyboards.
Btw. on iOS there's a subtle difference in rendering the tab where you can see if it's the classic (UIWebView) or the modern (WKWebView) WebView: In UIWebView, the background is black (or white depending on SEB settings) and you see that on iPads with rounded corners (the ones without a Home button) on the top (or if you scroll to the end of a page the bottom) of the screen. WKWebView chooses the background color automatically depending on the dominant color of the rendered web page (so the top/bottom would usually not be fully black).
On Mac, WKWebView can be pinched-to-zoom with two fingers on the trackpad, the classic WebView not.
Ok, thank you! That is great news! Let's hope things work out in the near term then, but also that the other exam solution providers move to support WKWebView
in the long term.
As for my implementation, although I didn't start out his way, this is essentially the default and obvious implementation in UIResponder
(logging excepted, of course). I haven't dug far enough in the history of NS/UIResponder
to be sure, but it wouldn't surprise me if the UIResponder
methods started out as an informal protocol, which easily leads to this default implementation in NSObject
.
I have also found some old related bugs, but no suggested workaround seems better or safer than my implementation.
Hi! Any chance of including these fixes in a release soon? (Inspera didn’t mention the iPad version of SEB in their latest release notes a few days ago, so I still don’t know if they support WKWebView
there.)
Hi, I can confirm that Inspera supports WKWebView with their latest release also on iPad. I plan to release these fixes in the SEB 3.3 version, on which I'm currently working. I still have to finish implementing 2-3 features first, then I'll review those fixes. They likely won't be included in the next TestFlight beta, but if you don't have access yet, you can send me an email address for a private invite (info at safeexambrowser dot org) or use the public TestFlight link.
Great! Thank you!
The above mentioned fixes are contained in SEB 3.3 for iOS, available in the App Store. I just briefly tested it, so I hope everything works correctly. As discussed it's now probably no longer relevant for Inspera Assessment, as that should now be using the modern WebView. But with all e-assessment apps which still use the Config Key/Browser Exam Key with the HTTP request headers or use URL content filters in settings SEB will still use the classic WebView, which will profit from these fixes.
So thank you @mteep, thank you very much for your contributions!
When a physical keyboard is used with an iPad (iPadOS 15 – 16.3 tested), the arrow keys do not work in "classical" web views (
UIWebView
).This seems to be caused by the
UIThreadSafeNode
that wraps the activeDOMNode
not implementing the (UIResponder
) methodcanPerformAction:withSender:
.I have a fix ready where a trivial default implementation is added to
NSObject
using a category.This issue was observed in AAC mode. Proof of concept fixes have been tested on both iPadOS 15 and 16, but the final fix only on 15.7.3. (And not in single app mode since I don't have the entitlement.)