Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
briar
briar
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 675
    • Issues 675
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 11
    • Merge Requests 11
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • briar
  • briarbriar
  • Issues
  • #1572

Closed
Open
Opened May 29, 2019 by akwizgran@akwizgranOwner
  • Report abuse
  • New issue
Report abuse New issue

Transport icons use inconsistent information to determine plugin state

The transport icons in the nav drawer use two sources of information to determine which transports are active: Plugin#isRunning() and TransportEnabled/DisabledEvents. But these sources can be inconsistent. For example, BluetoothPlugin#isRunning() returns true if the adapter is enabled, regardless of whether contact connections are enabled, but the plugin doesn't broadcast TransportEnabledEvents unless contact connections are enabled. This leads to the following bug:

  • Start Briar with default settings and the Bluetooth adapter enabled
  • The Bluetooth icon is active because isRunning() returns true
  • Disable the Bluetooth adapter
  • The Bluetooth icon is inactive because a TransportDisabledEvent was broadcast
  • Re-enable the Bluetooth adapter
  • The Bluetooth icon remains inactive because no TransportEnabledEvent was broadcast

Arguably the real issue here is that plugins (or the manager) should provide an isEnabled() method that follows the enabled/disabled events. This could easily be implemented in the manager, and could also be used to suppress redundant enabled/disabled events, such as those broadcast when toggling the Bluetooth adapter state without contact connections enabled.

Related to discussion of plugin states on #185 (closed).

Assignee
Assign to
Android 1.2
Milestone
Android 1.2
Assign milestone
Time tracking
None
Due date
None
Reference: briar/briar#1572