Implement loading (only) local change notes after a Tor Browser update
In #13512 (moved) we implemented showing change notes after a Tor Browser update. This is essentially done by loading the blog post on first start after the update. There were some concerns mainly over the reliability of this procedure which led to the idea to implement parts or all of this mechanism using local resources.
Activity
Quoting comment:32:ticket:13512:
Replying to gk:
One final thing I am wondering is whether we really should contact the blog or an external resource after an update. If that goes wrong (mybe there is an issue with the server, or whatever) the users are seeing a weird error message instead of the site we want to show them and instead of the familiar about:tor page (which is now a backgounrd tab). And we put additional load on the Tor network (an on the server hosting the blog) instead of using the changelog we ship with the browser. These concerns might be for a follow-up bug, though (while we are testing the things we have so far in the alpha cycle).
I am not sure how concerned we should be about the network load but if an error occurs while loading the page, that could be confusing. We could create a local page (about:update or similar) that just said "An update has been applied" which also included a link (or an iframe) that pointed to a remote page. We would need to figure out how to pass the remote link to the about:update page.
Alternatively, we could create a local page that displayed the top part of ChangeLog.txt. But doing that would take away a major benefit of loading a remote page: no ability to inform the user about issues and/or workarounds we learn after release.
Or we could combine both approaches. Any approach that reads ChangeLog.txt would require us to standardize the format of that file (e.g., a blank line separates the info for one versions from the next).
We now have an implementation. Please review. Part 1 is in tor-browser: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug16940-01&id=0d181256ab1c42caf75108ef193f31eeee2ad961
Part 2 is in torbutton (localizable strings): https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug16940-01&id=9b800ffc669f7eb7dd6203a24aa85a39b5edd154
We will also need to add the aboutTBUpdate.dtd file to Transifex; the changes we made to import-translations.sh in torbutton assume that the new translations.git branch will be named torbutton-abouttbupdatedtd.
Trac:
Status: needs_information to needs_review-
Replying to gk:
I wonder whether having
linkPrefixandlinkLabelthat way is causing trouble for translators. My gut tells me "yes". The languages I am able to speak "no". Hm...I am not sure, but this approach does provide flexibility, assuming the localizers are not confused by it. We did something very similar for the about:tor page (see aboutTor.failure3prefix.label, aboutTor.failure3Link, and aboutTor.failure3suffix.label within aboutTor.dtd). So far it looks like no one has needed to change the suffix (".").
-
Replying to mcs:
Replying to gk:
I wonder whether having
linkPrefixandlinkLabelthat way is causing trouble for translators. My gut tells me "yes". The languages I am able to speak "no". Hm...I am not sure, but this approach does provide flexibility, assuming the localizers are not confused by it. We did something very similar for the about:tor page (see aboutTor.failure3prefix.label, aboutTor.failure3Link, and aboutTor.failure3suffix.label within aboutTor.dtd). So far it looks like no one has needed to change the suffix (".").
Okay, sounds like it is working that way, fine with me.
I've tested the patches on Linux and local change notes are working + the code looks good. Nice job! Just two things occurred to me while testing/reading the code:
- Should we prepend the value for
startup.homepage_override_urlwithabout:tbupdate?as well? - I wonder if we should update the comment above this preference to explain what is going on as we don't do this anywhere as far as I can see. And using
openURLgives the wrong impression as we won't open the one mentioned there usually. Thus, folks might be confused. If not there, were else could mention the "hijacking" of theopenURLparameter?
- Should we prepend the value for
-
Replying to gk:
I've tested the patches on Linux and local change notes are working + the code looks good. Nice job! Just two things occurred to me while testing/reading the code:
- Should we prepend the value for
startup.homepage_override_urlwithabout:tbupdate?as well?
about:tbupdate? will be prepended to the overridePage whenever the browser is starting immediately after applying an update (app.update.postupdate). After the call to getPostUpdateOverridePage(), the overridePage value might be the startup.homepage_override_url, the value from the update manifest (XML from the server), or an empty string. So about:tbupdate? will be added to startup.homepage_override_url. Or are we missing something?
- I wonder if we should update the comment above this preference to explain what is going on as we don't do this anywhere as far as I can see. And using
openURLgives the wrong impression as we won't open the one mentioned there usually. Thus, folks might be confused. If not there, were else could mention the "hijacking" of theopenURLparameter?
We will update the comment.
- Should we prepend the value for
-
Replying to mcs:
Replying to gk:
I've tested the patches on Linux and local change notes are working + the code looks good. Nice job! Just two things occurred to me while testing/reading the code:
- Should we prepend the value for
startup.homepage_override_urlwithabout:tbupdate?as well?
about:tbupdate? will be prepended to the overridePage whenever the browser is starting immediately after applying an update (app.update.postupdate). After the call to getPostUpdateOverridePage(), the overridePage value might be the startup.homepage_override_url, the value from the update manifest (XML from the server), or an empty string. So about:tbupdate? will be added to startup.homepage_override_url. Or are we missing something?
I tested the update changes by applying a MAR-file by hand and then the currently specified URL got loaded without
about:tbupdate?prepended. I guess there are people with a bunch of tinfoil-hats out there doing this kind of thing regularly, so I was wondering. - Should we prepend the value for
-
Replying to gk:
I tested the update changes by applying a MAR-file by hand and then the currently specified URL got loaded without
about:tbupdate?prepended. I guess there are people with a bunch of tinfoil-hats out there doing this kind of thing regularly, so I was wondering.Ah. Kathy and I had not considered that scenario. I think we will remove the app.update.postupdate pref. check; doing so will cause about:tbupdate to be opened whenever a restart occurs after new bits have been installed. I think about:tbupdate will also be opened in a downgrade situation, but that is probably OK too (and downgrades should only happen if someone manually applies an update or if they modify hidden prefs such as browser.startup.homepage_override.mstone and browser.startup.homepage_override.torbrowser.version).
-
Please review the following revised tor-browser patch: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug16940-02&id=4a726fc8a675c0882cbfba2514deb32b53ade2ab (compared to the previous patch, we only made changes inside browser/components/nsBrowserContentHandler.js)
The torbutton patch is the same as before: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug16940-02&id=4a726fc8a675c0882cbfba2514deb32b53ade2ab.
-
See also #17729 (moved) (need to add aboutTBUpdate.dtd to Transifex).
-
See #17917 (moved) for a follow up ticket.
mentioned in issue #17729 (moved)
mentioned in issue #21850 (moved)
mentioned in issue #25543 (moved)
mentioned in issue #25543 (moved)
mentioned in issue #30429 (moved)
mentioned in issue #30429 (moved)
mentioned in issue #34209 (moved)
mentioned in issue tpo/community/l10n#17729 (closed)
