Project

General

Profile

Bug #14962

Tor Browser >= 7.0.8 fails to render local pages correctly

Added by anonym 2 months ago. Updated 1 day ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
11/16/2017
Due date:
% Done:

100%

QA Check:
Feature Branch:
Type of work:
User interface design
Blueprint:
Starter:
Affected tool:
Browser

Description

See: https://trac.torproject.org/projects/tor/ticket/24243

It certainly will not be fixed in time for Tails 3.3: https://lists.torproject.org/pipermail/tor-qa/2017-November/000929.html

Note that this also affects the Unsafe Browser (in fact, anything using Firefox).


Subtasks

Bug #14971: Remove translations of translations (sic) on unsafe browser warningResolvedintrigeri


Related issues

Related to Tails - Bug #14940: Upgrade Tor Browser to 7.0.10 Resolved 11/09/2017
Blocks Tails - Feature #13245: Core work 2018Q1: Foundations Team Confirmed 06/29/2017

Associated revisions

Revision 74536c6a (diff)
Added by anonym 2 months ago

tails-documentation: rewrite in Python + use WebKit for display.

... instead of using the Tor Browser: since version 7.0.8 it fails to
render local pages (like our docs) due to #14962.

Refs: #14962

Revision da835375
Added by anonym 2 months ago

Merge branch 'feature/14940-torbrowser-7.0.10' into stable

This includes the workaround for refs: #14962.

Fix-committed: #14940

Revision 08259afa (diff)
Added by anonym 2 months ago

Replace the Unsafe Browser's warning pages with static, pure-HTML versions.

This is truly a temporary workaround for refs: #14962.

Revision a02aafef (diff)
Added by anonym 2 months ago

Prevent Ikiwiki from formatting the Unsafe Browser warning pages.

This is a follow-up on 08259afa449f3dcd916fe03db5775f3652f5a7e8.

Due to #14962 we really only want the simple text-only HTML page
without all the Ikiwiki formatting added. I'm very ignorant of
Ikiwiki, so this hack is the best I could come up with so I can
quickly rebuild Tails 3.3. I'm also sloppy: I verified my assumption
that those .html pages would be left unprocessed...

Refs: #14962

History

#1 Updated by anonym 2 months ago

  • Related to Bug #14940: Upgrade Tor Browser to 7.0.10 added

#2 Updated by anonym 2 months ago

#3 Updated by anonym 2 months ago

  • Status changed from Confirmed to In Progress

#4 Updated by anonym 2 months ago

These are the commits implementing workarounds for this bug in Tails 3.3:

We definitely want to have 08259afa reverted once upstream is fixed, but we might want to consider keeping 74536c6a & co.

#5 Updated by anonym 2 months ago

Actually, 7d9be782a175ab3a3d583590422f4cebf307f03a and friends should probably be "ported" back into the Greeter.

#6 Updated by sajolida 2 months ago

In Tails 3.3, the Python version doesn't have our sidebar and no "Back" button which makes the thing barely usable. So if Tor:#24243 can be fixed I'd rather go this way...

#7 Updated by anonym 2 months ago

  • Assignee changed from anonym to sajolida
  • QA Check set to Info Needed

sajolida wrote:

In Tails 3.3, the Python version doesn't have our sidebar

That is intentional. The new doc viewer uses the same code as the Greeter's help veiwer, and there we deliberately disable the sidebar, and I think we do that for good reasons that apply equally in this context. Hiding the sidebar is a great way to cheaply convert our website into something that is more like offline docs: the side bar otherwise distracts and confuses by showing things like

  • "Install Tails", which they clearly already have done
  • "News", which might be outdated
  • "Contribute", which is for a very small set of users: if we want to expose this, we could provide a separate launcher somewhere

As long as you use the correct entry-point you'll find what you need without the sidebar:

  • "Report an Error" launcher ⇒ "Support", which shows just what you need about the subject, not more
  • "Tails documentation" ⇒ "Getting started...", which links to the all things of the sidebar which are relevant for users

To me it seems like the sidebar mostly is helpful if you want to reach some part of the documentation from the wrong entry-point. I suppose that isn't bad, since it is more forgiving, but I don't find it a "must have", and I certainly think the removal of the sidebar's distractions is more important.

Am I missing something? I thought I for once got UX a bit, but apparently it just lead us to controversy! :P just to be clear: I'm not defensive, just a wee bit disappointed that I apparently failed. ¯\_(ツ)_/¯

and no "Back" button which makes the thing barely usable.

Huh. Either you just missed that there is one in the header bar (but only if there actually is history to go back to), or you found a bug. Can you provide steps to reproduce if the latter?

No "Forward" button is provided, but I thought adding one would just add bloat: if your history is "site A -> site B", and you click "back" then you end up at the place of site A that linked to site B, so going forward again is just a matter of clicking the same link again.

#8 Updated by segfault 2 months ago

I agree with anonym on the sidebar, I don't think it is needed and would actually only add distraction to the doc viewer.
And the back button works for me.

I really like the new doc viewer, primarily because it's so friggin fast :) So I'm in favor of keeping it even after Tor:#24243 is fixed.

#9 Updated by intrigeri 20 days ago

#10 Updated by intrigeri 20 days ago

#11 Updated by sajolida 2 days ago

  • Assignee changed from sajolida to anonym
  • QA Check changed from Info Needed to Dev Needed

Indeed, I missed the "Back" button when I first looked for it. The same might happen to others.

Something else I thought about is that we sometimes give file:/// URLs in our doc and code for people to visit and that's not possible to copy and paste in GNOME Help.

If speed of opening is the only argument in favor of GNOME Help, then I'm still pretty much against it. I think that being in the familiar environment of a browser is more important than speed of opening. Especially since people most likely already have a browser open or will open one later on.

But this ticket is about fixing the display of local pages in Tor Browser which is something we want to do independently from my opinion on GNOME Help, right?

#12 Updated by intrigeri 1 day ago

  • Assignee changed from anonym to sajolida
  • QA Check deleted (Dev Needed)
  • Type of work changed from Wait to User interface design

I see no indication that this regression will be fixed any time soon so IMO we should move on, acknowledge this bug and decide what's the best workaround to it.

I don't see it mentioned here, so here we go: we still have the option to point to online URLs instead of file:/// ones, as I suggested back when we discovered this Tor Browser regression. Of course it would not work offline but at least it would work reliably online, we don't have to discover and fix bugs like #15160 along the way, the corresponding test suite regression is fixed, and sajolida's point about UX is addressed. I don't know what's best but I think this should be sajolida's call.

Also available in: Atom PDF