Is setting a specific zoom level part of the MVP?

[youennf]

The current proposal allows to set a particular zoom level, which requires getting the current zoom level.
This seems ok to implement for tab capture, but might prove more difficult for window surfaces.

AIUI, the main usecase is to zoom in or zoom out, which is something many OS/applications support.

This makes me wonder whether, instead of exposing the ability to set a specific zoom level, we could reduce to allow to zoom-in/zoom-out for the MVP. It seems these primitives could be easier to implement for both tabs and windows.

Would we lose much in terms of functionality?

[eladalon1983]

Would we lose much in terms of functionality?

IIUC, the proposal here is to only support increase/decrease and get rid of everything else - getter, setter, supported-levels, event handelr. That means:

• Apps won't be able to display the current zoom-level to the user over the preview tile. (And to listen to out-of-band changes to this value.)
• Users would lose the ability to "reset" the zoom level with a single-step, sending the level back to 100%.
• Apps won't be able to grey out controls at min/max value.
• Apps won't be able to please the user with more advance controls such as drop-down lists or sliders.
• Multi-step transitions of zoom level would require multiple clicks from the user...
• ...and multiple layout updates by the captured application, instead of a single zoom-change and subsequent layout change.

[eladalon1983]

Issue transferred; heads up to those discussion participants who might otherwise be looking for it elsewhere: @jan-ivar, @youennf