Bug 30092 - Subscribing to event handler for UIWebView.ScrollView disables zooming.
Summary: Subscribing to event handler for UIWebView.ScrollView disables zooming.
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: XI 8.10
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2015-05-14 14:53 UTC by Jon Goldberger [MSFT]
Modified: 2015-05-14 19:51 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Test Project (494.81 KB, application/zip)
2015-05-14 14:53 UTC, Jon Goldberger [MSFT]

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Jon Goldberger [MSFT] 2015-05-14 14:53:19 UTC
Created attachment 11205 [details]
Test Project

## Description

Adding any event handler to the ScrollView property of a UIWebView causes zooming to no longer function, e.g:

>webView.ScrollView.DraggingStarted += (object sender, EventArgs e) => {};

I assume this is because adding the event handler is overriding an internal delegate? The workaround is to use a delegate class to handle those events:

>var scrollViewDelegate = new WebViewScrollViewDelegate();
>webView.ScrollView.Delegate = scrollViewDelegate;
>public class WebViewScrollViewDelegate : UIScrollViewDelegate
>	public override void DraggingStarted(UIScrollView scrollView)
>	{
>		Console.WriteLine("DraggingStarted");
>	}
>	public override void DraggingEnded(UIScrollView scrollView, bool willDecelerate)
>	{
>		Console.WriteLine("DraggingEnded");
>	}

Doing the above lets you handle the events and zooming still functions. However it seems to me if those event handlers are available they should be usable. I understand this may not be possible with the UIWebView as the UIScrollView is part of the UIWebView widget, but perhaps it is. 

## Steps to reproduce

1. Open the attached test project and deploy to an iOS device/simulator.

2. Try to Zoom the UIWebView

Expected result: UIWebView will zoom.

Actual result: UIWebView does not zoom. 

## Environment

=== Xamarin Studio ===

Version 5.9.1 (build 3)
Installation UUID: 2dc9022f-f9a8-424f-8284-bf224cbbfde0
	Mono 4.0.0 ((detached/d136b79)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 400000143

=== Apple Developer Tools ===

Xcode 6.3.1 (7703)
Build 6D1002

=== Xamarin.Mac ===

Version: (Business Edition)

=== Xamarin.Android ===

Version: (Business Edition)
Android SDK: /Users/apple/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode)

=== Xamarin Android Player ===

Version: Unknown version
Location: /Applications/Xamarin Android Player.app

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 6481535
Branch: master
Build date: 2015-04-27 04:38:13-0400

=== Build Information ===

Release ID: 509010003
Git revision: aad75a6e7e48f18120ce41f47d0ff2c6216f49c3
Build date: 2015-05-08 12:46:18-04
Xamarin addins: 1246b3044cbb7f56a217334f8fc5489ef8eefe3f

=== Operating System ===

Mac OS X 10.10.3
Darwin Jons-iMac.local 14.3.0 Darwin Kernel Version 14.3.0
    Mon Mar 23 11:59:05 PDT 2015
    root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64
Comment 1 Sebastien Pouliot 2015-05-14 15:50:37 UTC
That's because when you use events you're using the internal *Delegate type that bridge them.

Most (but not all) events return `void` so it's fairly easy to ignore (and not implement) them.

In some cases they can return a value - and that value may be important. In this case it's `ViewForZoomingInScrollView` which must return the view to be used.

The default implementation returns `null` (as it cannot know the default) but that breaks the zooming. Using something like this:

> webView.ScrollView.ViewForZoomingInScrollView += (UIScrollView scrollView) => webView;

will make the zoom be based on `webview`.
Comment 2 Jon Goldberger [MSFT] 2015-05-14 16:06:07 UTC

I should have mentioned that doing:

webView.ScrollView.ViewForZoomingInScrollView += (UIScrollView scrollView) => webView;

Causes the zooming to act strangely. try it in the test project and you will see. It seems like it almost double zooms the view. So perhaps that is the bug report I should have filed. :-)
Comment 3 Sebastien Pouliot 2015-05-14 17:07:48 UTC
> webView.ScrollView.ViewForZoomingInScrollView += (UIScrollView scrollView) => webView.ViewForZoomingInScrollView (scrollView);

Note that you should not* play with the ScrollView's delegate (it's impolite as it's not yours) as UIWebView implements IUIScrollViewDelegate (in ObjC-talk UIViewView conforms to the the UIScrollViewDelegate protocol). That makes it even harder to implement events correctly (too many ways of doing the same stuff, not all of them correct).

Anyway that's why the above code works, it's routing back to the UIWebView code (which was not `webView`).

* you'll run into many problems (see SO posts)
Comment 4 Jon Goldberger [MSFT] 2015-05-14 18:06:20 UTC
By the "above code", do you mean:

>webView.ScrollView.ViewForZoomingInScrollView += (UIScrollView scrollView) => webView.ViewForZoomingInScrollView (scrollView);

That does not work. There is no ViewForZoomingInScrollView on a UIWebView and the above code causes the build to fail stating such. Making it:

>webView.ScrollView.ViewForZoomingInScrollView += (UIScrollView scrollView) => webView.ScrollView.ViewForZoomingInScrollView (scrollView);

causes a stack overflow, so anyway I am more confused now than before. Can you clarify the correct way to handle dragging and other events on a UIWebView object's ScrollView?  

It seems that the first workaround I noted in the bug description works as expected, i.e. assigning my own delegate to the webView.ScrollView.Delegate property, but now I am unclear if you are meaning that that is what should not be done ("it's impolite as it's not yours")

Sorry, I do not mean to belabor this, I just want to make sure that our customer who reported this to me gets the proper way to implement handling of dragging (and perhaps other) events on web view's scroll view.
Comment 5 Jon Goldberger [MSFT] 2015-05-14 18:19:57 UTC
This SO thread's accepted answer seems to indicate that the workaround in the bug description is the correct way to handle dragging or other events on the web view's scroll view:

Comment 6 Sebastien Pouliot 2015-05-14 19:51:15 UTC
> That does not work.

So my code above work, I copy-pasted it directly from XS.

But, double checking, I see that UIWebView was fixed recently (by no one else than me) to conform to UIScrollViewDelegate, IOW it works only in master (not 8.10.x) and I did not notice/remembered it earlier, sorry ;-)

> There is no ViewForZoomingInScrollView on a UIWebView 

Right - but there's an extension method defined in `UIScrollViewDelegate_Extensions` that provides it on any type implementing `IUIScrollViewDelegate` (which UIWebView, on master, does).

> the proper way to implement handling of dragging

Right now, use the *Delegate (not events) approach. There are other workarounds but they ugly and won't help the customer code maintenance.

> This SO thread's accepted answer

That was not a post I had read before (there's many), see the comment on it

> Is it safe to reassign the delegate of a grandchild object like this? 

A: it's not 100% safe, i.e. it could change and you could replace existing/custom logic. That's a low risk (because it's a commonly used pattern on UIWebView that would break too many apps) but something that should be avoided when possible.

http://stackoverflow.com/q/17253345 is a bit better, see the EDIT in the question that describe how the UIWebView was implemented. Now internals can vary with different iOS versions, don't trust that information to code something (its a lot more risky than the above).