Feature #1073
closed
Add an option to display under camera cutouts in full screen browsing mode
Added by v ... about 1 year ago.
Updated 10 months ago.
- Subject changed from Full screen mode is not using the status bar's space to Full screen mode is not using the status bar's vertical space
Does the device you are using have a camera cutout?
- Subject changed from Full screen mode is not using the status bar's vertical space to Add an option to display under camera cutouts in full screen browsing mode
I should be able to create an option to draw the full screen browsing under the cutout (some video playing apps do this, so I know it is possible). However, there should be an option to turn this off as it could cover an important aspect of a website. The question now is if the default should be enabled or disabled.
Having this option turned off by default seems, for me, to be the less annoying for most of the users. It will prevent that some users, maybe the less experienced, could think it is a bug (that some [important] part of a web page is hidden).
I believe that the cutout of the camera orb is very small, whether you take even a small device or a flagship. The odds of it interfering the website's interface should be almost negligible because most of the websites contain headers, with some title / heading. You can easily the guess the missing text there, as the orb cuts only a single letter.
Even if the website hides the header while scrolling (through scripting), that wouldn't be an issue too. Caz the screen real estate is too large to even begin with, users can scroll the content where the camera orb doesn't exist.
And in the rare cases, the orb isn't an orb. Maybe it's a notch. But the devices that were launched with a notch, were very less. So you might factor in the notch area coverage setting. But nonethless of the defaults on or off, I would say bringing this config out into the userspace will be a very good move.
- Priority changed from 3.x to Next Release
- Status changed from New to Closed
How do you manage issue priorities that are "Next Release" which were of closed status ?
Wouldn't this cause confusions for you on writing the changelogs of the next release ?
I'm not sure I understand your question, but closing features when they are implemented helps when it comes to preparing the changelog.
Of course but just wondering how you'd track those, as they get mingled into the older issues which were closed & their statuses still remaining as "Next release" like this one.
Why not change the Priority to "3.x" since these are done?
I sort all closed issues by date. Then I start at the release date of the last version and read forward through each issue, seeing if it contains anything that should be in the changelog.
Also available in: Atom
PDF