Added iframe for statement's source

[wdestin]

Resolve CaptainFact/captain-fact#26

good.mp4

However, there are two downsides to this feature:

1. Not all websites are responsive

meh.mp4

2. Not all websites allow the integration of their content.

[Miragide]

C'est vraiment bien de pouvoir voir les sources sans quitter le site ! Merci

Des remarques suite aux tests :

1
« Not all websites allow the integration of their content. »
Comment informer l'utilisateur de cela ? Sinon, il va croire que CaptainFact bug.
Pouvons nous afficher un message lors que le contenu ne s'affiche pas, ou bien dans l'entete de l'iframe :
« si le site source n'autorise pas l'affichage, cliquer sur le lien ci-dessus [icone] »
?

2
Quand on ouvre l'iframe de la source, de nombreux utilisateurs n'auront pas le réflexe de cliquer sur la croix pour fermer la fenêtre de l'iframe, mais vont cliquer sur « précédent » (sur mobile surtout, car les personnes vont se croire sur une autre page).
Actuellement, cliquer sur précédent nous sort de la page vidéo, mais ne ferme pas la fenêtre de l'iframe. Les personnes sur mobile pensent que le bouton précédent ne fonctionne pas.
C'est possible que le bouton « précédent » ferme l'iframe ?

Alternative : faire en sorte que sur mobile, l'utilisateur voit un bout de la page de vérification, afin de lui permettre de cliquer dessus pour fermer l'iframe.
Ici par exemple (ce qui est aussi plus proche du pouce que la croix, pour fermer l'iframe).

3
Est ce que ce serait mieux de mettre la fenêtre de l'iframe à gauche, au lieu d'à droite ? Afin que l'utilisateur puisse comparer le contenu de la source avec les commentaires de la page de vérification qui apparaîtront alors à droite (si son écran est assez grand).

4
Je propose de mettre la croix en bleu ou en noir, pour être sûr que l'utilisateur ne la rate pas.

[Betree]

Ça en jette !

Il y a deux points qui restent de #765 (comment) qu'on devrait adresser, ça me semble assez important :

• Fermer l'iframe quand on clique sur Précedent : idéalement en écoutant pour un event "prev" dans la navigation, sinon on doit pouvoir bricoler quelque chose avec react-router.
• Ça serait effectivement chouette qu'on puisse détecter les erreurs et proposer un message maison. Je suis pas sûr qu'on puisse avoir ça depuis l'iframe, par contre on peut envoyer une requête HEAD en parallèle et regarder le contenu du header x-frame-options - dans 95% des cas c'est lui qui va nous bloquer. On peut alors afficher un truc du genre "Cette source n'est pas disponnible à la prévisualisation, cliquez ici pour l'ouvrir dans un nouvel onglet".

[wdestin]

Les 3 derniers points de @Miragide ont été réalisés.

Pour le premier point, après avoir essayé plusieurs solutions, j'en suis venu à la même conclusion @Betree.
Cependant, cette requête HEAD devra être faite par le serveur. Côté client, c'est bloqué (alors que l'iframe non). Tu penses que c'est envisageable ?

[Betree]

Les 3 derniers points de @Miragide ont été réalisés.

Pour le premier point, après avoir essayé plusieurs solutions, j'en suis venu à la même conclusion @Betree.
Cependant, cette requête HEAD devra être faite par le serveur. Côté client, c'est bloqué (alors que l'iframe non). Tu penses que c'est envisageable ?

Ça peut se tenter oui, la requête est bloquée à cause des CORS?

[wdestin]

Les 3 derniers points de @Miragide ont été réalisés.
Pour le premier point, après avoir essayé plusieurs solutions, j'en suis venu à la même conclusion @Betree.
Cependant, cette requête HEAD devra être faite par le serveur. Côté client, c'est bloqué (alors que l'iframe non). Tu penses que c'est envisageable ?

Ça peut se tenter oui, la requête est bloquée à cause des CORS?

Oui. J'ai ajouté la requête côté back et j'ai mis ce message pour résoudre le premier point de @Miragide :

Quand tu testeras en local, certains liens ne fonctionneront pas, c'est à cause de cette erreur :

[info] TLS :client: In state :wait_cert_cr at ssl_handshake.erl:1889 generated CLIENT ALERT: Fatal - Handshake Failure
 - {:bad_cert, :hostname_check_failed}

Une idée ?

[Betree]

This is a very good implementation, the code is clean & simple. Thank you for exploring this solution @wdestin ❤️

I'm a bit worried about this project, for mainly 3 reasons:

1. In terms of UX, sending an API request to check the source every time necessarily means an increased delay to access the source's content which might defeat the initial intent of being able to access sources faster.
2. It's tricky to rate-limit it because we don't want to block legit users from accessing the sources, yet with its current state it's very easy to use this endpoint to DDOS another URL (even if it's just a HEAD request).
3. I didn't see this complexity coming when I first proposed Show sources without leaving the website captain-fact#26. We can already see that there will be more work to do to make this really safe and useful for users, and to maintain it.

In my opinion, we should cancel the adoption of this feature for now. It's not a pleasure to put aside a great PR like this, but I'm really not confident merging such an important UX change without a proper scoping of all the aspects and a plan to maintain and iterate on it. Given the recent discussions, I also don't think that investing in that feature is a priority for us at the moment.

[wdestin]

I agree. We shouldn't implement a feature that doesn't work 100% of the time. It was fun to explore though. 😊