I've been seeing this for close to a week now but haven't been able to get a some reduced steps-to-reproduce. Basically, if I use Firefox for at least two or three hours, various icons in the browser chrome become invisible. This has affected the Windows minimize/restore/close buttons and the page info/SSL lock icons. Restarting the browser fixes this. I don't see this in other programs on my computer. I do have Windows set to use a screensaver after 5 minutes of inactivity. I tried changing that to 1 minute and then reproducing via mozregression but it didn't reproduce with just letting it sleep like that.

This is on Windows 10 insider build 14316. Graphics Adapter Description Intel(R) HD Graphics Family Adapter Drivers igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32 Adapter RAM Unknown Asynchronous Pan/Zoom wheel input enabled; touch input enabled Device ID 0x0a16 Direct2D Enabled true DirectWrite Enabled true (10.0.14316.1000) Driver Date 2-2-2016 Driver Version 20.19.15.4380 GPU #2 Active false GPU Accelerated Windows 1/1 Direct3D 11 (OMTC) Subsys ID 221817aa Supports Hardware H264 Decoding Yes; Using D3D11 API Vendor ID 0x8086 WebGL Renderer Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote true AzureCanvasAccelerated 0 AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo

I was able to run mozregression on this, but it took a long time because I have to use the browser for anywhere between 5 minutes and 2 hours to reproduce this. To use this in coordination with mozregression, I ran the latest Nightly build (2016-04-13) at the same time as mozregression. If the mozregression build reproduced the bug, then I marked the build as bad. If the latest Nightly build reproduced the bug but the mozregression didn't, I marked the build as good. Each time I marked a build good or bad, I restarted my Nightly build so they both shared equivalent running time. Regression window, https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8a4359ad909fe0cffcfea512770483ffdf8cd4e6&tochange=a66bf0a800f3d859b4bd2ceebc57b2e3fa6544d8 Likely cause: bug 1256517

Narrower regression range has removed bug 1256517. Regression window, https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9ebccbbb04a65870d49627fa8ca701c494974cef&tochange=2a8ca5caae8e3a300701b0a85e5051ead55e0648 Likely cause: bug 1242256

Note that the icons that stop displaying have associated transitions. The ones I've seen are the page info/SSL lock/tracking protection, tab curves, and window caption buttons (restore/minimize/close).

what information are you requesting from me?

Does this bug sound plausible given the changes you made in your bug?

For my change to have an effect you'd need an svg file with some non-displayed by default image <image> elements i.e within <defs> or <pattern> or <mask>.

Actually, that may match the symptoms here. The tab curves are drawn using SVG[1], the caption buttons are drawn using SVG[2], the info (i) icon is drawn using SVG[3], the various locks are drawn using SVG[4], and the tracking protection icon is also rendered using SVG[5]. [1] http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tab-shape.inc.svg [2] http://mxr.mozilla.org/mozilla-central/source/browser/themes/windows/caption-buttons.svg [3] http://mxr.mozilla.org/mozilla-central/source/browser/themes/shared/info.svg [4] http://mxr.mozilla.org/mozilla-central/source/browser/themes/shared/identity-block/ [5] http://mxr.mozilla.org/mozilla-central/source/browser/themes/shared/identity-block/tracking-protection-16.svg They all define the image within <defs>.

None of those things seem to involve an SVG 'image' element, and if that element is not involved then bug 1242256 can't be the cause I'm afraid.

The code in the patch would have no effect on the data in comment 9. As Jonathan said, they have no <image> elements.

Re-ran mozregression and so far have it narrowed down to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=720933fc00b99d6ec11d8be54b710cdf493f18eb&tochange=dec6f360210220d77472538bb0863dfbdc37ef37 David / bholley, could this bug be fall-out from bug 1258017?

Tracking, seems likely to be a recent regression.

It sounds unlikely. What was your methodology for declaring a build to be good? It seems like there might be useful things to debug while the bug is happening. Have you ever seen the icons come back after they disappear? Do they show up in a new window after they disappear in the existing window? What if you change Does it go away if you change the layout.css.devPixelsPerPx pref between small integers?

(In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain patch) from comment #14) > What was your methodology for declaring a build to be good? My methodology has been to start a Nightly build at the same time a mozregression build starts. If the mozregression build exhibits the problem, I mark it as "bad". If the Nightly build exhibits the problem but the mozregression build hasn't, I may wait an additional 20-30 minutes. If the mozregression build still isn't exhibiting the bug, then I mark that build as "good". > It seems like there might be useful things to debug while the bug is > happening. Have you ever seen the icons come back after they disappear? No they don't come back. > Do > they show up in a new window after they disappear in the existing window? Yes, they are in a new window. > Does it go away if you change the > layout.css.devPixelsPerPx pref between small integers? The pref was set to -1.0. At 1.0 the icons come back. At 1.5 the icons come back. At 1.7 the icons come back. At 1.9 the icons come back. At 2.0 the icons disappear. At 2.1 some of the icons come back.

Clearing NI pending further investigation.

How do we move this along?

Seth, where do you think the above symptoms mean the problem is? And do you see anything related close to the above regression ranges (which may not be completely correct)?

Okay, I've taken another stab at the regression hunt. This time I have come up with two potential bugs that could have regressed this, and they both landed one day apart from each other. Bug 1146663 and bug 1201796 https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2015-09-20&enddate=2015-09-22

I pushed three jobs to tryserver, 1) https://treeherder.mozilla.org/#/jobs?repo=try&revision=41c5b60ef37e which is with both bug 1146663 and bug 1201796 2) https://treeherder.mozilla.org/#/jobs?repo=try&revision=ea5b6cf3eb41 which is with only bug 1201796 3) https://treeherder.mozilla.org/#/jobs?repo=try&revision=dc508a87601c which is with neither bug I'll run these builds when they complete to help narrow down the regression range.

I haven't seen this recently on Firefox Nightly 2016-07-04. It may have been fixed by a Windows update / graphics driver update / or a change in Firefox. I'll reopen if I see it again.