ms-intune-app-sdk-ios
ms-intune-app-sdk-ios copied to clipboard
Unable to disable or modify long pressing links when MAMPolicyRequired is true
Describe the bug: Excuse the lack of specificity as I try to describe the issue while I am unable to upload screenshots or real code from the company network.
We have a hybrid mobile application where most of the content is rendered with WKWebview. In the web views, we have anchor tags linking to various pages within the app i.e. <a href="...">Link</a>
.
When MAM policies are required (MAMPolicyRequired = true
), the SDK is overriding any behaviors we have implemented for long press gestures and allows users to long press on links which opens an action sheet with Open, Share..., and Copy options for the link's href value. We don't want this action sheet to appear.
When MAM policies aren't required, we are able to disable long press gestures or capture them to handle ourselves.
To Reproduce Steps to reproduce the behavior:
- In an iOS app with the Intune SDK, set
IntuneMAMSettings:MAMPolicyRequired
to true in the app'sInfo.plist
. - Long press on any anchor tag
- An action sheet appears with Open, Share..., and Copy options
Expected behavior: A link in a web view should not resort to the default long press behavior when MAM policy is required. Developers should be able to capture long press gestures within their own apps.
Screenshots and logs: Unfortunately I can't upload a screenshot, but when you long press on any links, an action sheet appears with the following options:
<link's href value i.e. /details/id
>
- Open
- Share...
- Copy
Smartphone (please complete the following information):
- Device: iPhone 13
- OS: iOS 15.6
Intune App SDK for iOS (please complete the following information):
-
What version of the Intune SDK are you using? Are you using the latest version? 15.1.3, no
-
What platform is your app based in (native, Xamarin based, Cordova, etc)? Ionic/Capacitor
-
For errors during build, does the app build without Intune SDK integration?
-
For errors post build, does the app launch without being Intune SDK integrated?
-
Do you see a trend with it only being reproduced on a specific device? Yes, iOS devices.
Additional context: We've applied this CSS to links to disable the action sheet from appearing:
-webkit-user-select: none;
-webkit-touch-callout: none;
In any build of the app where MAM policies aren't required, this works long presses on links do nothing. As soon as the MAM policies are enabled, long presses open the action sheet.
Additionally in an attempt to handle this natively, we use UILongPressGestureRecognizer
in conjunction with webView.addGestureRecognizer()
to try to suppress the gesture. Once again, when MAM policies aren't required, I'm able to see in the console the gesture being captured. As soon as MAM policies are required, the code does nothing.
I've also tried adding the URLs to the IntuneMAMSettings:WebViewHandledURLSchemes
array in my app's Info.plist, which did nothing.
@christinaasu, this unfortunately sounds like expected behavior when when MAM policy is applied to webviews. You should be able to workaround this behavior with the "TreatAllWebViewsAsUnmanaged" flag. Can you confirm if using "TreatAllWebViewsAsUnmanaged" in the app's info.plist fits the app's needs? Here are the docs for how to use this flag for different data source scenarios: https://docs.microsoft.com/en-us/mem/intune/developer/app-sdk-ios#displaying-web-content-within-an-application
@abasore Unfortunately, setting TreatAllWebViewsAsUnmanaged
didn't change anything. All of the content should be managed anyway, but I tried using both YES and NO; both result in me being able to long press on a link and the app displaying an action sheet with those options when we've otherwise explicitly disabled it.
To clarify, it's expected behavior for the SDK to forcibly show Open/Share/Copy options when a user long presses on links?
@christinaasu, thanks for clarifying. The SDK current doesn't support apps to disable the long press open/share/copy options when a managed user has app sharing restriction policy in place. I make a note of this as something to support in a future SDK version.