Opened 4 years ago

Closed 8 weeks ago

#19251 closed enhancement (fixed)

TorBrowser might want to have an error page specific to when .onion links fail

Reported by: cypherpunks Owned by: brade
Priority: Low Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ux-team, TorBrowserTeam202004R, tbb-9.5a10
Cc: tbb-team, asn, emmapeel Actual Points: 7.1
Parent ID: #30025 Points: 6
Reviewer: acat,pospeselr Sponsor: Sponsor27-must

Description

When a webpage fails to load, it can be due to any number of factors. But when that page is served by an onion service, some of those factors have greater implications for security.

It would be cool to know if the failure is related to a malfunction in the local Tor instance, or due to nonlocal failures. If TBB can determine this, adding something to TBB to create .onion specific error messages with greater detail would be helpful.

Child Tickets

TicketTypeStatusOwnerSummary
#30090taskclosedantonelaMake a list of potential .onion errors
#33035defectclosedtbb-teamcreate strings for onion service error pages

Attachments (11)

O2A4.jpg (158.4 KB) - added by antonela 8 months ago.
1-errorpage.jpg (271.3 KB) - added by antonela 8 months ago.
1-errorpage-graph-2.png (57.5 KB) - added by antonela 4 months ago.
assets.zip (3.0 KB) - added by antonela 4 months ago.
1-errorpage - grayshade.png (184.1 KB) - added by antonela 3 months ago.
1-errorpage - outline.png (190.5 KB) - added by antonela 3 months ago.
1-errorpage - colored.png (187.7 KB) - added by antonela 3 months ago.
error-0xF0-rev2.png (159.5 KB) - added by mcs 3 months ago.
0xF0 error page (WIP)
browser.svg (972 bytes) - added by pospeselr 2 months ago.
network.svg (843 bytes) - added by pospeselr 2 months ago.
onionsite.svg (3.7 KB) - added by pospeselr 2 months ago.

Download all attachments as: .zip

Change History (68)

comment:1 Changed 2 years ago by antonela

Cc: antonela added

comment:2 Changed 18 months ago by antonela

Cc: antonela removed
Keywords: ux-team added

comment:3 Changed 14 months ago by pili

Sponsor: Sponsor27

comment:4 Changed 14 months ago by gk

Sponsor: Sponsor27Sponsor27-must

Add Sponsor27-must items for Objective 2

comment:5 Changed 14 months ago by pili

Parent ID: #30025

Changed 8 months ago by antonela

Attachment: O2A4.jpg added

Changed 8 months ago by antonela

Attachment: 1-errorpage.jpg added

comment:6 Changed 8 months ago by antonela

We want to improve the way we communicate with users that there is an error trying to visiting an onion service. We have a good opportunity for sharing educational points and for being more transparent with users, offering them information about the kind of error they are experiencing.

We can provide more informative error messages indicating better whether the issue was on the service-side, on the client-side, or the network-side. We can do it without being overwhelming or patronizing but clear about the information we are spreading.

As asn mentioned, errors could happen in different layers:

  • Client Errors
  • Network Errors
  • Service Errors

To illustrate this complexity, we can use a diagram of the connection and show where the error happened. I thought about isabela's idea in #23486 and I think we can have a kind of step-by-step graph here as well.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/O2A4.jpg

So I came up with this concept. This layout is flexible enough to cover all the error scenarios we currently have in #30090.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/1-errorpage.jpg

What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?


TODO

  • UI: Make the UI for each error scenario.
  • Content: Define the content for each page. This information also needs to have an entry at support.tpo.org and tb-manual? Onion services documentation?. We will need to l10nize it.
  • User Testing: Once this reaches a nightly, I'd like to share with our testing pool of users for feedback.

comment:7 Changed 8 months ago by asn

Cc: asn added

comment:8 in reply to:  6 ; Changed 8 months ago by asn

Replying to antonela:

What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?

I think the concept is reasonable, but I don't have much insight on how good this will be for users VS other options that I can't imagine right now. e.g. I'm not sure if people will be helped by knowing that the problem is on the network or not.

Leaving that aside, and assuming that the idea is the best one (which is fine by me), I need to say that sometimes it's not clear where the error is (e.g. in 'F2' and 'F3' where the intro/rend fails, it's not clear whether the problem is on the network or the service itself), so in those cases I'm not sure which button should light up. I think it would be a bad idea to tell users that the problem is on the service, when actually it's just a bad rendezvous point and it would be solved by reconnecting. And given that 'F2' and 'F3' are hard to classify, and 'F1' should never really appear, I'm not sure what would be the class of 'network-level errors'.

comment:9 Changed 8 months ago by clash

Something like the Cloudflare error pages might be a nice idea since they serve the same purposes.

https://community.cloudflare.com/t/connection-breakage-between-cloudflare-and-the-server/57148

It would be nice to be able to isolate where the error occurred both as a client and as a host.

Maybe a "flow" could be represented in those icons like Cloudflare does with the double sided arrows.

comment:10 in reply to:  8 Changed 7 months ago by asn

Replying to asn:

Replying to antonela:

What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?

I think the concept is reasonable, but I don't have much insight on how good this will be for users VS other options that I can't imagine right now. e.g. I'm not sure if people will be helped by knowing that the problem is on the network or not.

Leaving that aside, and assuming that the idea is the best one (which is fine by me), I need to say that sometimes it's not clear where the error is (e.g. in 'F2' and 'F3' where the intro/rend fails, it's not clear whether the problem is on the network or the service itself), so in those cases I'm not sure which button should light up. I think it would be a bad idea to tell users that the problem is on the service, when actually it's just a bad rendezvous point and it would be solved by reconnecting. And given that 'F2' and 'F3' are hard to classify, and 'F1' should never really appear, I'm not sure what would be the class of 'network-level errors'.

I've been noticing the cloudflare error pages much more lately, and I actually like how they present the problem. I think it would work nicely (altho we would need to think of the technical issues detailed above).

comment:11 Changed 7 months ago by sysrqb

Keywords: TorBrowserTeam202001 added

comment:12 in reply to:  6 ; Changed 5 months ago by mcs

Replying to antonela:

What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?

On the implementation side, it should be possible to add a new internal error page (e.g., about:onionerror) and have code that changes its look using CSS and JS. Using that approach i should be straightforward to include the three-part graphic (Browser / Tor Network / Host)... but we need to resolve the issues raised in comment:8.

Maybe the graphic does not add much value and we should instead focus on creating good textual descriptions with actionable advice.

Implementation would be be easier if we could reuse Firefox's existing about:neterror page layout and elements. Maybe that is not feasible if we decided to keep the Browser / Tor Network / Host graphic though, because Mozilla only includes a graphic on the left side. Load this link to see an example:
about:neterror?e=dnsNotFound&d=We%20can't%20connect%20to%20the%20server%20at%20foozat.com

If we do keep the three-part graphic, do you think it would be an improvement to change the Host label to Onion Site?

comment:13 in reply to:  8 Changed 5 months ago by pili

Replying to asn:

Replying to antonela:

What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?

I think the concept is reasonable, but I don't have much insight on how good this will be for users VS other options that I can't imagine right now. e.g. I'm not sure if people will be helped by knowing that the problem is on the network or not.

With "network-level" errors, I think if that we can at least rule out that the issue lies with the browser, then we can suggest a number of strategies to users e.g to try to reconnect to the service, in order to help them out

Leaving that aside, and assuming that the idea is the best one (which is fine by me), I need to say that sometimes it's not clear where the error is (e.g. in 'F2' and 'F3' where the intro/rend fails, it's not clear whether the problem is on the network or the service itself), so in those cases I'm not sure which button should light up. I think it would be a bad idea to tell users that the problem is on the service, when actually it's just a bad rendezvous point and it would be solved by reconnecting. And given that 'F2' and 'F3' are hard to classify, and 'F1' should never really appear, I'm not sure what would be the class of 'network-level errors'.

In that case we should define what these graphics would look like for each of the error codes that we know tor will surface to the browser. I think it's fine to show some ambiguity in the graphics (e.g a question mark instead of a tick or a cross at the Tor Network and Host icons) as long as we suggest some next steps for the user, depending on the error code.

I think a good next step would be to map all of these out together and see what comes out.

comment:14 in reply to:  12 Changed 5 months ago by pili

Replying to mcs:

Replying to antonela:

What do you think? Is the graph accurate? Could it work for each scenario? Is it too complicated to have custom error pages for each scenario? I see it feasible with just CSS, but is it doable on the browser side?

On the implementation side, it should be possible to add a new internal error page (e.g., about:onionerror) and have code that changes its look using CSS and JS. Using that approach i should be straightforward to include the three-part graphic (Browser / Tor Network / Host)... but we need to resolve the issues raised in comment:8.

Maybe the graphic does not add much value and we should instead focus on creating good textual descriptions with actionable advice.

I think the three-part graphic is very useful to educate users about a) where the problem lies b) how onion services work. Also, remember we have the user testing program to test these options out.

Implementation would be be easier if we could reuse Firefox's existing about:neterror page layout and elements. Maybe that is not feasible if we decided to keep the Browser / Tor Network / Host graphic though, because Mozilla only includes a graphic on the left side. Load this link to see an example:
about:neterror?e=dnsNotFound&d=We%20can't%20connect%20to%20the%20server%20at%20foozat.com

We should try to keep it if we can. If it is going to take significantly longer to do than a simpler error page, we should evaluate doing a first, simple iteration with the aim of implementing this later on, once the S27 project is over.

If we do keep the three-part graphic, do you think it would be an improvement to change the Host label to Onion Site?

+1

comment:15 Changed 5 months ago by gk

It seems we had #10864 for this task. .) Resolving that ticket as duplicate.

comment:16 Changed 4 months ago by mcs

Points: 6

comment:17 in reply to:  12 Changed 4 months ago by antonela

Replying to mcs:

Thanks for your review!

Implementation would be be easier if we could reuse Firefox's existing about:neterror page layout and elements. Maybe that is not feasible if we decided to keep the Browser / Tor Network / Host graphic though, because Mozilla only includes a graphic on the left side. Load this link to see an example:
about:neterror?e=dnsNotFound&d=We%20can't%20connect%20to%20the%20server%20at%20foozat.com

Yes for sure. We can re-use about:neterror. I do think the 3 steps graph is very useful for users, but if we decide that such implementation is out-of-scope, then we can move forward with just a title and a description.

If we do keep the three-part graphic, do you think it would be an improvement to change the Host label to Onion Site?

Yes, it's a great idea.

comment:18 Changed 4 months ago by mcs

Cc: tbb-team added
Owner: changed from tbb-team to brade
Status: newassigned

comment:19 Changed 4 months ago by antonela

Hi! I've tried a markup here

https://onion-error.glitch.me/

Still need assets and LTR<>RTL support.

comment:20 Changed 4 months ago by brade

Did you decide against a vertical arrangement for the browser/network/onion service graphics? (Maybe it's not workable)

comment:21 in reply to:  20 ; Changed 4 months ago by mcs

Replying to brade:

Did you decide against a vertical arrangement for the browser/network/onion service graphics? (Maybe it's not workable)

Antonela — in case it matters, Kathy and I think we have found a way to make a horizontal layout work within the existing about:netError page. I assume for a RTL locale we just want to reverse the order of the 3 images?

comment:22 in reply to:  21 Changed 4 months ago by antonela

Replying to mcs:

Replying to brade:

Did you decide against a vertical arrangement for the browser/network/onion service graphics? (Maybe it's not workable)

Antonela — in case it matters, Kathy and I think we have found a way to make a horizontal layout work within the existing about:netError page.

Awesome!

I assume for a RTL locale we just want to reverse the order of the 3 images?

Yes, that'd be ideal.

I'm working on exporting the proper assets for the icons. Will update them here soonish.

comment:23 Changed 4 months ago by brade

I created a child ticket for the task of creating all of the necessary strings: #33035.

comment:24 Changed 4 months ago by mcs

Actual Points: 2.1

comment:25 Changed 4 months ago by antonela

Hi! I've iterated over the originally proposed icons set and I'd like your feedback on that.

Basically, we've been discussing that using the onion icon would confuse users, so a regular cloud and server reference may help on illustrating these errors.

Also, as suggested in comment:12, I do think we should go with Onionsite. Do you think is better to have it as one-word like "website" or is it better to have two words like Onion Site. I think the former is nicer.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/1-errorpage-graph-2.png

Changed 4 months ago by antonela

Attachment: 1-errorpage-graph-2.png added

Changed 4 months ago by antonela

Attachment: assets.zip added

comment:26 Changed 4 months ago by mcs

Actual Points: 2.13.1

comment:27 Changed 4 months ago by brade

Personally I like the thinner lines in the "A" line for the browser and onionsite graphics (as compared to the "C" line). In particular, the fat lines of the browser window makes the toolbar seem disproportionately large.

I'm concerned that using a cloud graphic may confuse users about what the Tor Network is. I think many users will think of a cloud (on the Internet) as the place where they store images and files rather than the network. We should also be careful about reusing the Tor Browser icon to represent Network or Onionsite. Ticket #23486 includes some other ideas for icons, although our design ideas have evolved since that ticket was updated.

For "onion site" vs "onionsite", I'm ok with either term. I am curious how "website" localizes. If we are coining a new term in English ("onionsite") will our translators be able to create an equivalent term in their language? I assume they can handle it, but maybe we should check with emmapeel.

comment:28 Changed 4 months ago by pili

Keywords: TorBrowserTeam202002 added; TorBrowserTeam202001 removed

Moving tickets to February

comment:29 Changed 4 months ago by mcs

Actual Points: 3.13.9

Changed 3 months ago by antonela

Attachment: 1-errorpage - grayshade.png added

Changed 3 months ago by antonela

Attachment: 1-errorpage - outline.png added

Changed 3 months ago by antonela

Attachment: 1-errorpage - colored.png added

comment:30 Changed 3 months ago by antonela

I'm back here to commenting the UI specs. So, I've uploaded two options. I think we are OK having everything on a grayscale. If that is the path we are taking, everything looks clean and clear if we use the same color for the icon and for the status container. I added a 3px solid border around it to make the shape outstand.

https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/1-errorpage%20-%20outline.png

Colors are from https://design.firefox.com/photon/visuals/color.html#icons-and-other-elements

  • Light theme: Grey 90 a80 rgba(12, 12, 13, 0.8);
  • Dark theme: Grey 10 a80 rgba(249, 249, 250, 0.8);

Changed 3 months ago by mcs

Attachment: error-0xF0-rev2.png added

0xF0 error page (WIP)

comment:31 Changed 3 months ago by mcs

It seems that the error pages (about:netError) do not currently support a dark theme; at least on macOS, the colors used on that page do not change when in dark mode. Kathy and I cannot find a Bugzilla bug for that issue, but we think we should skip dark theme support for now.

We tried using the Grey 90 a80 color, but we need to avoid transparency. With transparency, the Browser/Network/Onionsite images show through the circles that surround the checkmark and (x) icons, and the Onionsite image is not a consistent color (apparently, some of the paths within the SVG overlap). Here is what it looks like with Grey 70 (no transparency); Kathy and I think the result is close to your mockup:

https://trac.torproject.org/projects/tor/raw-attachment/ticket/19251/error-0xF0-rev2.png

What do you think?

comment:32 Changed 3 months ago by mcs

Actual Points: 3.94.5

comment:33 Changed 3 months ago by mcs

Keywords: TorBrowserTeam202002R added; TorBrowserTeam202002 removed
Reviewer: acat,pospeselr
Status: assignedneeds_review

While we are waiting for strings (#33035), Kathy and I think it would be OK to do a first round of reviews of the implementation.

For Torbutton we added strings for the error pages (currently, most of them are placeholders and therefore they are not ready for translation).

For the browser, we did the following:

  • Added an OnionServicesAboutNetError module which enhances Firefox's built-in about:netError page to add descriptive text that is tailored to each onion service error as well as a visual diagram to help people understand where the error occurred.
  • Added support for two additional SOCKS extended errors: SOCKS5_HS_BAD_ADDRESS (typo in .onion address) and SOCKS5_HS_INTRO_TIMEDOUT (introduction timed out).
  • Made changes to the onion service authentication prompt logic so the browser displays an appropriate error page after the prompt is canceled.

https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-01&id=0979f4acf33539cd12d8bcf89f8e18d69bc5ce99

https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug19251-01&id=eb4443ba40b28d6984e7142773004823a5460b68

I added Alex and Richard as reviewers.
Matt: please change that if you have a different idea.

comment:34 Changed 3 months ago by mcs

Actual Points: 4.55

comment:35 Changed 3 months ago by mcs

Keywords: TorBrowserTeam202002 added; TorBrowserTeam202002R removed
Status: needs_reviewneeds_revision

I am taking this out of review for now because Kathy and I found a bug in the browser patch (in browser/components/onionservices/content/authUtil.jsm the reference to this.string.clientAuthMissingTopic needs to be replaced with this.topic.clientAuthMissing). Hopefully we will have the English strings soon (from #33035) so we can put them in a revised patch as well.

Last edited 3 months ago by mcs (previous) (diff)

comment:36 Changed 3 months ago by pili

Keywords: TorBrowserTeam202003 added; TorBrowserTeam202002 removed

We are no longer in February, moving tickets

comment:37 Changed 3 months ago by mcs

Actual Points: 56.3

comment:38 Changed 3 months ago by mcs

Keywords: TorBrowserTeam202003R added; TorBrowserTeam202003 removed
Status: needs_revisionneeds_review

We rebased the patches (to torbutton master and to the tor-browser-68.5.0esr-9.5-1 branch), incorporated the final English strings from #33035, and fixed a couple of minor issues. We also removed the "Learn More" links for now. Here are the patches:

https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-02&id=542a8755b39a6f7a9d533f7df65c79d859f6ec72

https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug19251-02&id=33063ea49ad39c9a60a7440b3fde0d5a47bdb438

Please review.

comment:39 Changed 3 months ago by mcs

Actual Points: 6.36.7

comment:40 Changed 3 months ago by acat

The patches look good to me. Just a couple of nits for onionNetError.jsm:

  • Shouldn't this._insertStylesheet be after the errPrefix check? (so that the stylesheet is not added for non-onion errors).
  • Can't we just do ld.textContent = longDescription.replace("%S", hexErr); instead of using innerHTML (and remove the eslint-disable), or longDescription may contain HTML?

comment:41 in reply to:  40 ; Changed 2 months ago by mcs

Replying to acat:

The patches look good to me. Just a couple of nits for onionNetError.jsm:

  • Shouldn't this._insertStylesheet be after the errPrefix check? (so that the stylesheet is not added for non-onion errors).

Good catch. We will move it and post a revised patch once we receive review comments from Richard.

  • Can't we just do ld.textContent = longDescription.replace("%S", hexErr); instead of using innerHTML (and remove the eslint-disable), or longDescription may contain HTML?

Mozilla sometimes uses HTML in the long description; we essentially copied this code:
https://gitweb.torproject.org/tor-browser.git/tree/browser/base/content/aboutNetError.js?h=tor-browser-68.6.0esr-9.5-1#n233

Since we are not currently using any markup in that field we could use the textContent property. Or we could keep it as we wrote it and match Mozilla. What do other people think?

comment:42 in reply to:  41 Changed 2 months ago by mcs

Replying to mcs:

Since we are not currently using any markup in that field we could use the textContent property. Or we could keep it as we wrote it and match Mozilla. What do other people think?

During today's Sponsor 27 IRC meeting, we decided to match Mozilla and keep support for HTML.

Last edited 2 months ago by mcs (previous) (diff)

Changed 2 months ago by pospeselr

Attachment: browser.svg added

Changed 2 months ago by pospeselr

Attachment: network.svg added

Changed 2 months ago by pospeselr

Attachment: onionsite.svg added

comment:43 Changed 2 months ago by pospeselr

Ok, a few nits but overall looks good to me:

comment:44 Changed 2 months ago by mcs

Thank you for the reviews. Kathy and I made the suggested changes: we moved the this._insertStylesheet() call later plus we addressed everything from comment:43. We also rebased both patches on top of the latest tor-browser and Torbutton code. There were no actual changes to the Torbutton patch. New patches:

https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug19251-03&id=800293b5af438df25f89bae6e8c9b0abf4845c7e

https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-03&id=7ce7e376fc8f3e51cf5de04f1a254c9190e3364b

Please do another quick review.

comment:45 Changed 2 months ago by pospeselr

I would say make diagramInfoMap a member variable of OnionServicesAboutNetError to avoid rebuilding it each time _insertDiagram is called. Apart from that, looks good to me.

comment:46 in reply to:  45 ; Changed 2 months ago by mcs

Replying to pospeselr:

I would say make diagramInfoMap a member variable of OnionServicesAboutNetError to avoid rebuilding it each time _insertDiagram is called. Apart from that, looks good to me.

Thanks. Here is a revised tor-browser patch:
https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug30237-04&id=6cac185d0c10e4f26ca7eaf000c31fae36d13bfc

The Torbutton patch is unchanged:
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-03&id=7ce7e376fc8f3e51cf5de04f1a254c9190e3364b

comment:47 Changed 2 months ago by pospeselr

Looks good, assuming you meant tor-browser patch: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug19251-04

:)

comment:48 in reply to:  47 Changed 2 months ago by mcs

Replying to pospeselr:

Looks good, assuming you meant tor-browser patch: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug19251-04

Wow, how did I post that and not notice? Yes, the commit on the bug19251-04 branch is the one I meant.

comment:49 Changed 2 months ago by mcs

Actual Points: 6.77.1

comment:50 in reply to:  46 ; Changed 2 months ago by acat

Status: needs_reviewmerge_ready

The patches look good to me too.

Replying to mcs:

Replying to pospeselr:

I would say make diagramInfoMap a member variable of OnionServicesAboutNetError to avoid rebuilding it each time _insertDiagram is called. Apart from that, looks good to me.

Thanks. Here is a revised tor-browser patch:
https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug30237-04&id=6cac185d0c10e4f26ca7eaf000c31fae36d13bfc

The Torbutton patch is unchanged:
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-03&id=7ce7e376fc8f3e51cf5de04f1a254c9190e3364b

comment:51 Changed 8 weeks ago by pili

Keywords: TorBrowserTeam202004 added

We are no longer in March

comment:52 Changed 8 weeks ago by pili

Keywords: TorBrowserTeam202004R added; TorBrowserTeam202003R TorBrowserTeam202004 removed

comment:53 Changed 8 weeks ago by pili

We are no longer in March

comment:54 Changed 8 weeks ago by sysrqb

Cc: emmapeel added

comment:55 Changed 8 weeks ago by sysrqb

Status: merge_readyneeds_review

comment:56 Changed 8 weeks ago by emmapeel

@sysrqb, this looks good for l10n!

comment:57 in reply to:  50 Changed 8 weeks ago by sysrqb

Keywords: tbb-9.5a10 added
Resolution: fixed
Status: needs_reviewclosed

Replying to emmapeel:

@sysrqb, this looks good for l10n!

Thanks!

Replying to acat:

The patches look good to me too.

Replying to mcs:

Replying to pospeselr:

[snip]

https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug30237-04&id=6cac185d0c10e4f26ca7eaf000c31fae36d13bfc

Merged with commit 31200493ae908e01ecbeeb44e0546a354ea8736d

The Torbutton patch is unchanged:
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19251-03&id=7ce7e376fc8f3e51cf5de04f1a254c9190e3364b

Merged with commit 751a8d02b6ca5e7c8e2a05972c83f2776996f3d8.

Thanks for all your work on this!

Note: See TracTickets for help on using tickets.