While opening another AppBar styling related issue #110951, I also noticed that the current fix #108332 for this issue in master, has issues when it comes to smooth lerping of the colors for the icons, while transitioning from old theme to new one.

The icon colors "jank" via their default colors and do not animate smoothly from previous to new themed color. This was explained a bit further here #110951 (comment). This kind of theme color animation jank via default color is normally not observed on theme transitions and should not be there.

Hello @rydmike. Since this is an issue that is fixed in master, are you suggesting a cherry pick?

@exaby73 this issue did not exist in Flutter 3.0.x stable, and was caught and fixed in master well before 3.3.0 release (about 25 days), so I had kind of expected that it would not regress into 3.3.0. So from that viewpoint a cherry pick with when first hotfix is released would be nice.

However, current fix in master does have an issue too (as explained in the comment above), so maybe that is why the fix was not included in 3.3.0.

If you run the sample on master you can see that the themed AppBar icon theme always transitions via the default icon theme colors and we see a "flash" of the default values in the transition. This is not how theme transitions should, or do behave. So that part needs another look in master too.

Could you paste a complete and minimal, reproducible example the reproduces this flash you mentioned?

Hi @exaby73,

I am unable to reproduce the animation via default color that I saw in this case earlier. I was not able to reproduce it with latest master anymore.

So strike that claim. The same sample as in original issue worked before to show it, but I could no longer repeat it using it, or some variations of it. If I for some reason do see the issue again, I will open a specific separate case for it.

As for this issue itself, I needed a simple case to refer to that showed that what was a regression from 3.0.x to master, here #107305, that was closed in master via #108332, actually migrated into Flutter 3.3.0 stable release and did not land as I had expected in Flutter 3.3.0 stable, despite the fix in master for the issue being merged into master some 25 days before 3.3.0 release.

I had elsewhere earlier mentioned and linked that the fix for the issue could be expected to land in Flutter 3.3.0, so it would never be seen in stable, but since it did not, an issue that explained that it did not land was needed for documentation purposes. For me this issue serves that documentation purpose as is, be it open or closed.

If Flutter team wants to close it as something that is solved in master and will land whenever it does in stable, or if a cherry pick for a hotfix is considered appropriate and then close it after that, I'm OK with either. I just found it a bit sad that this regression issue had to land in Flutter 3.3.0 (and 3.3.1) stable when its fix had been merged 25 days in master before 3.3.0 was released.

OT: Sorry about the slow response, managed to catch Covid and it made me a bit under the weather for a few days. Just mild flu like symptoms, nothing major :)

Hello @rydmike. Hope you're feeling better :)

Unfortunately, not all issues are prioritized for a hotfix. If you want to request for a cherry pick, you can find a link to the template here. Would be great if you include the exact commit that fixed this in the template if you do decide to request a cherry pick.

Since this issue is fixed, I will be closing it as a duplicate of #107305. If you disagree, please comment and I can reopen it. Thank you.

Preferring to have a bug that was not in then current stable (3.0), that was fixed 25 days before new stable release (3.3) in master, not included in the stable release, but instead allow the bug to regress into the new stable release (3.3), is a bit of an odd preference, but certainly choice as well.

Perhaps an oversight, perhaps there was a good reason for it, I'm not in the loop on that. Would love to know what the rationale was, if there was one.

As mentioned, I needed a ref to a simple issue that I can point to that explains why this issue now exists in Flutter stable 3.3. Since I had previously stated in package docs that I did not think this issue would ever land in stable, so this issue would never matter in Flutter stable releases, but now it does.

Since I could not add any further comments to the original issue to explain the situation, I had to open this as a new issue to provide the additional explanation. Now that this has been done, and an issue entry exist that I can refer to, it does really matter if it is open or closed.

As for the hot fix cherry pick, I'm tagging @QuncCccccc that made the fix #108332 and @HansMuller involved in the review of it. They are better positioned to consider if this should be added as hotfix, or if it is something Flutter users will have to wait another 3 months on or so, to eventually see it in the next stable release.

Opinion:
If you ask me, this issue should not have been allowed to land in Flutter stable 3.3, it did not exist in Flutter 3.0, was caught and fixed well in advance of Flutter 3.3 stable release, there was no reason to let it land in stable 3.3. But yeah, I know, stuff happens and Flutter 3.3 did seem a bit rushed, so maybe that is why.
Many M3 features that would have made 3.3 the first release where I could actually recommend trying and using M3 in a Flutter production app, did not make it. So my personal green light on that is still a no go, maybe next stable, I hope so.

I will reopen this issue for further insights from the team. Maybe they would be able to give you a better rationale on why this was not included.

Any update on this issue? 3.3.1 & 3.3.2 have been released and I was surprised to see that the fix was not included in either of these...

Any update?

Although Flutter 3.3 didn't actually debut until the end of August, the code freeze for Flutter 3.3 was around July 7th. Unfortunately, at the time, there wasn't a regression test for this case and the problem wasn't detected. Although the issue has been fixed in the master branch and in more recent betas, we haven't included #108268 and #108332 in a 3.3 hotfix release because the changes are more complex than we usually include in a "cherry pick". This is indeed unfortunate.

Thanks @HansMuller for the reply and insights. I noticed when I looked at what is needed to include it, that it is a bit more complex, so the situation is understandable.

Personally I don't think it is so critical that it did not land yet, because Material 3 is not really yet useable in Flutter 3.3.x anyway, unless you are prepared to accept a world of theming challenges and inconsistencies. So I recommend people to stay off M3 for production for now anyway. Based on recent activities in master channel it looks like next stable release might be able to change this status, at least I hope so.

As for this issue. I basically would have been happy adding just a comment to the original issue, saying same as above, that this issue unfortunately migrated to Flutter 3.3 stable channel since the fix did not land. As I could not do that when the original issue was closed for new comments, I had to open this issue to document this fact, so I could refer to it from FlexColorScheme known theming issues, here: https://docs.flexcolorscheme.com/known_issues#flutter-sdk-appbar-icon-theme-not-respected-regression

AppBar IconTheme animation issue - seen before

When I opened this issue I also said this:

If you run the sample on master you can see that the themed AppBar icon theme always transitions via the default icon theme colors and we see a "flash" of the default values in the transition. This is not how theme transitions should, or do behave. So that part needs another look in master too.

and later:

I am unable to reproduce the animation via default color that I saw in this case earlier. I was not able to reproduce it with latest master anymore. So strike that claim. The same sample as in original issue worked before to show it, but I could no longer repeat it using it, or some variations of it. If I for some reason do see the issue again, I will open a specific separate case for it.

What I observed on the AppBar icons was similar to the issue described here:

#112216 "Fixed an iconTheme lerping problem with ChipThemeData"

But as said, I could no longer see it on the sample. Still I have not checked recently using master channel and and a Themes Playground app build using it. When I do and if I see the issue again, the playground is very useful not only for theming, but also for finding any odd theme behavior in dynamic theme changes.

Input Decoration (Off topic but M3 issues related)

@HansMuller, how ready is M3 input decoration in master channel considered now?

Just asking because last I looked at it I noticed some diffs compared to web M3 spec. However, back then I learned it was not completely done yet so I did not open an issue. If it is done and I still see that diff compared to web spec, I will open an issue for it.

Might just again be a case of db tokens and web M3 spec not matching, and tokens used by Flutter being correct. Found two of those before, if so, the web spec needs a fix. But it might also be a Flutter M3 issue, if it is still there, I did not check yet, might be fixed if it was still work in progress back when I looked at it, about a month ago.

@rydmike - if you've found aspects of InputDecoration that don't match the M3 spec (on the master channel) please file issues, we'd like to make sure that they're fixed before the next stable release.

This regression is solved in new stable 3.7.0, but if someone uses Flutter stable 3.3.x they will still see it there. Closing this regression issue warning as obsolete and no longer relevant in stable Flutter 3.7.0.

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.