The badges for different states are useful, but I have to click on cupcake to see them. It would be cool if the toolbar icon changed color (maybe the icing?) to indicate whether it's working or not. I'm thinking two colors, one for IT'S WORKING! and one for PLEASE INVESTIGATE FURTHER. Otherwise, cupcake could be failing and I'll never know because why would I check?

I should make accessibility enhancements to make the Cupcake more usable for the visually impaired and people who use accessibility devices.

I could make this happen with ARIA markup. The most commonly used screen readers offer support for ARIA and some automatically select a speech/aural stylesheet if one is offered. (aural was offered for CSS2, speech is the variety used in CSS3. Backwards compatibility is in play, but given that Cupcake only exists for modern browsers, I'm just going for CSS3).

Cupcake is small enough that this would dictate the accessibility tree in a pretty straightforward way. Instead of listing current and possible statuses (as it does now), Cupcake will just list the current status and ways to resolve it, if necessary. This will be partly implemented as part of the UX overhaul.

References:

• http://www.w3.org/TR/aria-in-html/
• http://www.w3.org/WAI/PF/aria-implementation
• http://blog.paciellogroup.com/2012/06/html5-accessibility-chops-using-aria-notes/

(note to self: JAWS 8 is the IE6 of screen readers)

So right now, rapid network changes will trigger a false dead signal and seemingly remain that way. However, it is not actually dead or disabled in any way, just idle. It will still become active, and after it returns to an idle state, it displays the correct icon.

This happens in a no-internet environment and when behind a captive portal. (Which, given that I am frequently behind captive portals, this likely happens more than with most users).

Proposed initial fixes:

• A) set background to re-initialize flashproxy.js at regular intervals, if the status is something other than active.
• B) force dead-status flash proxies to retry connection every 10 minutes.

Future upstream fixes:

• Change dead to waiting, since it seems to be waiting for a real connection
• Ensure that flash proxies with dead/waiting status occasionally re-check connection

Edit: this is also Tor issue #11400.

Hello!
Firefox 50.1.0, Ubuntu 16.04
When I try to install from the https://addons.mozilla.org/en-US/firefox/addon/cupcakebridge/?src=ss
In the end comes the pop up that it can only install if I restart firefox. If I do click restart it does, but doesnt seem that it installed cupcake (no icon on the toolbar)
However, it does list in the "Add ons" of firefox, but without an icon.
Probably I'm missing something, but Id like to see an indicator if my browser is a proxy.

Integration of Snowflake with Cupcake will begin later this week at the Tor dev meeting hackathon. Initially, this will be in the browser extensions, with later plans for WordPress/etc.

Check out branch pink-snowball to work on this.

[1] https://github.com/keroserene/snowflake

Previously, the Cupcake extension would be displayed near the address bar by default. At some point, Firefox updated and the extension no longer has this default behavior. Mozilla's automated testing of extensions didn't catch the incompatibility.

Normally I'd be correcting this instead of filing a ticket, but I will instead take the approach of recreating the Firefox extension to be compatible with the new extension system. It's important to note this as the division point between Cupcake being a classic Firefox extension and becoming a new-style Firefox WebExtension. Hence, ticket. =)

body

While I don't entirely agree with comments about the Chrome extension's current design, it will be redesigned to make it easier for users to understand. This should also help with user retention to some degree.

I fixed this just now upstream:

https://gitweb.torproject.org/flashproxy.git/commitdiff/05b9c101ba9afe4653d1eff6f5414f90f22ef042

I guess this is more important for cupcake, since people leave their browsers running for longer periods of time. In my experience it takes about a day to reach 5 failed connections, then after that the unfixed flashproxy is useless.

(Generally, you probably want to have some way of being notified about changes to flashproxy.js from us upstream.)

Test