(In reply to Botond Ballo [:botond] [away until Jan 4] from comment #6)
(In reply to :Gijs (he/him) from comment #5)
Is there a good way of exposing "meaningful" zoom levels from layout code, perhaps on the browsing context (which is what we use to zoom right now)?
In principle we could do either of the following:
- Expose a list of all percentage zoom levels (within a min/max range) that have distinct corresponding AppUnitPerDevPixel scales. Note, at lower zoom levels, such as between 100% and 110%, this will have entries that are closer to each other than every 10%, so the consumer of this may need to do further pruning of it.
- Send a list of desired zoom levels (e.g. ones at 10% intervals), and have layout code return a subset that have distinct corresponding AppUnitPerDevPixel scales (so e.g. it would prune out 290%).
It depends on what makes more sense in terms of how the API would be used.
I'm not sure. Right now the code uses frontend-side logic to take the current zoom level. Then for wheel/scroll zooming, we add/subtract 0.1. For the other UI, we use a list of levels we have in a pref (so is user-customizable...) and pick the next/previous item in that list, and then assign to
.fullZoom on the browser custom element, which talks to the browsing context.
I guess this means the simplest solution would be (2). This means we can do the filtering for the shortcuts and non-wheel/scroll UI in the same place where we find the next item in the list. For the wheel/scroll zooming, we'd need to adjust the implementation so we generate a list and then use similar logic, instead of "just" incrementing/decrementing by 0.1 .
What would be the right place to add such an API, and when should frontend discard the list and refresh it, e.g. if the OS DPI changes or the window is moved between screens? (Right now we cache the list based on the pref.)