Giorgio Maone:
> On 18/11/2015 19:54, sajolida wrote:
>>
>> I read this too fast. Actually, we don't want the extension to open the
>> file browser of the OS right now. After clicking on the "Next" button,
>> people will go through step-by-step instructions and we'll tell them
>> when to use the ISO image.
>
> So, when you click "Next" the extension should NOT open the file browser
> NOR reload the page to initial state, correct?
> What should happen exactly, instead? Should I just leave it up to you
> (i.e. the web page)?
Sorry for being unclear here. The cases where the extension should reset
were not super clear to us either until now. We gave it a second thought
this morning. We think that the extension should reset (ie. go back to
the state it is right after installing) in the following cases only:
1. The IDF has changed. I'm not sure exactly when the extension
downloads the IDF again as of now, but whenever the IDF changes (for
example if we issue an emergency release) and the user goes back to the
same page the extension should reset. We can probably skip the corner
cases when the IDF changes *while* the user is downloading.
2. The "Download again" button is clicked.
3. The "Cancel" button is clicked.
So yes, after giving it a second though, when the user clicks on the
"Next" button the extension should not reset. We'll simply use an href
to redirect to or toggle the rest of the instructions if needed. In some
cases the instructions might be on the very same page already and we
might not even have a "Next" button.
In other words, I think that we'll rescue the logic you had already for
the "Next" button and make it the "Download again" button.
Regarding opening the file browser, neither the "Download again" nor the
"Cancel" button nor the "Next" button should open the file browser.
But maybe we might want to open the file browser from the same page,
later on in the rest of the instructions. But this would be outside of
the big div #download-and-verify. Can you still give us that possibility?
>> Here are the new issues:
>>
>> 1. Clicking the "Next" button should also bring back #use-button to
>> "show" and #use-text to "hide".
>
> So, if you click "Next", you get the "Use Firefox extension" button
> again visible, right?
> What is exactly supposed to happen when you click it, though?
Sorry but we're changing a bit our minds here. Forget about the "Next"
button. As said in the previous point, the "Download again" and "Cancel"
buttons should reset the full state of the page as when the extension
was installed. That means with the "Use Firefox extension" (and the
minor BitTorrent option) visible again.
We might find a better wording for the "Download again" button but the
idea is to give the user a way of resetting everything. For example, if
they come back after delete the ISO or something...
>> 2. #bittorrent-minor should also be visible when #use-button
>> and #install-button are visible. See slides 3 and 4.
>
> OK, done in latest commit.
I don't see this. I tested with 0.2.5 and it didn't work. I also don't
see any change while search on 'bittorrent' in the Git history as of
1039f5f. Maybe you forgot to push?
>> 3. Clicking #use-button or #install-button should #i_have_iso (when
>> the download starts).
> You mean *hide* #i_have_iso, correct? Tentatively done, then.
Sorry for the missing word. You understand correctly, I meant "Clicking
#use-button or #install-button should hide #i_have_iso". Still, I don't
see this in 0.2.5. See screenshot in attachment.
>> 4. The page reloads every 10s. Why? It makes it blink pretty badly on
>> Tor Browser and also sometimes loses state.
>
> Weird, can you consistently reproduce, and how?
Yes, when in Tails, Tor Browser outside of Tails and FF38. See this
screencast. The first blinking and reset appears at 0:49, then it goes on:
https://dl.poivron.org/p27bqufzog2ekqmkqttt-cbt2g3hglv62s4jv
Note that I need to force a reload of the page for this to happen. If I
don't reload the page it doesn't blink.
>> 5. We tried in 26642eb to add a link below the "Next" button to reset
>> the page as well but it didn't work. Are you triggering the
>> cancelation only on the *first* "#verify-text-success .btn" in line
>> 207-210?
>
> Yes I was. Fixed in latest commits.
Ack.
>> 6. We tried in 7bcda1a to replace the URL in the download button with
>> the size in MiB but it failed. Maybe you should set iso-size-MiB in
>> updateBlobView around line 88.
>
> Fixed.
Ack.
>> 7. We managed to get a negative ETA displayed :) See screenshot in
>> attachment.
>
> I couldn't find any screenshot, sorry.
Damn... then I lost it forever...
>> 8. When doing "Resume", the progress bar goes to 100%, displays ???,
>> and then go back to where it was once the download really started
>> again. The progress bar should instead freeze where it is until the
>> download starts again for real.
>
> Tentatively fixed in 0.2.5
Ack for the progress bar. Now, there's still a minor glitch as the
displayed size temporarily goes down to 0/30 MiB see the screenshot in
attachment.
And maybe the speed should go to 0 instead of displaying ???.
>> 9. #verify-text-label should be visible once #download is visible. See
>> slide 11. We should be able to change its opacity until we get to
>> the verification state.
>
> And it shouldn't be clickable either, correct?
Yes. I should only give an insight on what's the next step.
> So I suppose the
> extension should manage both the disabled state (maybe setting an
> attribute that you can use to style the button) and behavior, correct?
Right.
