#26826: TBA - Does the app need the SYSTEM_ALERT_WINDOW permission? --------------------------------------+-------------------------- Reporter: sysrqb | Owner: tbb-team Type: task | Status: new Priority: High | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: tbb-mobile | Actual Points: Parent ID: #24796 | Points: Reviewer: | Sponsor: --------------------------------------+--------------------------
Comment (by sysrqb): This is used by the TabQueue subsystem. Quoting the TabQueueService description: {{{ The SYSTEM_ALERT_WINDOW permission is used to allow us to insert a View from this Service which responds to user interaction, whilst still allowing whatever is in the background to be seen and interacted with. }}} So, this is used when Fennec's `Tab queue` is enabled (`false` by default). If a user enables Tab queue in Fennec's Settings->General menu, then they are prompted for allowing the SYSTEM_ALERT_WINDOW permission at run-time. If the user grants this permission, then whenever the user chooses opening a link from another app in Fennec/Tor Browser, that link is queued in the tab queue. This additional permission is required because the UI presented in the other app when the user performs this action is a custom toast popup created by the browser. This toast popup is translucent and appears over the origin activity. See https://bugzilla.mozilla.org/show_bug.cgi?id=1130368 and a mockup https://bug1130368.bmoattachments.org/attachment.cgi?id=8560439 and see https://bugzilla.mozilla.org/show_bug.cgi?id=1130368#c4 and [https://bugzilla.mozilla.org/show_bug.cgi?id=1130368#c5 c#5] for more context. But the reasoning was: {{{ > Why use a Service here rather than an Activity? If we're the foreground > Activity, we can draw over the other application if we don't take up the > full-screen (think share overlay [1]). That way we don't need to take the > SYSTEM_ALERT_WINDOW. Services are typically reserved for background work > (i.e. non-drawing). This is the main difference between this and the share overlay is that this will allow the user to ignore the toast and carry on using the application in the background. I tried a fair few approaches on this before opting to go down the current route. The issue with using an activity to display the toast is that although we can set the background of the acitvity to invisible so the user can see the application behind it, that application is now in a background state which means that it doesn't respond to touch events and there's no way that I can route touch events from our activity to the application behind. This method is the same as FB us to do their chatheads (http://stackoverflow.com/questions/15975988/what- apis-in-android-is-facebook-using-to-create-chat-heads). }}} In this context, the share overlay was implemented in Bug 1044947 - mock https://bug1044947.bmoattachments.org/attachment.cgi?id=8480149 -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26826#comment:1> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs