canvas-gauges icon indicating copy to clipboard operation
canvas-gauges copied to clipboard

Firefox - Most gauges layout breaking after a few seconds

Open rouggio opened this issue 3 years ago • 16 comments

hi Mikhus, even on the live demo page, I can get broken gauges after a few seconds: https://canvas-gauges.com/documentation/examples/

just hover with the mouse on any gauges in the "Zero Configuration Gauges" or "Other Custom Radial Gauges" or "Other Custom Linear Gauges" sections, stay there for about 10 - 20 seconds and after a while the layout will get corrupted

canvas-gauges version: 2.1.7 Tested on Firefox 95.0.1 (64 bit) on Ubuntu 20.04.3 LTS

bug

cannot reproduce on google chrome, no other browser available here for me

rouggio avatar Dec 23 '21 01:12 rouggio

Hi, I have has a similar issue for more than a year with Firefox and this gauge type. I have always assumed it was the way I was using the gauge. Windows 10, Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz, NVIDIA 1060, Firefox 95.0.2 (64-bit) Similar experience with Chrome, no issue visible.

Issue takes 50 updates to display the missalignment, i.e. >100 seconds with the test code below: image

image

Test code html, perhaps someone has a tip on what's causing the issue? test.txt

P.S. Thanks to the author, great gauges and to you for taking time to read and perhaps assist.

OneOfTheInfiniteMonkeys avatar Jan 02 '22 18:01 OneOfTheInfiniteMonkeys

Same here on Raspberry PI4 4GB and Win11 both running Firefox.

W0lpertinger avatar Jan 03 '22 18:01 W0lpertinger

Confirming the problem with Firefox 96.0.3 (64-bit) on Windows 10. Animations (as they usually are because they are one of the coolest thing in these) must be on for this problem to occur. As said above, most of the animated demo gauges on the official example pages fail in a few seconds.

My workaround is to use the update method to set valueText everytime after updating the value [to a string containing the numeric value just set; so visually value box will look the same]. It looks like this workaround works for some reason, no problems so far. However, with that approach animatedValue will not be available (valueText will override it).

panuworld avatar Feb 04 '22 19:02 panuworld

Same problem here....

Tirguy avatar Feb 18 '22 08:02 Tirguy

My workaround is to use the update method to set valueText everytime after updating the value

Hi panuworld,

I'm having the same problem with Firefox but I can't seem to get your workaround to work. I'm just doing this each time I have a new value:

        gaugeSpeed.value = parameter[1];   //parameter[1] contains the new value as a number string
        gaugeSpeed.valueText = parameter[1];

I guess I am missing something in your workaround description! Can you see what I am doing wrong? It would be nice to get this fixed if possible!

JohnLinford avatar Mar 05 '22 10:03 JohnLinford

I'm having the same problem with Firefox but I can't seem to get your workaround to work. I'm just doing this each time I have a new value:

        gaugeSpeed.value = parameter[1];   //parameter[1] contains the new value as a number string
        gaugeSpeed.valueText = parameter[1];

My code uses the update method to update the valueText and it (looks like it) helps with this problem. Wondering if the valueText can be set directly as a property at all... My code:

	gauge.value = speed
	speed = speed.toFixed()
	gauge.update({ valueText: speed, animationDuration: intv })

My PWA using this workaround is here: https://panuworld.net/liikenne/nopeus/speedo.htm (however, it is not really useful on desktop Firefox without GPS) Another page where I use the same workaround is here (its is in Finnish only but it should show something also on desktop Firefox): https://panuworld.net/liikenne/junat/

Edit: Disclaimer: this seems to work around the acute problem for now. However, I have no idea what is the root cause. So the reliability of this workaround cannot be guaranteed.

panuworld avatar Mar 06 '22 13:03 panuworld

Hi, tried the proposed fix against the example I posted previously. It seems to work a treat!!! :-)

I have commented in the differences as this file works standalone as an example. test-1.txt

Thanks for the hint.

OneOfTheInfiniteMonkeys avatar Mar 07 '22 21:03 OneOfTheInfiniteMonkeys

Many thanks panuworld and OneOfTheInfiniteMonkeys. I didn't know about the gauge.update facility but now I've implemented it in my code it works perfectly. I don't do much of this sort of coding, being more of an application programmer, so your examples were really helpful!

JohnLinford avatar Mar 07 '22 21:03 JohnLinford

be very careful with using this workaround as updating too often with this approach will kill the browser.

fencer avatar Apr 03 '22 21:04 fencer

That's an interesting comment, fencer. I've not "killed" any of my browsers with updates every second or so but perhaps you're thinking about much higher update rates? What resource is the browser running out of to cause it to crash?

JohnLinford avatar Apr 04 '22 12:04 JohnLinford

您的邮件我已收到,谢谢!

TuShen121 avatar Apr 04 '22 12:04 TuShen121

That's an interesting comment, fencer. I've not "killed" any of my browsers with updates every second or so but perhaps you're thinking about much higher update rates? What resource is the browser running out of to cause it to crash?

I have about 4 gauges 2 of which update 2-4 times a second. One of them was using the update method, Firefox would eat up 3GB+ RAM in very few seconds till eventually get unresponsive.

fencer avatar Apr 04 '22 14:04 fencer

I have about 4 gauges 2 of which update 2-4 times a second. One of them was using the update method, Firefox would eat up 3GB+ RAM in very few seconds till eventually get unresponsive.

Interesting, thank you. I found that my Firefox which had been running for 8 hours or so was using 1.7GB with 15+ open tabs, two of which are displaying gauges that use the update function. I closed Firefox, reopened it and refreshed the tabs one-by-one. That got me to about 1.2GB but there was no big uptick in memory use when I refreshed my gauge pages. I've watched for 30 minutes or so with very little change in memory use. Of course, if I start refreshing tabs displaying dynamic pages then memory use goes up as more stuff gets cached but I can't see that the gauges are gobbling up RAM, nor am I experiencing any unresponsiveness.

JohnLinford avatar Apr 04 '22 15:04 JohnLinford

I have tried to make an example to reproduce the issue but I had no success, so I went ahead and restored the guage.update in my code and still did not happen. I suspect it could be a combination of other things. Will post an update in case I figure it out.

fencer avatar Apr 04 '22 21:04 fencer

Same here, when viewed by Firefox on Win10. On Firefox v101.0, using gauge.min.js served from cdn.rawgit.com, I did see a deprecated warning message on FF debug console from on some gauge draw method. After updating to FF the current latest version (v102.0.1), no warning messages occurred but stated problem persists. To me, this looks like a problem with the coordinate system, where the top-left origin changes to the center of the drawing. The .js code is too obfuscated to be readable, unfortunately.

rob040 avatar Jul 07 '22 15:07 rob040

您的邮件我已收到,谢谢!

TuShen121 avatar Jul 07 '22 15:07 TuShen121