Even though I missed the IRC meeting today (sorry), I wanted to share
that there has been a noticeable increase lately in support requests
regarding a "Tor unexpectedly exited. Please restart the application."
message.
Users will get this message over and over when trying to start their Tor
Browser. At least some of these folks are already familiar with Tor
Browser ("It worked fine before"). As a response, we will usually tell
users to delete their current Tor Browser and download the Tor …
[View More]Browser
again, which seems to usually clear up the issue. I have not opened a
new ticket for this issue.
--
Matt Pagan
matt(a)pagan.io
PGP: 0xE9284418E360583C
[View Less]
Radical proposal of the day: Can we use the Firefox major version
number in the Tor Browser version? This would mean that TBB versions
would be 24.0, 24.1, 24.1.1, etc.
Why consider making this change? Because doing so would allow us to
greatly simplify the patches needed for bug #4234 (Use Firefox updater).
For the Firefox updater to work correctly, it needs to be able to check
the version of an advertised update against the version of the software
that is currently installed. At …
[View More]the same time, for add-on compatibility
the browser version itself must be close to that of the Firefox release
it is based on.
We already have patches for #4234 that modify our Firefox build process
to pass the TBB version through and use it inside all of the
updater-related code (and to use the 24.x Firefox version when we need
to do so). However, the patches are messy and I don't think Mozilla
could ever accept them; Mozilla has no need for a bundle version that is
separate from the Firefox version.
If we used a version number for TBB that was close to the Firefox
version number, we would not need to patch anything; we would just use
our version number as THE version number. Doing this would also allow
us to eliminate the torbrowser.version hidden preference. And it might
help end-users who want to figure out what version of Firefox the Tor
Browser is based on.
--
Mark Smith
Pearl Crescent
http://pearlcrescent.com/
[View Less]
Mike made a comment here:
https://trac.torproject.org/projects/tor/ticket/6457#comment:9
that caused Kathy and me to do some more thinking about the TBB package
structure and how we can simplify the patches required for #4234 (Use
Firefox updater). The purpose of this message is to get input from
everyone.
The question: Should we change TBB so it it structured on disk just
like Firefox? In other words, can we pull the Firefox ("Browser")
directory up to the top of our package? This …
[View More]would provide several
advantages:
+ The patches for #4234 (Use Firefox updater) would be much smaller,
which means maintenance would be easier, Mozilla would be more likely to
accept the small patches we would be left with, and so on. This would
be a *huge* win and it is the main reason we are asking this question.
+ Bugs such as #6457 (Mac dock icon problems) would disappear.
+ The TBB package would look less like a bundle and more like a browser
that is based on Firefox.
There are also some challenges that stopped us from doing this last
fall. The RelativeLink wrappers perform some useful functions and it
may be difficult to eliminate them entirely. Our current thinking is
that we could adopt a slightly different approach for each operating system:
- On Mac OS, Kathy and I think we can keep the wrapper script but
eliminate the nested .app structure. This should solve the dock
icon problems. The main reason we need the wrapper is to ensure
that -no-remote is passed to firefox (we do not want someone to
try to open TBB and have a new Firefox window open up instead,
just because they happen to have Firefox running). Even if
we don't make changes for Linux and Windows, it probably makes
sense to do so for Mac OS since the package innards are mostly
hidden from users.
- On Linux, we can keep the wrapper script but move it down into the
Firefox ("Browser") directory. To keep end-users from being
overwhelmed by all of the files that are in the firefox directory
directory, we could provide a symlink at the top and use a
structure that looks like this:
tor_browser_en_US/
start-tor-browser@ (symlink to Browser/start-tor-browser)
Browser/ (Firefox directory)
Browser/start-tor-browser (wrapper script)
Browser/Tor/ (new parent for Data, Docs, Tor dirs.)
Browser/firefox (executable)
...
Note that the Firefox updater would not be able to touch anything
above the Browser directory, so we can't put anything above that
point that we will EVER need to update. But we can probably get
away with using one symlink.
- On Windows, like Linux, we have the problem of not wanting to
overwhelm end-users by showing them a folder with a bunch of
files in it and hoping they will locate and open the one named
firefox.exe (a challenging task, given that they just installed
a package named "Tor Browser"). But we could use a structure
similar to what I proposed above for Linux; our Windows installer
could create a shortcut that includes -no-remote, e.g.,
Tor Browser/
Start Tor Browser.lnk (installer-generated shortcut)
Browser/ (Firefox directory)
Browser/Tor/ (new parent for Data, Docs, Tor dirs.)
Browser/firefox.exe
...
If, someday, we provide a .zip package on Windows, users of it
will need to create their own shortcut or they will need to find
and open firefox.exe (but that means they may not neglect to
include the -no-remote flag).
A side note is that we do not need -no-remote if we are willing to
change the Tor Browser to look like a different application (compare to
Firefox), i.e., register a different window class on Windows, use a
different creator code on Mac OS, etc. But there may be reasons we do
not want to be different from Firefox in that way.
Opinions on all of the above? Pitfalls? This change will be disruptive
to developers, support people, and end-users but the long term benefits
might make it worth doing.
--
Mark Smith
Pearl Crescent
http://pearlcrescent.com/
[View Less]
Due to the US Daylight Savings Time changes generating new conflicts for
a few people, the Tor Browser team's weekly IRC meeting will now be on
Fridays at 18:00 UTC in #tor-dev on irc.oftc.net, starting this Friday,
March 21st.
We will be snuggling up next to the Huggable^W Pluggable Transports team
meeting, which is just before us at 17:00 UTC on alternating Fridays.
Their next meeting is March 28th.
The hope is that this will help us to work closer with them to polish up
the new unified PT-…
[View More]enabled Tor Browser, add new transport types, and
otherwise generate PLUR (yeah, I said it).
For details on our meeting format, see the original post:
https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html
P.S. We may have to revisit this time again when the EU switches to
"Summer Time" on March 30th. Running an hour later in the EU may start
to run into people's Friday evening plans, but we'll cross that bridge
once it starts burning.
--
Mike Perry
[View Less]
[Sorry for breaking threading; just joined the list and couldn't find
an In-reply-to header to use to fake it.]
I see the thread is mostly quiet, and it would be great for it to go
somewhere, so let me jump in with my own colors for the bike shed.
Geko said:
> Erinn Clark said:
> > - Firefox Patch Issues
>
> agreed.
Agreed.
> > - Quality Assurance and Testing(?)
>
> I wonder if that one really fits here (in the long run!?) as it is
> probably meant as a …
[View More]component which covers the QA and testing of all the
> (sub) projects we (The Tor Project) have. At least that is my impression
> when I look at
> https://people.torproject.org/~boklm/automation/tor-automation-review.html
> Sure, the TBB is probably the most important one but there are other
> projects outlined that are, if at all, only loosely related to it.
I think this one should probably stay separate, and hopefully in the
future it will grow to be larger and more diverse.
> > - TIMB
>
> Hmm... Not sure what currently is or will be tracked with this component
> but that's a different bundle which does not have Firefox patch issues
> and does not have Torbutton. So, I am wondering if there is so much
> overlapping here. Maybe we can start without it and see how it goes?
And this one should stay separate too, since it is specifically not
Tor Browser Bundle.
> > - Tor Launcher
>
> Mmmm... I think I'd want to start with it included: TBB is currently the
> only one using Tor Launcher. We might want to evaluate this decision
> later if we have other bundles using it. Maybe there are not so many
> additional things they need to merit an own Tor Launcher component as we
> currently have and we could keep it in the tbb-bugs component?
Tough one. You will be unhappy either way here. On the theory that Tor
Launcher is used by an increasing number of projects that aren't TBB
(Tails, TIMB, maybe Torbirdy), I'd be inclined to keep it separate.
> > - Tor bundles/installation
>
> Agreed.
This is the most important one to do something about.
> > - TorBrowserButton
>
> Agreed.
Yep.
Why not Torbutton while we're at it? I guess more broadly, the Torbutton
component should be triaged and then lit on fire.
> While it is good to fold them into one component to send notifications
> to a list, I don't want to miss the ability to search for specific
> "subcomponents". Not sure whether there is a good way to do that with
> Trac. We (at least I) currently use keywords e.g. for it (see the
> "gitian" keyword as example) which kind of works. I can live with that
> but am not sure if it is still usable when we only have one big
> component (and a lot of keywords).
We faced exactly this situation with the 'Tor' component -- we've
adopted the unofficial policy of adding keywords tor-client, tor-relay,
tor-hs, tor-auth, etc to help people who liked the old "many components"
model. But we're slowly finding that we don't need to do that anymore.
> > 2. Pick a time and method to begin collapsing things, which will inevitably
> > (and IMO necessarily) involve huge amounts of triaging.
Yay.
--Roger
[View Less]
Hi!
On #11124 [1], you will find a proof-of-concept of using Mallard [2]
to create the future Tor Browser User Manual.
I really like it. It would be great to have an opinion of the TBB team.
[1]: https://bugs.torproject.org/11124
[2]: http://projectmallard.org/
--
Lunar <lunar(a)torproject.org>
Hi!
We usually call Tor's flagship product the “Tor Browser Bundle”.
But since Tor Browser 3 and our departure from Vidalia, I'm having a
harder time going on calling it a “bundle”.
This is really obvious with the Mac OS X version, where users now
interact with only a single icon, called “Tor Browser”.
One concrete example is the logo and the wording that is visible in the
configuration wizard. The logo says “Tor Browser Bundle” and the text
right next to it says “Before the Tor Browser …
[View More]Bundle tries…”.
Couldn't we just drop the “Bundle” here?
For another small unconsistency, the wizard window title is “Tor Network
Settings”.
(Also, “bundle” is super painful to translate properly in French… but
that's a side effect.)
--
Lunar <lunar(a)torproject.org>
[View Less]
Hello everyone!
During the dev meeting we had many interesting discussions and agreements about
how to proceed as the ultimate TBB dev team. One of them involved collapsing as
many components as possible into a single Tor Browser Bundle component on Trac.
To this end, we have a new mailing list called tbb-bugs[1] and I've created a
Trac user called tbb-team which has tbb-bugs(a)lists.torproject.org as its email
address. The idea is to have the huge component have its owner as tbb-team, so
that …
[View More]we are able to see all of the bugs assigned to it via the mailing list and
then assign the bugs to individuals as needed. We will revisit this topic at
the next dev meeting in June to see if it's working out and, if not, figure out
a different solution.
We need to make a few decisions and commit to a few actions now:
1. Which components do we collapse into the huge TBB component? Here's a list
of all of the current Trac components that are candidates:
- Firefox Patch Issues
- Quality Assurance and Testing(?)
- TIMB
- Tor Launcher
- Tor bundles/installation
- TorBrowserButton
When we discussed this at the dev meeting it seemed unclear whether Tor
Launcher and TIMB would fit into such a component. I'm not sure why they
wouldn't -- please share your thoughts.
2. Pick a time and method to begin collapsing things, which will inevitably
(and IMO necessarily) involve huge amounts of triaging.
We could do this all-at-once with a batch modification to each agreed upon
component and then try to deal with the resulting mess later, or we could go
component-by-component and try to triage each one of them. It might be easier
to do this in smaller teams, 1-3 people, for specific smallish amounts (1-2h)
of dedicated time a few times a week. Or we could schedule some insane 8h block
where it's all hands on deck. Does anyone have a strong opinion about the best
way to organize this? If not, what are your preferences?
Thanks,
Erinn
[1] https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-bugs
[View Less]