ça me semblerai être un sacré échec de ne pas pouvoir utiliser HTML5 pour implémenter les quelques controls/boite de dialogues de Firefox en HTML/JS/CSS.
Ce n'est pas implémenter des boites de dialogues qui posent problème, c'est tout ce qu'il y a dans un navigateur.
browser.html, ce n'est pas un fichier html que l'on va mettre dans firefox en remplacement de XUL, et qui va tourner en mode privilégié comme le XUL. browser.html est une webapp. qui tourne donc dans une sandbox.
Du coup, comment dans l'interface on affiche par exemple l'historique de navigation (pour le gestionnaire de l'historique) ? comment accéder à la liste des mots de passe (pour le dialog de gestion des mots de passe) ? Comment modifier les préférences (pour une bonne partie des paramètres de la boite de préférences) ? Il y a aussi la gestion des "commandes" de l'interface, la gestion du copier coller, la gestion de la fenetre etc...
Bref, un navigateur, ce n'est pas juste afficher une page web, c'est aussi est surtout pouvoir gérer plein de truc autour. Et pour cela, il faut utiliser des API interne. Chose facile quand on est en XUL, parce que le code JS/XUL de Firefox (et celui des extensions XUL) tourne en mode privilégié (le mode chrome), et donc on peut appeler n'importe quel composant interne XPCOM.
Et le souci ici est que l'interface de browser.html, comme toutes les webapps, comme toutes les applis de FirefoxOS, tournent dans une sandbox. Pas d’accès direct à ces composants internes.
Il faut donc exposer, dans le contexte HTML, des API qui permettent de pouvoir faire ce qu'on pouvait faire en mode chrome.
Ces API étant souvent "sensibles", il y a un système de permissions.
Un exemple d'API, c'est l'api de navigation. Ça l'air con de gérer des onglets et la navigation : suffit de gérer des iframes, et dans chaque iframe, tu charges un site. Oui mais pas seulement. Comment surveiller l'état du chargement d'une iframe, afin de pouvoir afficher un throbber dans la barre d'url ? Comment stopper le chargement d'une iframe ? comment detecter justement que l'iframe démarre le chargement d'une nouvelle page, pour mettre à jour l'url dans la barre d'url ? Comment récupérer les informations sur le certificat SSL du site chargé afin de pouvoir les afficher quand on clique sur le cadenas ? etc etc etc... En mode chrome, aucun souci. Mais quand tu es dans une page HTML qui n'a pas les privilèges chrome, t'es à poil. En html standard, tu n'as pas d'API pour tout ça.
Il faut donc développer ces API (qui, techniquement, à leur tour, appellerons les apis interne de gecko). Tu as un début avec la browser API, mais ce n'est pas suffisant. Il faut une API pour accéder au contenu de l'historique complet, une API pour accéder aux certificats, et des centaines d'autres API. Et créer/gérer les permissions qui vont avec.
Bref, il y a encore beaucoup, beaucoup de boulot. C'est d'ailleurs la raison pour laquelle le "navigateur" dans FirefoxOS est encore si pauvre en fonctionnalité.
D'ailleurs, tu remarqueras que pour faire les trucs de bases (copy/paste/undo/redo) de browser.html, tout ça est géré dans un fichier XUL lancé en mode chrome.
Note: il y a eu le même problème pour les extensions de type jetpack (non xul donc), qui tournent dans une sandbox JS. Il a fallu exposer dans cette sandbox un certain nombre d'API pour accéder aux API internes de Gecko. Et implémenter tout ça ne s'est pas fait en un jour (raison pour laquelle on a encore accès à un module "chrome" pour accéder directement aux composants internes).
[^] # Re: Et quid du portage gtk3 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 35 heures. Évalué à 10.
Ce n'est pas implémenter des boites de dialogues qui posent problème, c'est tout ce qu'il y a dans un navigateur.
browser.html, ce n'est pas un fichier html que l'on va mettre dans firefox en remplacement de XUL, et qui va tourner en mode privilégié comme le XUL. browser.html est une webapp. qui tourne donc dans une sandbox.
Du coup, comment dans l'interface on affiche par exemple l'historique de navigation (pour le gestionnaire de l'historique) ? comment accéder à la liste des mots de passe (pour le dialog de gestion des mots de passe) ? Comment modifier les préférences (pour une bonne partie des paramètres de la boite de préférences) ? Il y a aussi la gestion des "commandes" de l'interface, la gestion du copier coller, la gestion de la fenetre etc...
Bref, un navigateur, ce n'est pas juste afficher une page web, c'est aussi est surtout pouvoir gérer plein de truc autour. Et pour cela, il faut utiliser des API interne. Chose facile quand on est en XUL, parce que le code JS/XUL de Firefox (et celui des extensions XUL) tourne en mode privilégié (le mode chrome), et donc on peut appeler n'importe quel composant interne XPCOM.
Et le souci ici est que l'interface de browser.html, comme toutes les webapps, comme toutes les applis de FirefoxOS, tournent dans une sandbox. Pas d’accès direct à ces composants internes.
Il faut donc exposer, dans le contexte HTML, des API qui permettent de pouvoir faire ce qu'on pouvait faire en mode chrome.
Ces API étant souvent "sensibles", il y a un système de permissions.
Un exemple d'API, c'est l'api de navigation. Ça l'air con de gérer des onglets et la navigation : suffit de gérer des iframes, et dans chaque iframe, tu charges un site. Oui mais pas seulement. Comment surveiller l'état du chargement d'une iframe, afin de pouvoir afficher un throbber dans la barre d'url ? Comment stopper le chargement d'une iframe ? comment detecter justement que l'iframe démarre le chargement d'une nouvelle page, pour mettre à jour l'url dans la barre d'url ? Comment récupérer les informations sur le certificat SSL du site chargé afin de pouvoir les afficher quand on clique sur le cadenas ? etc etc etc... En mode chrome, aucun souci. Mais quand tu es dans une page HTML qui n'a pas les privilèges chrome, t'es à poil. En html standard, tu n'as pas d'API pour tout ça.
Il faut donc développer ces API (qui, techniquement, à leur tour, appellerons les apis interne de gecko). Tu as un début avec la browser API, mais ce n'est pas suffisant. Il faut une API pour accéder au contenu de l'historique complet, une API pour accéder aux certificats, et des centaines d'autres API. Et créer/gérer les permissions qui vont avec.
Bref, il y a encore beaucoup, beaucoup de boulot. C'est d'ailleurs la raison pour laquelle le "navigateur" dans FirefoxOS est encore si pauvre en fonctionnalité.
D'ailleurs, tu remarqueras que pour faire les trucs de bases (copy/paste/undo/redo) de browser.html, tout ça est géré dans un fichier XUL lancé en mode chrome.
Note: il y a eu le même problème pour les extensions de type jetpack (non xul donc), qui tournent dans une sandbox JS. Il a fallu exposer dans cette sandbox un certain nombre d'API pour accéder aux API internes de Gecko. Et implémenter tout ça ne s'est pas fait en un jour (raison pour laquelle on a encore accès à un module "chrome" pour accéder directement aux composants internes).