Tor Browser >= 7.0.8 fails to render local pages correctly
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).
Replace the Unsafe Browser's warning pages with static, pure-HTML versions.
This is truly a temporary workaround for refs: #14962.
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...
These are the commits implementing workarounds for this bug in Tails 3.3:
- 74536c6a04c850db69686588723a9fec5060be7b with follow-ups:
- Assignee changed from anonym to sajolida
- QA Check set to Info Needed
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.
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.
- 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?
- Assignee changed from anonym to sajolida
- QA Check deleted (
- 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.