> On Sep 18, 2015, at 10:45 PM, Nathan of Guardian > <[email protected]> wrote: > > > > On Fri, Sep 18, 2015, at 01:06 PM, Amogh Pradeep wrote: >> >>> On Sep 17, 2015, at 6:52 PM, Hans-Christoph Steiner >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> Orfox was working pretty well in general as a browser. Amogh added >>> NetCipher >>> to get the automatic Tor starting. That started Orbot fine, but Orfox >>> errored >>> out on any websites that it tried to load while waiting for Orbot to start >>> Tor. So I implemented an approach that makes the orbot starting stuff >>> transparent, and tries to make Orfox transparently hold loading any pages >>> until Tor is ready. This used the internal Fennec event "Tab:Load". The >>> problem with that approach is that the Fennec UI blocks and waits for the >>> Gecko engine to respond to any "Tab:Load" messages that have been sent. >> I agree that we need to make major UI changes to integrate the two >> applications properly. >> I’d be able to implement it if someone gave me a clear idea on what >> exactly to do, UI wise. > > I strongly disagree that we need to make major UI changes, because once > we do that, it becomes a much bigger problem to maintain and update > Orfox. That is a valid point. Maintenance > > The problem you are trying to deal with is one that happens rarely for > the typical Orbot user. Most people keep Orbot running all of the time > in the background on their phone. This is how a typical VPN is used as > well. They don't selectively start and stop it, and if they did, that > would create a pretty poor user experience based on the time it takes to > boostrap into the Tor network. > >>> >>> I also tried queuing incoming Intents that cause a web page to be loaded, >>> but >>> that only works for new URLs coming in. If Orfox is not running, then it is >>> started and wants to load a few tabs from the previous session, those will >>> all >>> show the failure to connect page since they are not being started by >>> Intents, >>> but rather the internal Tab:Load messages. >>> >>> I also thought about just going back to the old Orbot start Intent that >>> launched Orbot itself, but upon thinking about that, I think it would really >>> handle error conditions badly, like when Orbot fails to start properly, >>> because going to Orfox would always just redirect to Orbot. >>> >>> Now, I'm thinking the best approach includes two key pieces: >>> >>> * remove the Tab:Load queuing that is there now, and switch back to the >>> Intent >>> queuing method I had going before. >>> >>> * update the "proxy connection failed" page so that it shows the Tor status >>> (OFF/STARTING/ON/STOPPING) That page will also include the "Try Again" >>> button >>> that is there. Also, when STATUS_ON is received from Orbot, that page can >>> automatically try again. We should probably also add a button that brings >>> up >>> the Orbot main screen so that users can easily troubleshoot the Tor >>> connection >>> in Orbot. >> I think this would be awesome. If we could redirect to a help page in >> case the proxy connection isn’t fine (Orbot isn’t fine) and we help the >> user troubleshoot on that page, it would be a nice UX. > > This sounds like a good small change that we could manage.
I guess managing this one page would be the best solution then, that shouldn’t be too hard to maintain either. > > > -- > Nathan of Guardian > [email protected] > _______________________________________________ > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > To unsubscribe, email: [email protected] PS: Sorry for the triple reply for the earlier mail, I had email client problems!
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
