In my mind, the need to have content that can be scrolled and content that can be zoomed is very different. I understand that when content is zoomed it often also needs to be scrolled, but I'm curious if there was any consideration to making these separate controls? Possibly with a zoomable control extending from a scrolling one.
My concerns are: 1) the ScrollViewer being made overly complex by adding zooming related functionality which will not be needed by most; 2) it not being obvious to someone looking for a control for zooming into content that the ScrollViewer supports this.

Additionally, within the proposal, I'd like to see the ability to scroll to a specific element within the scroll viewer. In theory, this could be done by a developer by measuring all the items before it and then scrolling to the appropriate offset, but this can be difficult to do with virtualized lists and is (to my mind) a common enough scenario that many apps (and developers) would benefit from this being built-in.
Consider where an item is added to a "list" and the developer wants to ensure that item is visible. Or consider a page with a master/detail view where the page is opened at a detail item way down the list, but the developer wants to ensure the selected item in the master list is displayed, so it provides context for what is shown in the detail view.

Similarly, it would also be useful to be able to ensure that an item stays in the visible area while other items within the scrollable areas are removed from (or added to) the visual tree. I'm not sure what the best way to do this would be, but it's very bad when the selected item within a scrollable area moves because a background (or off-UI thread) action removes or adds other items to the scrollable area.
Having an item move as you go to click/tap on it leads to a terrible usability experience. Having focused/selected items move out of the visible area can also cause issues for accessibility tools and screen readers.
I'm aware there are potential issues with trying to keep an item in the same position while those around it move (especially if that item is deleted from elsewhere) but doing nothing doesn't seem good enough.

Thanks @mrlacey. I can see how zooming functionality would be less discoverable in the existing ScrollViewer as well as this proposal. I've added this as an open question for discussion as it would be another point of departure from the existing UWP ScrollViewer (perhaps for the better?).

Virtualization makes things tricky since first the specific element might need to be created and run through the layout system to have a position to which you can then scroll. This is why in the past certain controls (i.e. ListView) have had their own ScrollIntoView method that handles the above to make it easy. Is that the type of method you're envisioning? Alternatively, every UIElement has a StartBringIntoView method that can be used to very easily scroll to an item and has a number of options to provide fine-grained control over where in the viewport it lands when brought into view. The StartBringIntoView approach works even in scenarios with nested scrolling surfaces since it generates a request that bubbles up for each scrolling control to respond. This is essentially what happens when an item receives keyboard/GamePad/Narrator focus. Of course, it requires that you first have a UIElement which you may not in a virtualizing scenario without a way to explicitly trigger an element to be realized. Would it be useful to have a way to explicitly trigger the realization of an element? Among other things you could then use it to trigger a StartBringIntoView.

Re: maintaining the position of an item as other content is added/removed or changes in size... Totally agree that doing nothing isn't good enough. This is exactly why the scroll anchoring feature exists. :) It's a little-known capability that in the past has been built-in to the virtualizing Panels for ListView/GridView. In recent releases we've been making an explicit effort to decouple things like this from only being available in ListView.

If the idea of an expanded ScrollViewer is to be explored, perhaps the Fluent Design teams could advise you about handling parallax and items with z-depth values set by default.

As XAML moves into 3D representations for MR apps, and as Depth and Shadows come to 2D XAML - how the scrolling would move items of different depth values, how the shadows may render above or behind the scroll indicators, and other issues that may crop up in the XAML team's 3D experiments - could be built into what could become the new default, as Windows UI Library slowly becomes the new default.

In my mind, the need to have content that can be scrolled and content that can be zoomed is very different.

Except in web browsers, graphics design apps, office apps, PDF viewers..... anything that shows a content document.

Agree with @mrlacey that bringing a specific element into view is important as well as specifying where in the view it is displayed (top, center, bottom, etc...). There also needs to be a way to detect if the element is entirely in view or clipped. This way I don't have to scroll the view to show an element if I know the element is already entirely or even partially in view.

Thanks all! We gathered some telemetry regarding which properties apps tend to set in their markup and the ZoomMode shows up right after the *ScrollMode and *ScrollBarVisibility. Most of the time apps aren't changing any properties. What I've observed when the ScrollMode and ScrollBarVisibility properties are being set is that its often to enable horizontal scrolling on the content. The introduction of the ContentOrientation property is intended to make that easier. After horizontal scrollling, the next most common scenario is zooming.

Rather than introducing a separate (derived) control to address discoverability of zooming I believe the right documentation / samples could be more effective.

What about adding a Behaviour or Context Enum?

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom;
ScrollViewer.ScrollBehaviour = ScrollBehaviour.Scroll;
ScrollViewer.ScrollBehaviour = ScrollBehaviour.ParallaxScroll;

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom; is very confusing though. I think ZoomMode should stay as it is.

ScrollViewer.ScrollBehaviour = ScrollBehaviour.Zoom; is very confusing though. I think ZoomMode should stay as it is.

I probably should have prefaced the suggestion as addressing comments which think there should be a derived control for Zooming content, rather than Scrolling

To me it actually makes sense to have zoom functionality built in with ScrollViewer, especially on touch devices. There's currently no easy way to do freestyle panning/zooming/rotating on an image/control in UWP, and many related questions have been asked on StackOverflow and GitHub (e.g. Add draggable content control).

@micahl, I assume with zooming and

Support rotation gestures

this scenario would be supported natively in the future?

To me it actually makes sense to have zoom functionality built in with ScrollViewer, especially on touch devices. There's currently no easy way to do freestyle panning/zooming/rotating on an image/control in UWP, and many related questions have been asked on StackOverflow and GitHub (e.g. Add draggable content control).

If there is a need to have more control on Zooming and Scrolling...

ScrollViewer.ScrollBehaviour = ScrollBehaviour.ZoomAndScroll;

But on touch devices, it feels natural to allow pinching and sliding of fingers. Zooming without touch however would need [ + ] and [ − ] buttons to appear. Or perhaps if it was Zoom only, then the scrollbar thumb dragging would zoom in and out.

If you look at the Microsoft Word UI, there is a Zoom control in the Status Bar. And scrollbars for the document area.

Is mouse zoom support something that should be built into the new ScrollViewer control? So when ZoomMode is on, or a Behaviour Property allows Zoom - then Plus and Minus buttons appear?

@JustinXinLiu Supporting rotation gestures would likely require support from InteractionTracker (@likuba).

@mdtauk The new ScrollViewer would support mousewheel zooming via a Ctrl + mousewheel similar to the existing ScrollViewer. It's unclear to me whether the control should have a default plus/minus button when zoom is enabled. My current impression is that the kinds of apps that commonly enable zooming (e.g. a content document app) choose to incorporate those buttons into their app experience in varied ways. For example, a - / + in a status bar that is separated by a slider (i.e. Office) or as just a simple -/+ that appears vertically below other commands (i.e. Maps).

@micahl I don't understand why ScrollFrom is called that way. Isn't it just like ScrollBy but with a velocity parameter?

@adrientetar are you asking why not have another overload of ScrollBy with a different set of parameters instead of naming it ScrollFrom?

Yea I guess 😃 but I imagine the concept behind ScrollFrom is to move in a direction with a given velocity? as opposed to ScrollBy which is just move to a given point.

That's right. We had 3 situations in mind:

1. I don't care what my current position is. I want to scroll/zoom TO a specific destination.
2. I care what my current position is and I want to scroll/zoom BY a specific amount relative to that position.
3. I don't care what the final destination is. I just want to scroll/zoom FROM my current position.

A scenario for the latter might be something like the mousewheel-click to pan experience. Depending on the position of the cursor relative to when it was clicked, some inertia is inserted scroll from the current position (whatever that is).

Thanks, that clears things up. I think I'm more looking to use ScrollBy for my own mousewheel-click experience, but I can see ScrollFrom being useful in specific cases.

In the current ScrollViewer control, it is possible to bind to the ViewportWidth and ViewportHeight properties, but this does not seem currently possible in the new ScrollViewer control. Will this be added?

@lhak, what would you bind those values to? Adding them wouldn't be a big change. Depending on the context for your scenario there might be a different approach we'd recommend rather than binding. While we want to be sensitive to differences that make it difficult to move from one to the other we also want to promote alternatives if they're better.

@micahl I'm pretty sure I've used those values in the past too for some calculations. Not sure if I've bound to them.

@michael-hawker to be clear, the properties will be available on the ScrollViewer. However, in the proposed API they're exposed as regular properties rather than as DependencyProperties. These same values will be available as part of the ExpressionAnimationSources property for situations where someone is building input-driven animations based on Composition.

I currently use some code similar to the following in my application:

<ScrollViewer x:Name="outputScrollViewer">
  <Viewbox MaxWidth="{x:Bind outputScrollViewer.ViewportWidth, Mode=OneWay}" MaxHeight="{x:Bind outputScrollViewer.ViewportHeight, Mode=OneWay}">
    <TheXamlElement Width=X Height=Y/>
  </Viewbox>
</ScrollViewer>

This makes it possible to scroll/zoom the inner xaml element (which has a fixed size) while keeping its aspect ratio. The behavior is similar to the photos app showing an image, with the exception that the xaml element is never smaller than the viewport of the scrollviewer.

@lhak, good scenario! Thinking out loud on how this scenario might be accommodated in the current proposal... I think we could add another option for the ContentOrientation property. The current options in the proposal:

• None = No preferred orientation. Give the content infinite available size in both directions.
• Horizontal = Give the content infinite available size only horizontally and constrain the height to the viewport during layout.
• Vertical = Transpose of horizontal

A fourth option would be to constrain both the height and width during layout to the size of the viewport. For the moment I'll call this a "Viewport" orientation, although I have mixed reactions about naming it as such.
At least in the (more common?) case of an image I believe it would make the Viewbox and bindings unnecessary as "the right thing" should just happen as part of the layout process.

<ScrollViewer ContentOrientation="Viewport">
  <Image Stretch="Uniform" .../>
</ScrollViewer>

For more complex content you'd be able to wrap it in a Viewbox and still skip the bindings.

<ScrollViewer ContentOrientation="Viewport">
  <Viewbox>
    <TheXamlElement Width=X Height=Y/>
  </Viewbox>
</ScrollViewer>

@micahl Have another question: I would like to change the mouse wheel handling of Scroller to make zoom faster (bigger increments) and remove the smoothing animation. It seems like there's no API to tweak the wheel zooming, do I need to handle mouse wheel event manually?

You may have to handle mouse wheel manually, but it would be unfortunate if it turns out that you end up needing to re-implement what the control does. We think there might be a way to achieve what you're after. The gist of it would be to set the ZoomInertiaDecayRate to some value close to 1.0 and then define a repeated zoom snap point. It's something to try once we've added the ZoomInertiaDecayRate property and fixed some issues related to mandatory snap points.

If that doesn't work, then you could fall back to trying to handle it yourself by setting IgnoredInputKind="Mousewheel" and then either sub-classing the Scroller to override the OnPointerWheelChanged, or add an event handler for the PointerWheelChanged event on Scroller.

@micahl Thanks! I'm not sure what scenario you calibrated the mouse wheel behavior against, personally I like the way it is e.g. in Adobe XD: there's a bit of an accelerating animation it seems but it's snappy and has large enough zoom increments. Scroller mouse wheel zoom animation feels a bit sluggish and has really small zoom increments imo.

@adrientetar, good feedback. We can look into adjusting it.

Any kind of variable that controls increments and values - could be made into overridable properties

Right. One challenge for us here is that on Win10 version 1809 and later the control hands off mouse wheel input to the underlying InteractionTracker to let it be processed off the UI-thread for smoother motion. Those overridable properties would need to first be exposed at the lower-level. For versions of Win10 before 1809 we're adding logic to have the control process mouse wheel input on the UI-thread.

We could consider having some behavior where we expose some overrideable properties and if any are explicitly set then we fall back to having the control process mouse wheel on the UI-thread. If/When those properties exist at the lower level then we could switch to relying on them and kicking it back over to the compositor. Scrolling probably wouldn't be as smooth for mouse-wheel. Perhaps that's OK here?

So the current zooming behavior is baked in to InteractionTracker with no way of overriding it? And I guess now there's no way to change it because it would break backwards-compatibility 🤔 cc @likuba

I think there are some options on InteractionTracker that could help here 😊. Specifically, we built features like PointerWheelConfig and DeltaScaleModifier to enable these types of customizations. We're going to sync up and see if using these within the control could enable something to happen here without the problems/risks you mention above.

@micahl I have an interesting situation on a project I'm working on and I had to write my own scrollviewer for the PoC - but I'd like to know if you have any plans (or if the this control supports this already) for the following scenario :
Say you have a giant canvas, 10000x5000 so to move around it, you encapsulate it in a scrollviewer.
Now on the canvas you have 2 InkCanvases (or more) and you'd like to write on both (or more), with different fingers or with 1 finger and 1 mouse pointer. How would you achieve that (or is it even possible) with this control? :)
What I've seen the default behaviour is as soon as you touch anything else while drawing on one InkCanvas, that particular InkCanvas fires "PointerLost" and that's it - nothing else to do.
Obviously my scrollviewer is far far far from perfect as I wrote it myself - so I'm looking to see if this could be possible with this control?

Thank you kindly !

Hi @stefangavrilasengage, interesting scenario. :) From your PoC, what's the expected behavior when a finger goes down on an InkCanvas and then starts to move? Does it draw or pan?

Hi there @micahl - thank you for replying ! I assume by now you've guessed it's something like a digital whiteboarding app.
Now I will present what happens currently:

• ScrollViewer (default) : one finger drawing on an InkCanvas is fine. 2nd finger makes the 1st InkCanvas lose input.
• ScrollViewerEx (custom control) : use as many fingers and as many InkCanvases to draw and it works.

Does this help? :)
Thank you !

@stefangavrilasengage I was asking what disambiguates between whether a single touch gesture pans (default behavior for ScrollViewer) or draws ink. There's an inherent conflict there. How do you resolve it? Require two fingers for scroll like a map? Use an edit button to enter/leave an edit mode? Etc...

@micahl My apologies - forgot to mention how I've solved the conflict.
The objects we have on the canvas have their ink inside a Win2D container. Only if you enter an edit mode for each object will an InkCanvas be presented on top for editing (with custom drying).
Therefore in my situation (not sure if this applies to anyone else), if you have an InkCanvas active "drawable", then nothing should go up to the ScrollViewer.
I would be curious to know of a use case where you think this doesn't apply, if any?

Thanks !

Hard to believe this is the first time that @micahl and I have gotten mixed up in a github issue!

Hard to believe this is the first time that @micahl and I have gotten mixed up in a github issue!

Sorry about that ! Edited !

@micahgodbolt it may not be the last. ;)
@stefangavrilasengage thanks! That answers my question. I noticed that swapping out a ScrollViewer with something else like a Border as the parent of a Canvas containing multiple InkCanvas controls doesn't have the same problem. So, I've reached out to some folks internally to understand what may be causing the multi-input / multi-InkCanvas functionality to break down when it happens inside a ScrollViewer.

@stefangavrilasengage, figuring out why it doesn't work will take some time/investigation. Let's track that separately from this proposal. Will you open an issue for it?

@micahl I have an issue with Scroller where scrolling and zooming around my content in OnControlLoaded puts me in a wrong position. If I only scroll, I end up in the right position, but if I zoom right after scrolling I'm in a totally off position, even though I specified centerPoint=null so it defaults to viewport center (from looking at the code because there's no documentation yet afaict). With this code.

Thanks for trying things out, @adrientetar! Let's keep this thread focused on the proposal. Can you open a separate issue for what you're seeing? Depending on where we net out on that discussion we may want to return to this thread to discuss if it warrants changes to the proposal.

@micahl Why do ExtentChanged/StateChanged/ViewChanged events have object as their argument and not e.g. StateChangedEventArgs with a State member? Given that InteractionTracker runs on a different thread isn't the message passing pattern (event with an argument) preferred to querying the control property in the event handler?

https://github.com/XeorgeXeorge/Extended-Image-Viewer

Not much of a big deal, but the first part of this repo showcases how to implement zooming even when the Horizontal/Vertical Scrollbars are locked(Disabled),

In simpler words:
Allows for panning on a zoomed in content while still force fitting the to
effective Vertical/Horizontal Viewport.

At the time posting this it is mandatory to enable the HorizontalScrollbarVisibility property in a ScrollViewer in order to actually get a functional Zoom operation, and although there might be better ways to go around this, i think the dual scrollviewer solution i scrapped together might be sufficient enough.

@micahl I see that Scroller does not send StateChanged events when performing a non-animated zoom, is that by design?
I do set my CanvasVirtualControl scaling when Scroller becomes Idle, as you suggested in https://github.com/microsoft/microsoft-ui-xaml/issues/541#issuecomment-488749469, such that the control does not end up rasterizing too large portions of the canvas relative to the zoom factor. But with a non-animated zoom, I need to do that at the time I call the ZoomTo method, even though the zoom change hasn't been realized (afaict).

@adrientetar, there's some overhead to creating event args to pass back and forth between the framework and the app. Because the event arg would only be providing a copy of properties exposed by the sender our current design is to not have the event arg.

Yes, the current design is that in a non-animated zoom you invoke programmatically the StateChanged doesn't fire. The ZoomCompleted and ScrollCompleted event would be raised in response to programmatic changes. IIRC they aren't triggered by changes from the user. You could use one of those, perhaps in combination with the StateChanged. As fyi, the ViewChanged event is raised anytime the view changes (user or programmatic) which makes it a very perf sensitive code path and is not what you'd want to use.

We're still listening to feedback so if things seem obtuse let us know.

Yes, the current design is that in a non-animated zoom you invoke programmatically the StateChanged doesn't fire.

Ah okay, I understand now. Maybe the event could fire always and contain an origin parameter, like SetFocus, but maybe there's some overhead to doing that.

The ZoomCompleted and ScrollCompleted event would be raised in response to programmatic changes. IIRC they aren't triggered by changes from the user.

Okay, so for my use-case I have to handle ZoomCompleted and StateChanged iff State == Idle, depending on whether the change is programmatic or not. Isn't that weird? I mean, to have different events with different names for the same thing only triggered a different way 🤔

@RBrid and I had a brief chat about introducing a new state "Transitioning" and making some minor renames. Let us know if this would make more sense for your use-case.

The idea discussed was that when a change to the scroll/zoom position is about to be serviced (whether user initiated or programmatic) we'd raise the StateChanged event and report the current state as Transitioning. Here's what the sequence would look like for a programmatic scroll (animated and not animated):

// programmatic request, animated
myScrollInfo = ScrollTo(100, animate=true);
// few ticks
StateChanged raised (Scroller.State == Transitioning)
// few ticks
StateChanged raised (Scroller.State == Animating)
// many ticks
StateChanged raised (Scroller.State == Idling)

// programmatic request, no animation
myScrollInfo = ScrollTo(100, animate=false);
// few ticks
StateChanged raised (Scroller.State == Transitioning)
// few ticks
StateChanged raised (Scroller.State == Idling)

We'd probably want to rename the InteractionState enum to something like ScrollState since it would represent more than just the interactions.

enum ScrollState
{
    Idling = 0,
    Transitioning = 1,
    Interacting = 2,
    Inertial = 3,
    Animating = 4,
};

@micahl Yes, that looks very much like what I would expect! Someone who'd want to only handle animated changes can intercept the Animating state. For the names, I would keep Idle not Idling ("Scroller is idle"/"Scroller is animating"), Transitioning → Stirring? (Transitioning is very confusing, I'd rather we convey that it's at the start of the motion so imo stirring might work better), Inertial could be Drifting 😛 but I guess API Review will chime in as well.

Stirring initially made me think of blending. :) API review will want to weigh in when we finalize names and tends to look for precedent. It's always good to have some options. Other alternatives could be Unknown or Pending. There's precedent in existing APIs for both of those along with Idle which means we'd probably not do Idling.

Cool cool. Pending sgtm, imo Unknown is even more confusing than Transitioning.

@micahl -- Functional Requirement number 3 includes this subpoint:

participates in effective viewport changes (Must)

That subpoint refers to the preexisting event FrameworkElement.EffectiveViewportChanged. Is that subpoint sufficient to say (indirectly) that async on-demand partial loading of content is also a requirement/priority? I mean, for example, the equivalent of how the ScrollViewer operates when MS Edge displays a zoomed-in page of a PDF document (or SVG or other complex document). When the zoom is 900% (for example), it does not pre-render the entire PDF page at 900% size, because of these 2 reasons:

• This rendering task (at high zoom percentage) requires roughly 3 .. 20 seconds, depending on document complexity (quantity of vector elements, effects, etc), document size, and zoom percentage. This delay is too much for end-users to accept.
• A rendered image (bitmap) of the entire PDF page can consume hundreds of megabytes of RAM when the zoom percentage is high, because it is equivalent to rendering at a very high DPI.

MS Edge renders parts of the zoomed-in PDF page on-demand, meaning when the user scrolls those parts into view. This technique avoids the long delay before the page is displayed. I suggest that the Functional Requirements explicitly mention this scenario, but also with indirect support for async Task. When an unrendered (or otherwise not immediately available) part is scrolled into view, ScrollViewer can temporarily fill that space with a configurable Brush and then trigger an event, and the event handler can start an async Task to render (or otherwise retrieve/load) the part. Later, when the Task completes, the rendered/retrieved/loaded part is displayed in the ScrollViewer, covering up the space that was temporarily filled with the Brush.

This issue is not only about the high cost of rendering at a high zoom. It is also applicable to content that is retrieved on-demand. For example, imagine a map or satellite image displayed in ScrollViewer. Parts of the map are only downloaded from the server when the user scrolls them into view.

Should the zooming-related APIs be separated into a derived control (e.g. ZoomViewer) such that ScrollViewer is strictly about scrolling?

Although I much appreciated the addition of ScrollViewer.ZoomFactor, I was surprised to see that it was directly added to ScrollViewer. I presumed that it would be simpler and more reliable to put zoom in a separate class (not necessarily a derived class). At least 3 ways are possible:

1. A class named perhaps ZoomViewer that does NOT inherit ScrollViewer, but uses a ScrollViewer instance as a child element (in its ControlTemplate).
2. A class named perhaps ZoomableScrollViewer that does inherit ScrollViewer.
3. Directly supporting zoom within ScrollViewer, if it's not excessively complicated or messy.

17 Provide a default UX to support a mouse middle click and scroll. (Should)
18 Support a mode to click and pan via mouse (e.g. moving content inside a PDF viewer). (Should)

I suggest considering whether to remove support for 17, because 18 works much better than 17, and hardly anybody uses 17 in practice. Admittedly I might be thinking that 17 means something else than your intended meaning (the description of 17 is only one sentence and I'm not 100% certain that it means what I think it means). Isn't it correct to say that 18 is very user-friendly and easy-to-use, whereas 17 is an awkward thing that everybody struggles to use and avoids using?
(This issue changes if 17 is needed for accessibility reasons, but so far I've never heard anybody say that 17 is an accessibility issue.)

4 Able to perform input-driven animations

Number 4 is an accessibility-related issue. I'd like to request that ScrollViewer (and all other Controls in WinUI) respect the accessibility settings:

Windows 10 -> Start -> Settings -> Ease of Access -> Display -> Show animations in Windows (On or Off).

Unfortunately, over the years, I've noticed many examples where Microsoft apps ignore the Windows accessibility settings. Animations are switched off but Microsoft apps display animations anyway. This causes real difficulties for the users who rely upon these accessibility settings. Not everyone has the ability to enjoy animations without suffering negative side-effects. Users who experience no difficulties viewing animations etc can find it difficult to understand the significance of the accessibility settings in Windows.

Hi @verelpode, @predavid will be driving the work around the new ScrollViewer so I'll defer to her.

17 Provide a default UX to support a mouse middle click and scroll. (Should)
18 Support a mode to click and pan via mouse (e.g. moving content inside a PDF viewer). (Should)

I suggest considering whether to remove support for 17, because 18 works much better than 17, and hardly anybody uses 17 in practice. Admittedly I might be thinking that 17 means something else than your intended meaning (the description of 17 is only one sentence and I'm not 100% certain that it means what I think it means). Isn't it correct to say that 18 is very user-friendly and easy-to-use, whereas 17 is an awkward thing that everybody struggles to use and avoids using?
(This issue changes if 17 is needed for accessibility reasons, but so far I've never heard anybody say that 17 is an accessibility issue.)

@verelpode I think you understand 17 correctly and I agree that 18 is more important and usually more intuitive than 17. But there can be scenarios where "left click and drag" is already used for other purposes, such as selection, or drag+drop. For such scenarios, it would be good if the app can enable scrolling through middle click (17).

I personally use middle click scrolling in browsers from time to time, where left click + drag causes either text selection or drag+drop of images. A UWP browser would have 18 disabled and 17 enabled. Both should be opt-in via separate properties.

@lukasf

I personally use middle click scrolling in browsers from time to time, where left click + drag causes either text selection or drag+drop of images.

Good point re the need to avoid causing text selection etc to stop working. What do you think of this possible solution: Make middle-click start the mouse-based panning mode (18) instead of starting the awkward 17 mode.

When I look at what other apps do, some apps allow you to start mouse-based panning by holding down the spacebar key while left-clicking in the scrollable content area. This solution allows left-click to operate normally within the scrollable content area because the panning mode only starts via spacebar+click. I find panning via spacebar+click very comfortable and convenient and fast.

However, this spacebar+click solution is easier to implement in apps that don't need to display any editable textboxes within the scrollable content area. If editable textboxes do exist in the scrollable content area, then it'd be a problem the panning feature makes users unable to type spaces in textboxes. Therefore, as you said, this feature should be opt-in via a property. Alternatively, don't use the spacebar, and instead make middle-click start the mouse-based panning mode (18), and this eliminates the problem of users being unable to type spaces in textboxes.

@verelpode
With all browsers and also a bunch of other applications (Word, Adobe Reader, Outlook,...) supporting mode 17, I'd still think that this should be implemented. Just because you personally find it awkward does not mean that it is not useful to other people. Both modes should be opt-in of course, then devs can decide what shall be used in their app. This would also allow your spacebar+click behavior, if it makes sense for an app: Enable mode 18 on spacebar down, disable it again on spacebar up.

@lukasf -- OK, sounds good. I thought you meant that if the panning mode (18) wouldn't prevent text selection or drag+drop of images etc, then you would stop using mode 17 and switch to 18, but now I see your preference is actually for both modes to be supported.

Thank you for your feedback @verelpode and @lukasf, I agree with you that ultimately we will want public knobs on the Scroller control to turn on/off numbers 17 and 18. Let's call them 17=mouse-based constant-velocity-panning and 18=mouse-based panning.

I just sent out a PR https://github.com/microsoft/microsoft-ui-xaml/pull/1472 for adding some investigative work I did. I wanted to see how close I could get to supporting both 17 and 18 using today's Scroller.

Things went pretty well for 18=mouse-based panning, although the solution is 100% UI-thread-bound, unlike the touch-based or mouse-wheel-based experiences. I used the ScrollTo method while listening to the mouse's PointerMoved event. Ultimately we would want the underlying InteractionTracker component to handle mouse moves like it does with finger moves.

Things are much trickier for 17=mouse-based constant-velocity-panning (an experience which I personally dislike). The prototype is far from ideal and I did not try to address all issues, but two in particular are concerning:

• during a constant-velocity-panning (i.e. 0-velocity-decay panning), I don't think there is a way with the current Scroller to stop the movement without jumping back to an older position (with ScrollBy(0, 0)). It's just not reliably possible to know how far the composition thread has gone ahead of the UI-thread. So some new public Scroller API would be required to stop velocity in a glitch-less fashion.
• I was not able to keep the mouse capture after the mouse's PointerReleased event. It seems a new Xaml framework feature would be required to achieve this.
  Anyways, this may be another case where we would want the underlying InteractionTracker to handle some of the experience directly.
  I will keep these in mind for sure when discussing future Scroller/InteractionTracker features.

@RBrid

Things went pretty well for 18=mouse-based panning, …...
Things are much trickier for 17=mouse-based constant-velocity-panning (an experience which I personally dislike).

Interesting results! In that case, considering the difficulties with 17=constant-velocity, and considering that 18 can be implemented in a way that doesn't prevent normal usage of left-click, then in my personal opinion I think the proposal should probably be updated to abandon 17 and support 18 instead, but admittedly I don't know how many users would complain if 17=constant-velocity is abandoned.

Thank you @RBrid for these investigations. Great to hear that mode 18 already works! I agree it should ideally be handled by InteractionTracker, to allow smooth operation even during UI thread load.

@verelpode Both modes are set as "Should". So if effort is too high to realize mode 17, it could just be left out (and maybe added later, if required). But maybe someone finds a way to realize it without too many changes.

I hope the new ScrollViewer has ability to disable or customize Zoom with "Ctrl" key.