[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #26826 [Applications/Tor Browser]: TBA - Does the app need the SYSTEM_ALERT_WINDOW permission?

#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs