On Wed, Apr 11, 2012 at 3:33 PM, Lucas Adamski <[email protected]> wrote: > On Apr 10, 2012, at 9:07 PM, Jonas Sicking wrote: > >> On Tue, Apr 10, 2012 at 4:59 PM, Lucas Adamski <[email protected]> wrote: >>> >>> == Regular web content (unauthenticated) == >>> Use cases for unauthenticated code: Prevent screen orientation from >>> changing when playing a game utilizing device motion >> >> I'd also add: Switch screen orientation when switching between >> different parts of an app. For example when switching from UI to >> browse lists of videos, to UI which plays a specific video. Or >> switching orientation between people facing one another playing a game >> on the device. > > Ah ok, so the ability of the app to specify a specific orientation.
Yes. Or a restricted set of orientations (like only the two portrait modes). >>> Authorization model for normal content: implicit for detecting orientation, >>> explicit runtime for locking orientation >> >> I'm not sure what "explicit runtime for locking" entails here. I don't >> think we want an explicit prompt when the page requests that the >> orientation be locked in a particular direction. Basically it seems to >> me that prompting the user for something as "trivial" as screen >> orientation (which you can basically do by simply rendering your text >> sideways anyway) would just lead to "prompt fatigue" with users. > > I think I had confused orientation of the content with orientation of its > container/app. Disregard, I agree that it doesn't need any explicit > authorization. Well.. inside a browser app I think a page setting its orientation will also affect the where the browser UI goes. Some people have said that they don't want in-browser-pages to be able to affect the orientation of themselves+browserUI at all. Only if a page is fullscreened should it be able to set its orientation since then it isn't messing with the browser UI (since there is none). >>> Potential mitigations: Orientation should remained locked only while >>> focused. >> >> I think we might need more than that, especially since I'd prefer to >> not have an explicit ask-for-permission prompt for screen locks, even >> for uninstalled apps. What I propose is this: >> >> 1. Orientation locks only affect the locked app/page. If the user >> switches tab or app, the other pages aren't affected. >> 2. If the page is installed content, always allow the orientation lock. >> 3. If the page is in fullscreen mode, always allow the orientation >> lock. There is no browser UI being displayed anyway and so the page >> could cause the same behavior by simply rendering text sideways. Need >> to verify that this will work on mobile. >> 4. If the page isn't in fullscreen mode, and is contained in an >> <iframe> (or <frame>) never allow the lock request. >> 4. If the call to lock the screen orientation happens in response to a >> user action, always allow the orientation lock. >> 5. If the call to lock the screen orientation doesn't actually require >> the screen to be immediately re-orientated, always allow the >> orientation lock. >> 6. If no other calls to change the lock orientation has happened in >> the last X (say 5) seconds, allow the orientation lock. This is mostly >> to cover the case of the page setting its lock during initial page >> setup. >> >> We could potentially skip rule 5 since it doesn't actually solve any >> real problems, and might just be confusing to developers. The other >> rules should be enough to allow all sanely written code to "just >> work". > > I'm having a hard time keeping this all in my brain. :) If I were to > condense this into a set of simpler rules would it still meet the behavior as > described above? > a) Orientation locks only affect the locked app/page. If the user switches > tab or app, the other pages aren't affected. > b) Only top level or full-screen content can set the lock Yes! With the one exception mentioned above. > You have two #4s in that list, so regarding #4b I'm not sure why we need a > special exception to user initiated locks if they are generally permitted. > Is that just for iframes or frames? Same for 5 or 6 I guess. Fundamentally > if this lock only affects the content requesting the lock, then I agree > there's no reason to restrict its behavior (content can always choose to > annoy the user). Doh! I was referring to the second 4. The restrictions would only be there in order to prevent pages-in-a-browser from messing with the browser UI since the browser UI moves when the page changes orientation. > One thing that doesn't seem to have been discussed is whether a change to the > top-level orientation also changes the orientation for embedded iframes and > other content? IMO it should. I think we generally want all content on the screen to have the same orientation. / Jonas _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
