sajolida:
> Giorgio Maone:
>> On 18/11/2015 19:54, sajolida wrote:
Meta: I created a bunch of tickets on Redmine to track all these pending
issues. Feel free to reassign them to tchou if you think that should be
on our plate, or to me for review (using "QA Check: Ready for QA").
>>> 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?
I created #10682 to track the issue of opening the file browser.
>>> 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?
Created #10676 for that. Assigned to tchou for the moment.
>>> 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.
Created #10677 for that. Assigned to tchou as well.
>>> 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.
Created #10678 for this one.
>>> 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 ???.
Created #10679 assigned to tchou who can probably solve the "???". If
you think that you should be the one to fix the 0 MiB glitch, comment on
there.
>>> 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. It should only give an insight on what's the next step.
Created #10680 for this one.
And also #10681 for the MIME type thing.
