User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

I have a simple button in a web app that clears rendered chart.js chart from canvas element. However, recently this no-longer occurs in firefox. The chart stays visible. However, If I try to take a screenshot, to support this bug the chart disappears the moment I select the 'Take a screenshot' icon. Same occurs if I Alt+tab toggle from the browser and back again.
Also, when I select F12 to display the console, there are no errors the chart also disappears and whilst the console window displayed. the webapp performs as expected.
Same anomaly occurs with FF dev edition.
Have tested on both Chrome and Opera and my webapp performs as expected.

The Bugbug bot thinks this bug should belong to the 'Core::Canvas: 2D' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Can you provide a link to a webpage where you see this problem and simple steps to reproduce?

This is the problem when the 'DETAIL button is selected

This is the image of what should happen and indeed does happen, when F12 is selected or if screen loses focus and focus is returned and in original narrative

Can't give you access to website but did manage, through time delay screen capture, to grab the problem image? See attched

Can you make a simplified version of the page that shows the problem that you could make public?

(In reply to Timothy Nikkel (:tnikkel) from comment #6)

Can you make a simplified version of the page that shows the problem that you could make public?

Sorry but I don't think that will be possible. The page, as you see from the previous attachments, has two charts
The 'DETAILS' button has a simple .on("click", function() which does two things 1. destroys the charts if they exist. 2. makes an ajax call to get fresh data to be displayed in a separate set of divs.
step 1 is as follows

if (typeof trndChart != 'undefined'){
trndChart.destroy();
}
if (typeof curmChart != 'undefined'){
curmChart.destroy();
}
In normal screen mode (console panel not visible) the function fires but the charts remain visible. The moment the page loses focus or F12 is hit the charts disappear.
If I conduct the same process but with the console panel visible, everything functions as expected.
Try both approaches in Opera and Chrome and everything works as expected.
I'm using Charts.js Version: 2.7.3

Okay, you said that it used to work? Can you run https://mozilla.github.io/mozregression/ to track down what change broke this?

Using mozregression (nice tool) I have narrowed it down to this build on the 2021 Apr 22. Prior to this worked fine.
INFO: application_buildid: 20210422213157
INFO : application_changeset: 33143ef17c70c76f39ac75fe51d3ae9342365845
INFO : application_display_name: Firefox Nightly
INFO : application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
INFO : application_version: 90.0a1
INFO : platform_changeset: 33143ef17c70c76f39ac75fe51d3ae9342365845

Thanks! Can you include more of the output of mozregression? That should tell us the exact change that caused the problem.

That's pretty much all the output actually. Can you provide me with the INFO: "name you are looking for" and I'll try again.

I am hoping to see something like this

3:12.17 INFO: Narrowed integration regression window from [cdd65df8, fc1cc85f] (3 builds) to [bd25a12d, fc1cc85f] (2 builds) (~1 steps left)
3:12.17 INFO: No more integration revisions, bisection finished.
3:12.17 INFO: Last good revision: bd25a12ddee1177982672055545c3ba83e694201
3:12.17 INFO: First bad revision: fc1cc85f4f27a6527065bde732b0d6688bdece3e
3:12.17 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=bd25a12ddee1177982672055545c3ba83e694201&tochange=fc1cc85f4f27a6527065bde732b0d6688bdece3e

Nope, have tried several approaches and not getting any of that. Perhaps I'm missing something in the process or using wrong selections/configuration?
Are there certain selections I need to make? Please advise.

This is all I'm getting:
2021-08-04T12:44:08.178000: INFO : application_buildid: 20210422213157
2021-08-04T12:44:08.178000: INFO : application_changeset: 33143ef17c70c76f39ac75fe51d3ae9342365845
2021-08-04T12:44:08.178000: INFO : application_display_name: Firefox Nightly
2021-08-04T12:44:08.178000: INFO : application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
2021-08-04T12:44:08.178000: INFO : application_name: Firefox
2021-08-04T12:44:08.178000: INFO : application_remotingname: firefox
2021-08-04T12:44:08.178000: INFO : application_repository: https://hg.mozilla.org/mozilla-central
2021-08-04T12:44:08.178000: INFO : application_vendor: Mozilla
2021-08-04T12:44:08.178000: INFO : application_version: 90.0a1
2021-08-04T12:44:08.178000: INFO : platform_buildid: 20210422213157
2021-08-04T12:44:08.178000: INFO : platform_changeset: 33143ef17c70c76f39ac75fe51d3ae9342365845
2021-08-04T12:44:08.178000: INFO : platform_repository: https://hg.mozilla.org/mozilla-central
2021-08-04T12:44:08.178000: INFO : platform_version: 90.0a1

Are you running the mozregression gui? Are you choosing "Run a single build" or "start a new bisection"?

Yes - running the mozregression gui.
And, armed with this additional information I have now gone through several steps in bisection with heaps of information.

2021-08-06T14:52:17.425000: INFO : Narrowed integration regression window from [c409ea0b, 2a384027] (3 builds) to [42c3b61f, 2a384027] (2 builds) (~1 steps left)
2021-08-06T14:52:17.433000: DEBUG : Starting merge handling...
2021-08-06T14:52:17.433000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=2a384027ee9bcee63121a68d42c8db6644c8d8aa&full=1
2021-08-06T14:52:17.433000: DEBUG : redo: attempt 1/3
2021-08-06T14:52:17.433000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=2a384027ee9bcee63121a68d42c8db6644c8d8aa&full=1',), kwargs: {}, attempt #1
2021-08-06T14:52:17.435000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2021-08-06T14:52:18.645000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=2a384027ee9bcee63121a68d42c8db6644c8d8aa&full=1 HTTP/1.1" 200 None
2021-08-06T14:52:18.705000: DEBUG : Found commit message:
Bug 1706488 - Enable non-opaque compositor surface support r=gfx-reviewers,lsalzman

This removes the code in Gecko that was only allowing opaque
compositor surfaces, now that the underlying work in WR and
SWGL to support these is complete.

Differential Revision: https://phabricator.services.mozilla.com/D112831

2021-08-06T14:52:18.705000: DEBUG : Did not find a branch, checking all integration branches
2021-08-06T14:52:18.705000: INFO : The bisection is done.
2021-08-06T14:52:18.715000: INFO : Stopped

Thanks, that was very helpful.

I tried tweaking some of the examples on https://www.chartjs.org/docs/latest/samples to try and reproduce with similar JS to what you have in comment #7 but I couldn't reproduce the problem on Linux or Windows.

It's probably going to be a very subtle condition causing this that will be difficult / impossible to fix without being able to reproduce locally, unfortunately.

Is it privacy reasons (looks like some kind of health application) that mean we're unable to access it, or because it's on some kind of internal network, or something else? Is there any way we could get temporary access to it, or access to a dev version with dummy data or anything like that?

We might be able to try debug it remotely by providing you builds with extra logging and you report the output to us, though that will be a long process. We might also be able to get some insight by getting you to do a webrender capture and sending that to us (though again, that may not be possible due to privacy issues, as it basically dumps the entire display list and image set for the page so that we can replay it?).

As mentioned this is nothing really special going on. I can email html snippets and JS snippets with you. Let me know and I'll send to gwatson@mozilla.com
Can't share app because of data for both the reasons you suggest but may be able to do the other processes you suggest in closing para webrender capture etc.

Sure, if you're able to email me some snippets I'll see if I can reproduce with those. Would you also be able to send the output of about:support - that will identify what GPU you're using, along with which compositing backend is enabled on your configuration.

This is a basic chart + destroy button based on the reporter's description of what the web app is doing. It doesn't reproduce locally for me, but we will try to iterate on this and see if we can find out what triggers the bug to occur on this.

Not sure if it makes any difference Glenn but currently using charts.js 2.7 not 3.5

Another thought I had on how we might be able to create a local repro, is a technique I use regularly to reduce test cases.

If you open up your web app, open the devtools inspector, and use that to remove as many elements from the page as possible while it still reproduces, then you can try use File -> Save Page. This will save the minimized HTML and any JS/images etc to a local file/dir which you could zip and send to me (after doing a privacy pass first to remove any personal data from the saved files). Would that be possible?

Actually Glenn, I think can go one better than that. I have actually stumbled upon the problem.
The element that appears onClick of the DETAILS button is a container with the height set to auto. Previously the background colour was not set. By setting the background colour of the container element the issue resolves. If set to transparent, the problem persists.
Not problem for me to keep the background colour but it would be nice to resolve the actual problem. as this does not occur in Chrome or Opera.

Ah, great that you have found a work around! It would definitely be good to find the underlying issue though. Is there any chance you would be able to tweak the test case I attached above with that extra information in a way that manages to reproduce it? If we can get a local repro test case, it should hopefully be straightforward to fix.

As a quick follow up to this - we do some optimizations based on whether translucent web content intersects with what we call compositor surfaces (things like canvas, webgl, video, that we can hand off to the OS compositor for power / performance savings). I suspect that triggering it may rely on some element(s) overlapping with the canvas bounding rect - which sounds plausible given your description above of the height setting?

Also - it's probably good to have an opaque background color set on it, by the way - that will be a performance win, since we don't need to composite a translucent element over top of the compositor surface (canvas).

Suspect you are right re overlap. Have sent you a mail with tweaked webpage rather than polluting the thread. May need further tweaks though.