Some of our users skipped over the installation screen as it wasn’t clear
installation was a required action before proceeding.
Should reduce confusion as observed in #2130.
In anticipation of GitHub’s deprecation of anonymous gists, we are moving our
debug logs to https://debuglogs.org.
- [x] Publish debug logs to debuglogs.org:
- ~~Using jQuery v2.1.1-pre results in S3 error about invalid form data
indicating our jQuery version (added in 2014) doesn’t serialize
`FormData` correctly.~~
- [x] Using vanilla XHR ~~results in CORS error indicating our S3 bucket
doesn’t CORS headers but upload succeeds nonetheless.~~
- [x] Add CORS headers to https://debuglogs.org
- [x] Add CORS headers to S3 bucket (incl. `POST` requests):
https://s3.amazonaws.com/signal-debug-logs
**Sample log:** https://debuglogs.org/76bf1d7fd9b88ad061d91f79914230e45dc123bc8d169e073f10adb5c1999d4e
Updated export flow visuals to match registration/import in Standalone
(#2067)
New dismissable upgrade banner, with automatic display via incremental
rollout (#2067)
After the first export, all subsequent exports will be 'light' -
messages, contacts and groups only (#2067)
* Backup: Exclude all disappearing messages from export
* Reset overall statistics on start of backup
* Updated visual design for the export process
* On any export after first, don't include encryption info
* Wire up the upgrade banner with dismiss button
Unlike the previous implementation of this banner, it does not go away
when the user clicks on a conversation.
* Small tweak to the export error page: text width, error->isError
* Responding to PR feedback: some refactors, typo fix, dev server
- backupToDirectory -> exportToDirectory
- backup.js attachments -> numAttachments
- migration_view.js comment typo fix
- background.js revert back to the staging server url
- database.js remove dev-only commented-out migration
* Incremental rollout for upgrade banner
* Fix timing, address other PR feedback
* exportingToDirectory -> exportToDirectory
* inboxView: call proper method to show export process
* Remove unnecessary cancel() if first export was never finished
Since we do want to keep track of whether previous exports were even
attempted, this works against our 'light export/import' strategy. It's
also unnecessary, because the user will start at the first step of the
process.
* Log if we get the same value back from the s3 trigger file
* Migration.cancel() - don't reset 'everAttempted' flag
This would prevent us from doing the light export that second time
through.
Fix an issue where a mid-export or exported Chrome app would interfere
with Standalone app which imported its data
00ca91bc9b
and
a246e1a614
Dev:
- Harden top-level handler to strange incoming error shapes
We're seeing evidence of post-export Chrome apps causing problems with
the Standalone install that imported the data. They both try to rotate
signed prekeys.
Previously we just waited 5 or 10 seconds, and if it didn't work out,
then we just noted in the log.
Now we check for longer, and if any conversations are still not
well-formed after that long, we fail the export.
