I can't reproduce this realiably so I can't find the regression range. But it has been happening for some time that when I hover an inactive tab, the favicon disappears and reappears. Once it has happened, it does not happen again for that tab (at least for some time).

What OS is this on? Can you reproduce in safe mode? Any other information to go on at all? (I assume this is nightly, but that is also not stated in the report, so it'd be useful if you could confirm that, too!) Marco, do you have any ideas about this off-hand?

I use Windows 10 x64 version 1703 (15063.540) and Firefox Nightly x64. The problem is that I can't reproduce this deliberately, so I don't know if it happens with safe mode or clean profiles. It seems to happen with tabs that I haven't hovered for a certain time. Possibly they need to be not loaded after closing and restarting the browser, not sure. Having a huge amount of tabs (~750) might also be related.

(In reply to :Gijs from comment #1) > Marco, do you have any ideas about this off-hand? If you're thinking about "recent" changes to the favicons service, those are unlikely related, the tabs don't use the favicons service, they do their own parallel fetching and displaying from the network. There have been discussions about unifying those paths but it didn't happen. It's all in tabbrowser.xml::SetIcon(). I wonder if it may be related to lazy tabs, the flickering sounds like we setting the image attribute and thus causing an image reload. Even if we should not be doing that if the image url didn't change... Though, I have no idea what may cause us to do any kind of operation on a background browser when the user just hovers the tab.

Effectively, when the favicon flickers, the network devtool of the browser toolbox shows a request. Is there a way to see what code initiated it?

(In reply to Oriol Brufau [:Oriol] from comment #4) > Effectively, when the favicon flickers, the network devtool of the browser > toolbox shows a request. Is there a way to see what code initiated it? Yes, if you select the request in the network monitor there's a "stack trace" option. Can you try this? Off-hand, if I had to guess without the stack trace, maybe bug 874533. But a stack trace would be really helpful - there's other speculative connect things that could potentially be related here, I expect.

Ah, I remembered there was some way. But the "stack trace" subpanel does not seem to appear in the browser toolbox, I only have it in web devtools.

I get no stack trace when the favicon flickers because I hovered that tab. Hovever, more rarely, hovering a tab can also make favicons of other tabs flicker. It seems I get a stack trace in that case. That's it: > ensureElementIsVisible chrome://global/content/bindings/scrollbox.xml:208:11 > _handleTabSelect chrome://browser/content/tabbrowser.xml:6284:13 > onxblTabSelect chrome://browser/content/tabbrowser.xml:6753:1 > updateCurrentBrowser chrome://browser/content/tabbrowser.xml:1253:15 > onselect chrome://browser/content/browser.xul:1:44 > set_selectedIndex chrome://global/content/bindings/tabbox.xml:672:13 > set_selectedPanel chrome://global/content/bindings/tabbox.xml:691:13 > set_selectedIndex chrome://global/content/bindings/tabbox.xml:409:15 > set_selectedltem chrome://global/content/bindings/tabbox.xml:441:34 > selectNewTab chrome://global/content/bindings/tabbox.xml:486:11 > onxblmousedown chrome://global/content/bindings/tabbox.xml:808:11

(In reply to Oriol Brufau [:Oriol] from comment #7) > I get no stack trace when the favicon flickers because I hovered that tab. > Hovever, more rarely, hovering a tab can also make favicons of other tabs > flicker. It seems I get a stack trace in that case. That's it: > > > ensureElementIsVisible chrome://global/content/bindings/scrollbox.xml:208:11 > > _handleTabSelect chrome://browser/content/tabbrowser.xml:6284:13 > > onxblTabSelect chrome://browser/content/tabbrowser.xml:6753:1 > > updateCurrentBrowser chrome://browser/content/tabbrowser.xml:1253:15 > > onselect chrome://browser/content/browser.xul:1:44 > > set_selectedIndex chrome://global/content/bindings/tabbox.xml:672:13 > > set_selectedPanel chrome://global/content/bindings/tabbox.xml:691:13 > > set_selectedIndex chrome://global/content/bindings/tabbox.xml:409:15 > > set_selectedltem chrome://global/content/bindings/tabbox.xml:441:34 > > selectNewTab chrome://global/content/bindings/tabbox.xml:486:11 > > onxblmousedown chrome://global/content/bindings/tabbox.xml:808:11 This makes no sense. It suggests it's triggered by scrolling / a given element becoming visible. I'm assuming this is a favicon request, and as such would be triggered by imglib rendering for the XUL image that has the favicon. :aosmond, I'm told you know about imglib, so maybe you know why that might happen and/or if we've done something to how these loads happen in the last "some time"? (Oriol, do you have some idea of timeframe, even if it's weeks/months/years ?)

This sounds like bug 1119455.

Not much sure, but I think I started noticing it between 2 weeks and a month ago. I thought it would be fixed in few days so I didn't report it immediately. Definitely not 3 years like in bug 1119455. And that bug mentions large image favicons, this is happening to me with normal favicons like MDN, bugzilla, jsfiddle, etc.

Getting it on pretty much every tabs either on my OS X nightly. I don't remember seeing it on a W7 computer, but I'll pay more attention. I need to add that in addition to tabs in tab bar, redraw also happen in the full tab list that appear when you're over some number of tabs (Don't now the exact name, tab overflow list?)

[Tracking Requested - why for this release]: This is still a pretty bad regression which is now a little more than one month old and I guess it's not nice for the end user to have this landing in stable. :Gijs, can I offer to try to help gathering informations to dig into this issue? I can be available on IRC to do so more directly if that helps or, better, I'll still be in Paris offices tomorrow (friday) and two days next week, so if there's someone working on those parts there he can even have a direct look at it if that may help.

I think you're more likely to be seeing bug 1401122. (In reply to Clément Lefèvre from comment #13) > [Tracking Requested - why for this release]: > This is still a pretty bad regression which is now a little more than one > month old and I guess it's not nice for the end user to have this landing in > stable. There's no data on how old this really is or what caused this, and no steps to reproduce. Just steps to reproduce would be good, but I still think you're probably seeing something else.

(In reply to :Gijs from comment #14) > I think you're more likely to be seeing bug 1401122. > > (In reply to Clément Lefèvre from comment #13) > > [Tracking Requested - why for this release]: > > This is still a pretty bad regression which is now a little more than one > > month old and I guess it's not nice for the end user to have this landing in > > stable. > > There's no data on how old this really is or what caused this, and no steps > to reproduce. Just steps to reproduce would be good, but I still think > you're probably seeing something else. Well, you can't really provide STR considering I think it have something to deal with the profile. Anyway, as it's related to opened tabs and their possible idle time, you can't just fire a profile, open two tabs and see it (at least for my part). I get it on a very regular basis for both the tab bar and the tab list, and what was described in earlier comments fit pretty well: hovering those after having these tabs or the list idle for some time make it redraw completely/blink. Rather than STR, I was more looking into ways of providing you with useful informations like logs, debug informations and so on. If that's possible, of course.

(In reply to Clément Lefèvre from comment #15) > (In reply to :Gijs from comment #14) > > I think you're more likely to be seeing bug 1401122. > > > > (In reply to Clément Lefèvre from comment #13) > > > [Tracking Requested - why for this release]: > > > This is still a pretty bad regression which is now a little more than one > > > month old and I guess it's not nice for the end user to have this landing in > > > stable. > > > > There's no data on how old this really is or what caused this, and no steps > > to reproduce. Just steps to reproduce would be good, but I still think > > you're probably seeing something else. > > Well, you can't really provide STR considering I think it have something to > deal with the profile. > Anyway, as it's related to opened tabs and their possible idle time, you > can't just fire a profile, open two tabs and see it (at least for my part). > I get it on a very regular basis for both the tab bar and the tab list, and > what was described in earlier comments fit pretty well: hovering those after > having these tabs or the list idle for some time make it redraw > completely/blink. > Rather than STR, I was more looking into ways of providing you with useful > informations like logs, debug informations and so on. > If that's possible, of course. To be more precise, I think that if it was not directly related to the profile or a specific usage, you would have a whole lot more affected users and many dupes. Another two things to add: - While I'm unsure, it might be related, since only one to three days I can see that some of these icons are not fully redrawn like it was since the beginning of that bug. When hovering the favicon, this one disappear but never comes back. - And if I remember correctly, when the favicon of a website is redrawn, if there are more tabs of the same website then every copy of this favicon gets redrawn in the exact same time.

(In reply to Clément Lefèvre from comment #15) > Anyway, as it's related to opened tabs and their possible idle time, you > can't just fire a profile, open two tabs and see it (at least for my part). > I get it on a very regular basis for both the tab bar and the tab list, and > what was described in earlier comments fit pretty well: hovering those after > having these tabs or the list idle for some time make it redraw > completely/blink. > Rather than STR, I was more looking into ways of providing you with useful > informations like logs, debug informations and so on. > If that's possible, of course. I have no idea what those things would be. TBH, re-reading bug 1119455 comment 4, it's not clear to me that this bug is different. Can you find a regression window with (a clone of) your regular profile? What is "a very regular basis" - every minute? Only after an hour? Once a week? Any idea what triggers it? Is it always the same sites' favicons, or does it happen to all of them (maybe it only happens to hi-res ones, like in bug 1119455) ? Presumably it doesn't happen every time you hover tabs? Fundamentally, it seems this is almost certainly a platform issue, like bug 1119455. Whether or not it has the same cause, without ever having seen it or having any steps that trigger it, I have no idea, nor do I know how to make progress on this bug. It would require someone from platform telling us how to get more information. :tn, do you have any ideas on how to distinguish this from 1119455, or figure out why this is happening more often / to more people now?

(In reply to Clément Lefèvre from comment #16) > - While I'm unsure, it might be related, since only one to three days I can > see that some of these icons are not fully redrawn like it was since the > beginning of that bug. When hovering the favicon, this one disappear but > never comes back. This sounds like a separate bug that I've talked to Marco about and that's supposed to be fixed now. Marco? I'm assuming this is on nightly, not beta?

(In reply to :Gijs from comment #17) > (In reply to Clément Lefèvre from comment #15) > > Anyway, as it's related to opened tabs and their possible idle time, you > > can't just fire a profile, open two tabs and see it (at least for my part). > > I get it on a very regular basis for both the tab bar and the tab list, and > > what was described in earlier comments fit pretty well: hovering those after > > having these tabs or the list idle for some time make it redraw > > completely/blink. > > Rather than STR, I was more looking into ways of providing you with useful > > informations like logs, debug informations and so on. > > If that's possible, of course. > > I have no idea what those things would be. TBH, re-reading bug 1119455 > comment 4, it's not clear to me that this bug is different. Can you find a > regression window with (a clone of) your regular profile? What is "a very > regular basis" - every minute? Only after an hour? Once a week? Any idea > what triggers it? Is it always the same sites' favicons, or does it happen > to all of them (maybe it only happens to hi-res ones, like in bug 1119455) ? > Presumably it doesn't happen every time you hover tabs? > > Fundamentally, it seems this is almost certainly a platform issue, like bug > 1119455. Whether or not it has the same cause, without ever having seen it > or having any steps that trigger it, I have no idea, nor do I know how to > make progress on this bug. It would require someone from platform telling us > how to get more information. :tn, do you have any ideas on how to > distinguish this from 1119455, or figure out why this is happening more > often / to more people now? Well, bug 1119455 is three years old and I started experiencing those issues maybe like one month ago, one month and a half? Plus it's not only large favicon I guess. Regular basis is hard to define but I'd say every time I use my browser. However the issue also lie into the probably link to last time tabs were hovered, which means that, if I remember correctly, when issue happen you can't just reproduce it immediately, especially on the tabs that just got it. But it seems to have a random component either. (In reply to :Gijs from comment #18) > (In reply to Clément Lefèvre from comment #16) > > - While I'm unsure, it might be related, since only one to three days I can > > see that some of these icons are not fully redrawn like it was since the > > beginning of that bug. When hovering the favicon, this one disappear but > > never comes back. > > This sounds like a separate bug that I've talked to Marco about and that's > supposed to be fixed now. Marco? > > I'm assuming this is on nightly, not beta? Yup, only using Nightly, never Beta. No idea if Beta is affected or not. And this specific problem just happened around the time I wrote those comments, with an up-to-date Nightly.

Oh and another point: on the two computers I use on a regular basis which are my macOS 10.9 laptop and W7 computer, I can't remember experiencing it on the W7 one. But other people experienced it on W7 and W10 in earlier comments, which would again point to something in the profile.

(In reply to :Gijs from comment #17) > Fundamentally, it seems this is almost certainly a platform issue, like bug > 1119455. Whether or not it has the same cause, without ever having seen it > or having any steps that trigger it, I have no idea, nor do I know how to > make progress on this bug. It would require someone from platform telling us > how to get more information. :tn, do you have any ideas on how to > distinguish this from 1119455, or figure out why this is happening more > often / to more people now? Any change in the style of the browser chrome that affects the tab bar and hence the favicons could mean this comes up more (or less) frequently. I guess if we wanted to confirm that this is the same as bug 1119455 we could make a try build for users to use that dumps when we destroy the frame for a xul <image> and dump its id/class, and also dumps the uri of images that we discard. Then when the bug is observed they can quickly check the output to see if the favicon was discarded and an xul <image> with the correct sounding id had a frame reconstruct. Actually while thinking of this there is something simple we can do that should avoid this: try builds will show up here https://treeherder.mozilla.org/#/jobs?repo=try&revision=4086d7609f0200681e3c5552e6dcb5d4f8b1edfe Whoever sees this bug please try them.

(In reply to Timothy Nikkel (:tnikkel) from comment #21) > (In reply to :Gijs from comment #17) > > Fundamentally, it seems this is almost certainly a platform issue, like bug > > 1119455. Whether or not it has the same cause, without ever having seen it > > or having any steps that trigger it, I have no idea, nor do I know how to > > make progress on this bug. It would require someone from platform telling us > > how to get more information. :tn, do you have any ideas on how to > > distinguish this from 1119455, or figure out why this is happening more > > often / to more people now? > > Any change in the style of the browser chrome that affects the tab bar and > hence the favicons could mean this comes up more (or less) frequently. > > I guess if we wanted to confirm that this is the same as bug 1119455 we > could make a try build for users to use that dumps when we destroy the frame > for a xul <image> and dump its id/class, and also dumps the uri of images > that we discard. Then when the bug is observed they can quickly check the > output to see if the favicon was discarded and an xul <image> with the > correct sounding id had a frame reconstruct. > > Actually while thinking of this there is something simple we can do that > should avoid this: try builds will show up here > > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=4086d7609f0200681e3c5552e6dcb5d4f8b1edfe > > Whoever sees this bug please try them. I don't see the download link on your link firstly, but I'm anyway seeing the bug on macOS, and macOS build is busted here. I would also need a little bit more explanations on the place we need to check the things you asked to check, as I didn't get where we should do this.

Sorry, I fixed that in the next build here https://treeherder.mozilla.org/#/jobs?repo=try&revision=8d76a8dc46fb91a28e77b721864b39e526df0196 os x https://queue.taskcluster.net/v1/task/dUg6WKhDRamT7TSoiuZfWQ/runs/0/artifacts/public/build/target.dmg I would like if you could run the build enough to determine if you still see this bug or not, whatever you've been doing to see this bug.

(In reply to Timothy Nikkel (:tnikkel) from comment #23) > Sorry, I fixed that in the next build here > > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=8d76a8dc46fb91a28e77b721864b39e526df0196 > > os x > > https://queue.taskcluster.net/v1/task/dUg6WKhDRamT7TSoiuZfWQ/runs/0/ > artifacts/public/build/target.dmg > > I would like if you could run the build enough to determine if you still see > this bug or not, whatever you've been doing to see this bug. Okay, I finally found where the files to download are in the job details. Will run this instead of my "normal" build then. However I've questions remaining: is this build considered "risky" for my profile? ie. do I need to make a copy to run that build on, or my usual profile is find and is at no risk of being damaged? And in your previous comment you said "I guess if we wanted to confirm that this is the same as bug 1119455 we could make a try build for users to use that dumps when we destroy the frame for a xul <image> and dump its id/class, and also dumps the uri of images that we discard. Then when the bug is observed they can quickly check the output to see if the favicon was discarded and an xul <image> with the correct sounding id had a frame reconstruct." Is this still needed, or just running the try build is enough for that? If that's still needed, how do we do that check (in which output)?

(In reply to Clément Lefèvre from comment #24) > Will run this instead of my "normal" build then. > However I've questions remaining: is this build considered "risky" for my > profile? ie. do I need to make a copy to run that build on, or my usual > profile is find and is at no risk of being damaged? It shouldn't be risky, but make a copy of your profile just in case. > And in your previous comment you said "I guess if we wanted to confirm that > this is the same as bug 1119455 we could make a try build for users to use > that dumps when we destroy the frame for a xul <image> and dump its > id/class, and also dumps the uri of images that we discard. Then when the > bug is observed they can quickly check the output to see if the favicon was > discarded and an xul <image> with the correct sounding id had a frame > reconstruct." > > Is this still needed, or just running the try build is enough for that? If > that's still needed, how do we do that check (in which output)? Instead of that approach I tried to just fix the bug. So all that is needed is determining if you see the bug in that build. Thanks again.

(In reply to Timothy Nikkel (:tnikkel) from comment #25) > (In reply to Clément Lefèvre from comment #24) > > Will run this instead of my "normal" build then. > > However I've questions remaining: is this build considered "risky" for my > > profile? ie. do I need to make a copy to run that build on, or my usual > > profile is find and is at no risk of being damaged? > > It shouldn't be risky, but make a copy of your profile just in case. > > > And in your previous comment you said "I guess if we wanted to confirm that > > this is the same as bug 1119455 we could make a try build for users to use > > that dumps when we destroy the frame for a xul <image> and dump its > > id/class, and also dumps the uri of images that we discard. Then when the > > bug is observed they can quickly check the output to see if the favicon was > > discarded and an xul <image> with the correct sounding id had a frame > > reconstruct." > > > > Is this still needed, or just running the try build is enough for that? If > > that's still needed, how do we do that check (in which output)? > > Instead of that approach I tried to just fix the bug. So all that is needed > is determining if you see the bug in that build. > > Thanks again. I'll keep observing how it behave for a longer timeframe to confirm, but as of now it seems to solve half of the problem: I didn't got any favicon redraw on the tab bar yet, but I've got it one time on the big tabs overflow list. When this happens on this list it seems to fire a redraw of almost every favicon in the list.

(In reply to Clément Lefèvre from comment #26) > I'll keep observing how it behave for a longer timeframe to confirm, but as > of now it seems to solve half of the problem: I didn't got any favicon > redraw on the tab bar yet, but I've got it one time on the big tabs overflow > list. When this happens on this list it seems to fire a redraw of almost > every favicon in the list. There is another bug about this, that I recently moved to Core / Graphics, where all the icons in a menu (like the bookmarks menu) flicker like their gamma is changing. That's Bug 1393313. (In reply to :Gijs from comment #18) > (In reply to Clément Lefèvre from comment #16) > > - While I'm unsure, it might be related, since only one to three days I can > > see that some of these icons are not fully redrawn like it was since the > > beginning of that bug. When hovering the favicon, this one disappear but > > never comes back. > > This sounds like a separate bug that I've talked to Marco about and that's > supposed to be fixed now. Marco? The bugs I'm fixing in Nightly (just landed the last one in mozilla-central) are either about wrong favicon shown in the tab for a page, or a page missing favicon because it doesn't have a rel="icon". All the known bugs should be fixed in tomorrow's nightly (unless backouts) and I'll then proceed with uplifts, likely they will make beta 5. Those bugs are unrelated with flickering or half-shown icons though.

(In reply to Marco Bonardo [::mak] from comment #27) > (In reply to Clément Lefèvre from comment #26) > > I'll keep observing how it behave for a longer timeframe to confirm, but as > > of now it seems to solve half of the problem: I didn't got any favicon > > redraw on the tab bar yet, but I've got it one time on the big tabs overflow > > list. When this happens on this list it seems to fire a redraw of almost > > every favicon in the list. > > There is another bug about this, that I recently moved to Core / Graphics, > where all the icons in a menu (like the bookmarks menu) flicker like their > gamma is changing. That's Bug 1393313. Does this concern the tabs overflow list either? > (In reply to :Gijs from comment #18) > > (In reply to Clément Lefèvre from comment #16) > > > - While I'm unsure, it might be related, since only one to three days I can > > > see that some of these icons are not fully redrawn like it was since the > > > beginning of that bug. When hovering the favicon, this one disappear but > > > never comes back. > > > > This sounds like a separate bug that I've talked to Marco about and that's > > supposed to be fixed now. Marco? > > The bugs I'm fixing in Nightly (just landed the last one in mozilla-central) > are either about wrong favicon shown in the tab for a page, or a page > missing favicon because it doesn't have a rel="icon". All the known bugs > should be fixed in tomorrow's nightly (unless backouts) and I'll then > proceed with uplifts, likely they will make beta 5. > Those bugs are unrelated with flickering or half-shown icons though. So, no relation between those bugs and the favicon being redrawn/reloaded and not reappearing? Anyway I can't see this again as of now (and with the try build I'm currently running on).

(In reply to Clément Lefèvre from comment #28) > (In reply to Marco Bonardo [::mak] from comment #27) > > There is another bug about this, that I recently moved to Core / Graphics, > > where all the icons in a menu (like the bookmarks menu) flicker like their > > gamma is changing. That's Bug 1393313. > Does this concern the tabs overflow list either? hard to tell, but off-hand looks like a bug that could happen on Mac on any menu. I don't have enough details to give you a real answer, I can only guess a "yes". > > The bugs I'm fixing in Nightly (just landed the last one in mozilla-central) > > are either about wrong favicon shown in the tab for a page, or a page > > missing favicon because it doesn't have a rel="icon". All the known bugs > > should be fixed in tomorrow's nightly (unless backouts) and I'll then > > proceed with uplifts, likely they will make beta 5. > > Those bugs are unrelated with flickering or half-shown icons though. > > So, no relation between those bugs and the favicon being redrawn/reloaded > and not reappearing? Anyway I can't see this again as of now (and with the > try build I'm currently running on). It could have a relation with a missing favicon, but I doubt it relates to flicker. But note I don't have clear steps to reproduce, nor a clear idea of what may be the underlying cause, so it's again a guess based on the touched code.

So, :tnikkel: after a longer time than usual, I could however see the problem still being here, sadly. In the meantime, someone did show me bug 1401632 that could be related to the disappearing favicons (this afternoon at some point most of my favicons just disappeared one by one when I went over their respective tab with my mouse). This bug was duped on bug 1401777 which seems to relate to several problems around favicons. I get the feeling most of those problems actually are linked, and guess I'm good to go back to the normal builds to test latest 1401777 patches.

Nightly has all the fixes for favicons that were known, Beta will get those on b5 (GTB is on Monday). If it's not fixed there, it may be totally unrelated to those known favicons issues. Note there are also problems like bug 1404366 that are related to something in layout/graphics and still under investigation. In the end, I suspect this is just the same as bug 1401122.

(In reply to Marco Bonardo [::mak] from comment #31) > Nightly has all the fixes for favicons that were known, Beta will get those > on b5 (GTB is on Monday). If it's not fixed there, it may be totally > unrelated to those known favicons issues. > Note there are also problems like bug 1404366 that are related to something > in layout/graphics and still under investigation. > > In the end, I suspect this is just the same as bug 1401122. So, using latest nightly build, It seems I'm not getting favicons that definitely disappear (as of now). Blinking ones on the tab bar as well as the tabs overflow lists are still here though. ::mak as you seems to at least follow most of those bugs, do you think it can still be linked to another bug being worked on? Or is that still a different issue for which we need to investigate differently?

(In reply to Clément Lefèvre from comment #32) > ::mak as you seems to at least follow most of those bugs, do you think it > can still be linked to another bug being worked on? Or is that still a > different issue for which we need to investigate differently? Bug 1401122 and Bug 1393313 sound like the most likely candidates.

Tracked for now. If this isn't a recent regression or the fix comes in too late, we will have to live with a 57 wontfix.

I don't think we're sure if this issue still exists for 57, if it's a recent problem, or just something that happens intermittently. Maybe a duplicate of bug 1401122. In any case, too late for a patch in 57.

It looks like the bug disappeared by itself on my side, for the tab bar part (favicons doesn't blink anymore on the tab bar). I kept on obversation a few days just to be sure as it could be pretty random, so I can't tell exactly when it stopped, but I would say around one week, maybe a little bit more. So, are other affected people still affected by the bug or not. ::mak, if not, is it worthy trying to pin down the related commit(s)? On the other end, I can still see the problem in the tabs overflow list. I took a new look at bug 1393313, but while a part is similar, it doesn't look exactly the same: in my case favicons are reloaded a single time when opening the list. But it does it often but not every time I open the list. No flicker, just a single reload of the whole tabs favicons in the list. Do you think it should be a separate bug or not? NI ::mak for the above-mentionned questions, :Oriol to know if you can still see this issue on your side or not.

(In reply to Clément Lefèvre from comment #36) > :Oriol to know if you can still see this issue on your side or not. Today I haven't seen it yet, but yesterday or two days ago I did.

(In reply to Clément Lefèvre from comment #36) > ::mak, if not, is it worthy trying to pin down the related commit(s)? It would be cool, but honestly it may not be trivial. It could even be due to external reasons, for example a graphical driver update, or a timing skew that makes so that it's harder to reproduce the bug. That said, if you have any spare time to dedicate to that research, we may benefit from it. > On the other end, I can still see the problem in the tabs overflow list. I > took a new look at bug 1393313, but while a part is similar, it doesn't look > exactly the same: in my case favicons are reloaded a single time when > opening the list. But it does it often but not every time I open the list. > No flicker, just a single reload of the whole tabs favicons in the list. Do > you think it should be a separate bug or not? I'd rather keep this open, wait for the dependencies and see if they fix this, then we can move from there. There is too much noise compare to signal on favicons at the moment, part because we recently changed their behavior, part because we surely have 1 graphics/layout bug and one network bug (bug 1406091). It will be hard to distinguish the edge cases until some of this noise goes away.

(In reply to Marco Bonardo [::mak] from comment #38) > (In reply to Clément Lefèvre from comment #36) > > ::mak, if not, is it worthy trying to pin down the related commit(s)? > > It would be cool, but honestly it may not be trivial. It could even be due > to external reasons, for example a graphical driver update, or a timing skew > that makes so that it's harder to reproduce the bug. > That said, if you have any spare time to dedicate to that research, we may > benefit from it. No driver update on my side, it was on a old macbook pro from 2011 using OS X 10.9, nothing change regarding hardware or drivers anymore. Looks like :Oriol is still xperiencing the bug anyway. As for pinning it down, it would be difficult for me looking at how random this was. Maybe a look at repository log for favicons commits. I can't clone m-c here though.

Lately I don't remember seeing this issue, maybe it's fixed, but hard to know due to the lack of reliable steps to reproduce.

(In reply to Oriol Brufau [:Oriol] from comment #40) > Lately I don't remember seeing this issue, maybe it's fixed, but hard to > know due to the lack of reliable steps to reproduce. I'm not experiencing it anymore either in the tab bar for quite some time now, so I think it's fixed there. I'm still experiencing it in the tabs overflow list though: nothing changed there.