Skip to content
This repository has been archived by the owner on May 22, 2021. It is now read-only.

factored out progress into progress.js #457

Merged
merged 1 commit into from
Aug 7, 2017
Merged

Conversation

dannycoates
Copy link
Contributor

@dannycoates dannycoates commented Aug 6, 2017

Fixes #349
Fixes #366
Fixes #462

@dannycoates dannycoates requested a review from flodolo as a code owner August 6, 2017 16:04
@@ -62,7 +62,7 @@ class FileReceiver extends EventEmitter {
});
})
.then(([fdata, key]) => {
this.emit('decrypting', true);
this.emit('decrypting');
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out we don't really need the start/finish part of these events. Removing the finished case simplifies the listeners.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although I don't think it affects the outcome of the tests, I think we should change the frontend tests to reflect that these listeners only get called once.

@@ -50,6 +51,7 @@ downloadButtonLabel = Download
.title = Download
downloadNotification = Your download has completed.
downloadFinish = Download Complete
fileSizeProgress = ({ $partialSize } of { $totalSize })
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR adds a couple strings for l10n, but doesn't use them yet. @flodolo, is it a good idea to pre-stage strings so they can be translated before using them, or better just to use them now?

In fileSizeProgress case it's a new string previously not localized, whereas uploadingPageProgress will replace the uploadingPageHeader to be symmetric with downloadPageProgress.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general it's not a good idea to preland strings, because a) you won't have any way to test it and b) you might have to change your mind in the implementation phase.

Note: if this PR makes a string obsolete, that string should be removed.

$(() => {
gcmCompliant()
.then(() => {
$('#download-btn').on('click', download);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bumped download() up to make the "main" function cleaner.

@dannycoates dannycoates force-pushed the refactor-progress branch 2 times, most recently from 87c56bb to 6784bad Compare August 6, 2017 19:46
@dannycoates
Copy link
Contributor Author

now also fixes #349

@dannycoates
Copy link
Contributor Author

and fixes #366

@dannycoates dannycoates force-pushed the refactor-progress branch 2 times, most recently from 0bfc572 to 671cfc2 Compare August 7, 2017 00:06
@pdehaan
Copy link
Contributor

pdehaan commented Aug 7, 2017

Off-topic, but I think the "Fixes #___" only auto-closes the referenced bugs if you include it in the commit message or original PR comment.

typeof Intl.NumberFormat === 'function'
);

const UNITS = ['B', 'kB', 'MB', 'GB'];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this work for l10n? Is a "MB" the same in English, German, Japanese, Russian, etc?
/cc @flodolo @mathjazz

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We localize them, and you don't even need to go to a different script
https://transvision.mozfr.org/string/?entity=toolkit/chrome/mozapps/downloads/downloads.properties:megabyte&repo=central

Having said that, I wonder if we have access to them through Intl API @zbraniecki would know for sure.

Side note: kB is not going to be consistent with Firefox en-US (don't get me started)
https://hg.mozilla.org/mozilla-central/file/default/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties#l67

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, the https://github.com/zbraniecki/proposal-intl-unit-format has not been implemented yet in ECMA402 :(

? n.toLocaleString(navigator.language, {
minimumFractionDigits: 1,
maximumFractionDigits: 1
})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I've always struggled to understand localization...
Not sure I understand how this is working... What happens here if I have a local navigator.language of some non-supported localization on stage/prod (like Hebrew, for example), but I get a match on my second or third choice l20n fallback (such as Japanese)? Would the numbers be displayed in my preferred Hebrew language format, but the surrounding text be Japanese because that is one of the official production availableLanguages? Or am I totally missing something?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zbraniecki or @stas
Any advice?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First of all, never use navigator.language, use navigator.languages - this is a fallback chain of your preferred languages.

Now, what do you mean by "my second or third choice l20n fallback"? If I understand correctly this is a website, so it will get navigator.languages as a fallback chain from the user.
You just have to pass it to toLocaleString and it'll pick the best locale matching the list.

Copy link
Contributor

@pdehaan pdehaan Aug 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zbraniecki Sorry, I was trying to explain that I only speak Hebrew, Japanese, and Bulgarian:

preferences

I wasn't sure if this meant that my file sizes would be in Hebrew (which is not an available language for Send), but the rest of the site would be Japanese (or Bulgarian, if Japanese wasn't an available language for Firefox Send site + l20n).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure if this meant that my file sizes would be in Hebrew (which is not an available language for Send), but the rest of the site would be Japanese (or Bulgarian, if Japanese wasn't an available language for Firefox Send site + l20n).

Ah, yes. If you pass navigator.languages it will be ["he", "ja", 'bg"]. Since all browsers carry NumberFormat data for he, we'll format into he.

If you want to link the raw Intl API to use the same languages as were negotiated for l20n, you need to retrieve the result of language negotiation for l20n.

I'm not sure how this API currently works, but it should be something along the lines of document.l10n.locales which should be the list of locales that l20n negotiated down to.
Since he is not available, the list would end up being sth like ['ja', 'bg', 'en-US'] assuming both ja and bg are available, and en-US is the last fallback.

In that case, passing that list fo the Intl API will do the right thing for you.

I haven't been working with l20n.js package in a while, so CC'ing @stasm, who's maintaining it - he will hopefully be able to point out how to retrieve the negotiated locale list from l20n to pass to the Intl API.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I missed the notification for this. l20n.js exposes the currently negotiated languages in the langs attribute of the <html> element. You can access it with document.documentElement.getAttribute('langs'). It's a space-separated list of local codes.

<span id="dl-file"
data-filename="{{filename}}"
data-size="{{sizeInBytes}}"
data-ttl="{{ttl}}"
data-l10n-id="downloadFileName"
data-l10n-args='{"filename": "{{filename}}"}'></span>
Copy link
Contributor

@pdehaan pdehaan Aug 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated to this glorious PR, but looking at it with my special eyes, I think this is a bug...
I can seemingly break the download page hard on production by uploading a file with a pair of double quotes in the filename. Not sure if we can encode the filename here (and on line 6 above, and possibly elsewhere, or whatever).


UPDATE: Filed as #462, "File downloads break if you have a double quote in the filename".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch @pdehaan. We ought to be doing data-l10n-args='{{JSON.stringify({filename})}}'

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly a few places:

$ git grep -n "{{filename}}"

views/download.handlebars:7:       data-l10n-args='{"filename": "{{filename}}"}'></span>
views/download.handlebars:23:      data-l10n-args='{"filename": "{{filename}}", "size": "{{filesize}}"}'>
views/download.handlebars:34:      <div class="progress-text">{{filename}}</div>

@dannycoates dannycoates merged commit d2b5703 into master Aug 7, 2017
@pdehaan pdehaan deleted the refactor-progress branch August 10, 2017 16:17
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants