Greasemonkey: Après la mise à jour 3.11 -> 3.12, chaque fois que je ferme Firefox, il reste 2 instances firefox.exe

Créé le 21 sept. 2017 · 20Commentaires · Source: greasemonkey/greasemonkey

Utilisation de GM 3.11 (avec beaucoup de scripts d'utilisation et de paramètres stockés) dans FF 55.0.3 x64 dans win10.
Le multiprocessus est activé. Je cite à propos de:support :

Multiprocess Windows    1/1 (Enabled by default)
Web Content Processes   1/1

Chaque fois que j'exécute Firefox, je vois 3 instances firefox.exe dans le Gestionnaire des tâches _ (à condition que j'ai ouvert une page Web, pas seulement les pages internes de Firefox, sinon elles sont 2)_.

Donc, aujourd'hui, j'ai mis à jour GM 3.11 -> 3.12, redémarré Firefox (appuyé sur "Redémarrer maintenant"), tout semblait bien fonctionner, puis j'ai fermé Firefox :
J'ai remarqué dans le Gestionnaire des tâches que malheureusement, 2 processus firefox.exe sont restés
et après 1 min, le Mozilla Crash Reporter s'est affiché (et ces 2 processus ont finalement été terminés).
Voici le rapport de crash
et voici le bogue bugzilla associé : NtWaitForAlertByThreadId | SleepConditionVariableSRW | mozilla::CondVar::Wait | nsThread::nsChainedEventQueue::GetEvent |

Après cela, chaque fois que je ferme Firefox, 2 processus firefox.exe restent, à chaque fois,
et donc soit je dois les tuer manuellement, soit attendre le Crash Reporter et les faire terminer automatiquement.

Ce que j'ai fait, c'est restaurer mon profil Firefox d'hier (ayant GM 3.11)
et désactivé la mise à jour automatique pour GM.

Je comprends qu'il s'agit probablement d'un bogue de Firefox et non causé par GM,
néanmoins je tenais à vous en faire part.
J'ai également posté un lien vers ce problème vers le bogue bugzilla.

PS. Je ne pouvais pas le recréer dans un nouveau profil.
Mais, dans mon profil normal, même après avoir désactivé toutes les autres extensions installées
(AdBlock Plus, EHE pour ABP, NoScript, RES Suite, Elegant)
le problème persiste (les 2 processus firefox.exe ne sont pas fermés)

Source

darkred

Commentaire le plus utile

@arantius , vous vouliez peut-être fermer le #2579 en tant que doublon et le fermer par erreur à la place ?
Ce rapport contient beaucoup plus de détails.

darkred le 23 sept. 2017

👍2

Tous les 20 commentaires

Même problème ici. Juste pour ajouter, mon "correctif" était de faire une installation de 3.11 directement sur 3.12, pas besoin de restaurer un ancien profil

frankhalligan le 21 sept. 2017

J'ai le même problème. J'ai installé Greasemonkey 4 à partir du canal de développement et il n'a montré que quelques scripts installés. Peut-être que la version 3.12 a un problème avec la migration des scripts vers un nouveau stockage et cela provoque une rupture ? J'ai environ 20 scripts installés avec certains désactivés.

ghost le 21 sept. 2017

Davantage de personnes sont concernées : https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/reviews/

ghost le 22 sept. 2017

Voir aussi : https://bugzilla.mozilla.org/show_bug.cgi?id=1402201

fireattack le 22 sept. 2017

Confirmé!
Le redémarrage de FF ne fonctionne plus ; il tourne au ralenti avec un minimum de mémoire pour toujours.
Avec GM désactivé, FF redémarre proprement.

Edit : rétrogradation à 3.11 œuvres.

_Windows 10 64 bits_
_FF 55.0.3 64 bits_
_GM 3.12+_

Changements entre 3.11 et 3.12 : https://github.com/greasemonkey/greasemonkey/compare/ac955f21e6d30f8afae2a9013784c1a8b2aa8ae8...9d27f9ff11a080d174fec03727efdc13d030c5f9

jerone le 23 sept. 2017

Ce serait bien d'au moins annuler les modifications de 3.12, sinon les gens vont détruire cet excellent addon dans les critiques.

ghost le 23 sept. 2017

@arantius , vous vouliez peut-être fermer le #2579 en tant que doublon et le fermer par erreur à la place ?
Ce rapport contient beaucoup plus de détails.

darkred le 23 sept. 2017

👍2

Ouais!

arantius le 23 sept. 2017

Aucun ne semble le mentionner ici, mais il ne le fera qu'avec certains scripts.

Dans tous les 30+ scripts que j'ai, seul celui-ci provoque ce problème de blocage d'arrêt.

De plus, le script (problématique) ne doit même pas être activé ; même s'il est désactivé, cela pose toujours problème.

fireattack le 23 sept. 2017

+1 à fireattack, j'ai installé une douzaine de scripts et un seul est à l'origine du problème : Dealabs Compagon .
Il semble que ce soit une fonction spécifique (rare ?) qui soit à l'origine du problème.

mooms06 le 24 sept. 2017

Dans mon cas, le script du fauteur de troubles était https://greasyfork.org/en/scripts/6456-install-user-script
C'était aussi mon seul script avec // @run-at document-end ce qui est aussi le cas avec les deux scripts postés ci-dessus ? Coïncidence?

ghost le 24 sept. 2017

J'ai d'autres scripts qui ont // @run-at document-end mais ne posent pas de problème.

Cela pourrait encore être une condition nécessaire, mais pas suffisante.

fireattack le 24 sept. 2017

J'ai essayé avec tous mes scripts désactivés et le problème est le même pour moi sous FF 55.0.3 et le multiprocessus Windows 10 (64) est désactivé pour moi.

PHIL-IP le 24 sept. 2017

Vous devez supprimer les scripts problématiques, pas seulement les désactiver, pour les corriger

fireattack le 24 sept. 2017

Je n'ai pas ce problème avec mes scripts. Je peux donc confirmer, ce n'est qu'un problème avec certains scripts.

fdellwing le 24 sept. 2017

Je suis revenu à 3.11 en attendant un correctif. Espérons que nous n'aurons pas à attendre la nouvelle extension.

killerz298 le 24 sept. 2017

Les deux scripts liés ci-dessus utilisent une URL data: pour leur @icon . J'ai préparé une solution de contournement qui empêche le crash (je pense ..), mais je veux aussi que cela fonctionne vraiment, ce qui n'est probablement pas le cas aujourd'hui.

arantius le 25 sept. 2017

@arantius a commenté le 25 sept. 2017, 17:59 GMT+2 :