[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9034 [Flashproxy]: Firefox browser add-on
#9034: Firefox browser add-on
------------------------+---------------------------------------------------
Reporter: dcf | Owner: dcf
Type: project | Status: needs_review
Priority: normal | Milestone:
Component: Flashproxy | Version:
Keywords: | Parent:
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by cypherpunks):
A bit of status on this. My first implementation, the 0.0.3x series was
the badge integrated as UI element. It was a quick hack. However it had
two problems. First of all it was part of the UI so it was only running,
when attached. The other problem is that people wrote me how they don't
like it, because it is quite noisy and the badge simply was made for web
pages, blogs etc. It doesn't integrate well with the browser and isn't an
icon.
Since the add-on really got a bunch of users I started reading up on
extension development. Because there was also a mail about the size of the
iframe and memory usage, etc. and because I thought it would be benificial
(and just because I wanted to dig into it) I changed the approach, hacking
on Flashproxy directly, basically hoping it would remain stable and I
would have enough time to keep it updated. I kinda knew it probably
wouldn't work out, but I thought maybe it could go into a direction where
the core functionality is just a little library, so people could do most
of the stuff that these days is done via query strings using an event
frameworks or an API. It's mainly because installing an extension is in
general a different approach, one actively puts effort in it, has really
long running connections, wants to provide more resources, already opts in
to it, etc. Anyway, I thought that could be the way to go.
Sadly, it was too much experimentation, less time, etc. and so it became
buggy rather quickly. But lesson learned. I decided to strip all that away
again trying to not actively interfere withe the badge. I am now only
reading the messages the badge prints in debug mode. Should I want to do
configuration I will use the normal query string and for opting in I set
the required cookie (like I did in the early version). I currently do that
in a really simple way and also really inefficiently. That's most likely
to change. The benefit of this approach is that the badge will always be
used like it is meant to be, having its usual environment and if there is
any problem with the add-on it will most likely still work correctly, but
maybe show wrong statistics or something, which is a benefit for everyone.
I will also inform users of NoScript (which of course is extremely popular
among users of this add-on).
This is implemented, but not on addons.mozilla.org yet, which mainly is
because they appear to have a problem with add-on upload in the recent
hours. This however gives me time to test things more throughly before
releasing it.
One more related thing: The add-on is created using the SDK, so more high
level than some other add-ons. This currently means that the add-on can
NOT be used for other Mozilla products. There are tickets on GitHub for
this. It (hopefully) is a temporary problem, because it is something many
Mozilla people want to change. So as soon as this changes there will also
be Seamonkey, Thunderbird, etc. add-ons based on the same code.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9034#comment:3>
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