Html2canvas: La correspondance d'arrêt de couleur échoue avec TypeError en raison d'une expression rationnelle défectueuse

Créé le 4 nov. 2014  ·  29Commentaires  ·  Source: niklasvh/html2canvas

Je vois un TypeError lors de l'utilisation de mots-clés de couleur (par exemple transparent , par opposition aux valeurs rgb() ) depuis la correspondance avec la regex "step" dans LinearGradientContainer retournera toujours null dans ce cas ( voir cette ligne ).

Pouvez-vous mettre à jour l'expression régulière pour qu'elle fonctionne comme prévu avec les mots-clés de couleur [a-z]+ ainsi que la notation fonctionnelle rgb() / rgba() ? Ou seriez-vous ouvert à une pull request qui fait exactement cela ? (Je peux même ajouter le support hsl() / hsla() à l'expression régulière, si vous voulez...) Merci !

Bug

Tous les 29 commentaires

Une pull request avec le correctif et des tests pour le supporter serait excellent !

En ce qui concerne la mise en œuvre de l'encart de style bordure, il est également nécessaire d'obtenir une analyse commune des couleurs, car elle doit assombrir/éclaircir les couleurs d'un pourcentage spécifique. Avec ce correctif de dégradé, s'il est nécessaire d'analyser les couleurs dans un format commun, cela pourrait également être utile avec le style border-style: inset.

Par exemple, si n'importe quelle couleur (hex, rgb, rgba, hls, hlsa, nom prédéfini tel que "rouge", "vert", etc.) pouvait être analysée dans l'objet Color avec r, g, b et une valeur définie, cela serait facilitent considérablement la mise en œuvre de l'encart de bordure également.

Convenu qu'une analyse/représentation de couleur commune peut et doit être réutilisée. Je garderai cela à l'esprit et j'aurai probablement des questions.

Je n'ai pas eu l'occasion de regarder cela pendant le week-end, j'aurai peut-être/espérons-le le temps demain.

Une mise à jour pour ceci?

Euh, désolé, pas encore. :/ J'ai été submergé et j'avais des ressources informatiques limitées, bien que j'aie mis en place quelques tests localement (je n'ai encore rien implémenté).

J'ai ajouté l'analyse de base des couleurs (nommées rgb, rgba, hex3 et hex6 jusqu'à présent) et j'ai modifié toutes les utilisations de la couleur pour les utiliser. Les expressions régulières de gradient n'ont pas encore été mises à jour.

Voir https://github.com/niklasvh/html2canvas/commit/313c227a1fed416331978e365ef82000ea7f7aa5

Joli! Je vais jeter un œil ce week-end et voir comment mettre à jour ces expressions régulières.

@niklasvh Pouvez-vous jeter un œil au commit que je viens de faire sur ma branche (359ee8b) et me dire ce que vous en pensez ? Je supprimerai mes commentaires superflus et ajouterai bientôt des tests pour les noms de couleurs, mais pouvez-vous également jeter un œil à l'autre changement ?

J'ai corrigé l'analyse de direction pour Firefox, donc certains dégradés linéaires qui ne s'affichaient pas correctement auparavant devraient maintenant fonctionner. Vous pouvez voir le test manuel que je viens de mettre temporairement dans tests/lineargradients_manual.html (essentiellement une copie de tests/cases/background/linear-gradient.html ). Je suppose que je peux vérifier l'augmentation de la précision et aucune régression sur d'autres navigateurs/versions une fois que les tests de sélénium peuvent être exécutés, mais pouvez-vous s'il vous plaît vérifier que tout va bien ? Je soupçonne que l'amélioration de la précision du rendu n'est visible qu'en comparant des versions plus récentes de FF que celles testées. (On dirait que la seule version de Firefox testée est la 15 ??)

Hmm, retenez cette pensée, j'ai peut-être fait quelque chose de bizarre, les carrés sur ma machine à la maison sont pour la plupart noirs maintenant..

Ah, non, on dirait que 498527918c3324dce77260057bc47c280cc3324f est le commit du problème, mes affaires ont l'air ok. :sweat_smile:

Que se passe-t-il si le pourcentage est autre que 100 % ou 0 % ?

Pour le moment, il ne prend pas en charge les pourcentages arbitraires (les laisse par défaut à 50%), mais je peux l'ajouter assez facilement. ( Mise à jour : ajout de la prise en charge des pourcentages arbitraires : 6af1874dc04c81d1aba5d6e8e6c8ef69681a2e49.)

Ce dont je ne suis pas sûr, ce sont les longueurs sans pourcentage, qui peuvent être en px , em , rem , ex , cm , mm , in , pc , pt , etc... Je ne l'ai pas encore cherché dans le code, mais vous avez déjà un moyen de gérer/convertir les longueurs de diverses unités ? (Si non, cela devrait-il faire partie de cette fonctionnalité ou devrait-il être mis en œuvre séparément ?)

les longueurs absolues devraient être faciles à implémenter, mais je pense que px devrait être suffisant pour commencer.

@niklasvh Je viens d'avoir un peu plus de temps pour regarder et travailler dessus. Pouvez-vous jeter un œil à ma branche fix-firefox-gradients et commenter avant que je fasse une pull request ?

Je dois noter que, bien que les expressions rationnelles puissent analyser les longueurs de pixels (à la fois dans les positions de début de dégradé et les positions d'arrêt de couleur), il n'y a toujours pas de support pour les rendre correctement. Je pense que le moyen le plus propre d'ajouter la prise en charge des longueurs absolues serait d'inclure des informations sur les limites avec les imageData qui sont passés dans les constructeurs de conteneurs dégradés, puis de les convertir en pourcentages. Cela devrait probablement aller dans une demande de tirage distincte, cependant.

Merci! J'examinerai cela de plus près sous peu et je vous recontacterai avec tout commentaire que je pourrais avoir

Des progrès à ce sujet ? C'est encore nécessaire !

Je suis prêt à faire une pull request si @niklasvh peut donner un coup de pouce à l'approche que j'ai utilisée sur ma branche.

:+1: Je viens de tomber sur ça :

TypeError: Cannot read property '1' of null at GradientContainer.<anonymous> (http://localhost:8100/all.js:34496:44) 
at Array.map (native) 
at GradientContainer.LinearGradientContainer (http://localhost:8100/all.js:34493:66)
at ImageLoader.279.ImageLoader.loadImage (http://localhost:8100/all.js:34367:16) 
at ImageLoader.<anonymous> (http://localhost:8100/all.js:34339:46) 
at Array.forEach (native) 
at ImageLoader.279.ImageLoader.addImage (http://localhost:8100/all.js:34337:23) 
at Array.forEach (native) 
at ImageLoader.279.ImageLoader.findBackgroundImage (http://localhost:8100/all.js:34331:71) 
at 295.exports.bind (http://localhost:8100/all.js:36357:25)

Salut @niklasvh ! Merci d'avoir corrigé #526.

Avez-vous déjà eu l'occasion de visiter ma succursale fix-firefox-gradients ? Je rebaserais ma branche (et corrigerais tout nouveau conflit) avant de faire le PR, mais veuillez me faire savoir si un PR serait toujours le bienvenu. (Pensez-vous que vous seriez en mesure de l'examiner dans un délai raisonnable ?) Merci !

@usmonster Non, désolé j'ai raté ça. Un problème potentiel auquel je pensais en faisant ce correctif est que si le navigateur décide de ne pas convertir les couleurs nommées telles que red ou blue en leurs rgb ou rgba valeurs, la simple prise en compte de transparent ne fonctionnerait pas. Le module Color prend en compte toutes les différentes variantes de couleurs, mais je ne suis pas tout à fait satisfait de la façon dont l'analyse actuelle est effectuée dans master pour commencer.

Avez-vous une idée de la façon dont les couleurs nommées pourraient être traitées ?

@niklasvh , La recherche et la normalisation déjà effectuées par le constructeur Color devraient être suffisantes pour gérer toutes les couleurs nommées, à moins que j'aie mal compris quelque chose ?

De plus, j'ai corrigé les expressions régulières utilisées pour analyser les couleurs et les dégradés linéaires afin de les rendre plus robustes, corrects et performants, donc je ne pense pas que les couleurs nommées devraient être un problème. Qu'est-ce que tu penses?

@usmonster Vous avez raison, je faisais référence à https://github.com/niklasvh/html2canvas/compare/master...usmonster :fix-firefox-gradients#diff-48b5afb6985c457b9f79fcca1cfb499dR21 que j'ai maintenant remarqué prend en compte les couleurs nommées, donc pas de problème là. Ça a l'air bien sinon, ça vous dérangerait de rebaser et de mettre en place une pull request ?

Aucun problème! Je vais essayer de jeter un œil dans les prochains jours - j'ai en quelque sorte raté ma fenêtre de week-end. :/

@niklasvh S'il

J'ai reçu "TypeError: colorStopMatch is null" à html2canvas.js:1454:13 dans FireFox. Dans Chrome ça marche.

Salut @Observer999 ! Ce problème est clos. Veuillez rechercher un problème ouvert similaire ou créer un nouveau problème avec un lien vers une page qui reproduit le problème que vous rencontrez. (Veuillez également spécifier la version de Firefox dans laquelle vous avez testé.) Je peux imaginer que cela pourrait avoir quelque chose à voir avec les TODO dans le code. Merci !

@usmonster @niklasvh Bonjour les gars, je sais que ce problème est fermé mais j'utilise la dernière version de html2canvas et j'obtiens la même erreur dans la dernière version de Chrome mais dans Firefox, cela fonctionne.

html2canvas.js : formaté : 1377 Uncaught (in promise) TypeError : Impossible de lire la propriété '1' de null
à LinearGradientContainer.(html2canvas.js:formaté:1377)
sur Array.map ()
au nouveau LinearGradientContainer (html2canvas.js:formatted:1374)
à ImageLoader.loadImage (html2canvas.js:formated:1256)
à ImageLoader.(html2canvas.js:formaté:1227)
à Array.forEach ()
à ImageLoader.(html2canvas.js:formaté:1225)
à Array.forEach ()
à ImageLoader.findBackgroundImage (html2canvas.js:formatted:1219)
sur html2canvas.js : formaté : 2563

Cette page vous a été utile?
0 / 5 - 0 notes