Tooltip's ctx.fillStyle is set to an unexpected value in IE/Edge

[juliusl]

This is a weird one that I don't expect a lot of people to run into but wanted to bring it up to the community. It seems to only repro in Edge and IE (haven't checked Safari).

In this bit of code:

            // Draw Background

            if (this._options.tooltips.enabled) {
                ctx.fillStyle = helpers.color(vm.backgroundColor).alpha(vm.opacity).rgbString();
                helpers.drawRoundedRectangle(ctx, tooltipX, tooltipY, tooltipWidth, tooltipHeight, vm.cornerRadius);
                ctx.fill();
            }

While the tooltip is fading out, even though this line has set ctx.fillStyle to the appropriate fade out color:

                ctx.fillStyle = helpers.color(vm.backgroundColor).alpha(vm.opacity).rgbString();

ctx.fillStyle sometimes is set to something completely off.

For example, in my case vm.backgroundColor was supposed to be rgba(0,0,0,0) but ended up being #e74c3c instead. (Wot?) Even when I drop a breakpoint when the value is off and execute the line before (using VS immediate window) I get the right value, it's just what's set in ctx.fillStyle is still completely off.

It ends up with a nasty flicker effect. The really weird part is that it happens inconsistently. You have to mouse out really quickly for it to show up. My fix is:

                if (ctx.fillStyle.charAt(0) == '#' && ctx.fillStyle != '#000000')
                    return;

For some more context, #e74c3c is the value of the background color I use for some of the points. I am dynamically changing the background of the point based on the value of the point itself which I do through the helpers.extend( method. #e74c3c is the last value I've used for the points. The consistent part of this bug is that the flicker color seems to be the last value I use to dynamically color the points.

[etimberg]

Hmmmm, that's a neat one. I wonder if this happens if you try to do ctx.fillStyle = undefined
My reason for this line of thinking is that we use a modified version of https://github.com/MoOx/color for colour parsing. Maybe it can't handle applying an opacity to rgba(0, 0, 0, 0)

For reference, our forked version is: https://github.com/chartjs/color

[juliusl]

Hmm interesting, at the time it seems that the canvas is trying to do this:

ctx.fillStyle = helpers.color(vm.backgroundColor).alpha(vm.opacity).rgbString();

while applying the easeOut function.

The values for vm.backgroundColor and vm.opacity are:

vm.backgroundColor == "rgba(0,0,0,0.8)"
vm.opacity == "3.5572888829805184e-9" 

It's weird though because I feel like I'm treating the symptoms of another issue. In any case I'll take a look at that color.js file later this afternoon to see if there are any leads.

Here is a dump of the full vm object:

+       __proto__   {...}   Object
        _bodyAlign  "left"  String
        _bodyFontFamily "'Helvetica Neue', 'Helvetica', 'Arial', sans-serif"    String
        _bodyFontStyle  "normal"    String
        _footerAlign    "left"  String
        _footerFontFamily   "'Helvetica Neue', 'Helvetica', 'Arial', sans-serif"    String
        _footerFontStyle    "bold"  String
        _titleAlign "left"  String
        _titleFontFamily    "'Helvetica Neue', 'Helvetica', 'Arial', sans-serif"    String
        _titleFontStyle "bold"  String
+       afterBody   []  Object, (Array)
        backgroundColor "rgba(0,0,0,0.8)"   String
+       beforeBody  []  Object, (Array)
+       body    [640 requests took about 61.748ms]  Object, (Array)
        bodyColor   "#fff"  String
        bodyFontSize    12  Number
        bodySpacing 2   Number
        caretPadding    null    Null
        caretSize   5   Number
        cornerRadius    6   Number
+       footer  [Click on the dot to see the detailed samples we've collected.] Object, (Array)
        footerColor "#fff"  String
        footerFontSize  12  Number
        footerMarginTop 6   Number
        footerSpacing   2   Number
+       labelColors []  Object, (Array)
        legendColorBackground   "#fff"  String
        opacity 3.5572888829805184e-9   Number
        position    "top"   String
+       title   [5th percentile]    Object, (Array)
        titleColor  "#fff"  String
        titleFontSize   12  Number
        titleMarginBottom   6   Number
        titleSpacing    2   Number
        x   215 Number
        xAlign  "right" String
        xOffset 10  Number
        xPadding    6   Number
        y   78  Number
        yAlign  "center"    String
        yPadding    6   Number

[etimberg]

Thanks for the extra info, I'll have a look. By chance, which easing function are you using?

I logged some data on the actual value being set into ctx.fillStyle and what I found was

vm.opacity == 7.365404947729491e-10
ctx.fillStyle == 'rgba(0, 0, 0, 7.365404947729491e-10)'

I'm guessing this an implementation issue inside the IE/Edge core. I think if we round the opacity to 0 once it is below a certain value it would work . The reason for the colour of the background jumping to the colour of the fill is that this is the last style set into the canvas.

I went to the canvas 2D context spec (http://www.w3.org/TR/2dcontext/#fill-and-stroke-styles) but there aren't any limits specified for the alpha other than ]

if the alpha value is greater than zero then one or more digits in the range 0-9 (U+0030 to U+0039) representing the fractional part of the alpha, and finally a U+0029 RIGHT PARENTHESIS. User agents must express the fractional part of the alpha value, if any, with the level of precision necessary for the alpha value, when reparsed, to be interpreted as the same alpha value

[juliusl]

I'm using the defaults at the moment. In my repo it's set at easeOutQuart.

Thanks for taking the time to gather more info.

[etimberg]

No prob, I'll try and create a PR for this tomorrow

[etimberg]

@juliusl I created #1696 to address this issue. Tested against Microsoft Edge 20.10240.16384.0

[juliusl]

Sorry I've been on holiday. I'll give this a spin today. Thanks for looking into this.

[juliusl]

It looks like that fixed it! Yay!

It looks like some changes I picked up broke resizing so I'll need to investigate that. Closing for now. Cheers.

[etimberg]

Great that it's fixed. Hopefully nothing is too borked with the resizing. I don't recall playing with it recently.