I would love to get some feedback on the PR. I'm prepared to make any additional changes to meet the requirements.

This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

It also appears that the analyzer is complaining about trailing spaces on the ends of some lines. (See the analyze-linux check's details)

Gold has detected about 1 new digest(s) on patchset 4.
View them at https://flutter-gold.skia.org/cl/github/96664

Gold has detected about 1 new digest(s) on patchset 5.
View them at https://flutter-gold.skia.org/cl/github/96664

Gold has detected about 8 new digest(s) on patchset 7.
View them at https://flutter-gold.skia.org/cl/github/96664

Gold has detected about 16 new digest(s) on patchset 8.
View them at https://flutter-gold.skia.org/cl/github/96664

Gold has detected about 6 new digest(s) on patchset 9.
View them at https://flutter-gold.skia.org/cl/github/96664

@darrenaustin fixed everything.
Added more docs and removed the trailing spaces
Seems like there is a problem with the CLA because I accepted your commit suggestions. Is that resolvable or I should reset and apply the changes myself.

Gold has detected about 18 new digest(s) on patchset 10.
View them at https://flutter-gold.skia.org/cl/github/96664

reset and re-applied changes to avoid CLA issues and not waste more time on this.

@talamaska thanks for the update. It looks like the new tests are failing however. From the logs for one of the failing checks:

00:35 +626: /b/s/w/ir/x/w/flutter/packages/flutter/test/material/bottom_navigation_bar_test.dart: label style color should override itemColor for BottomNavigationBarType.shifting                     
══╡ EXCEPTION CAUGHT BY FLUTTER TEST FRAMEWORK ╞════════════════════════════════════════════════════
The following TestFailure was thrown running a test:
Expected: Color:<Color(0xffff9900)>
  Actual: Color:<Color(0xff0004ff)>

Can you take a look? Thx.

@darrenaustin it seems your suggestion for shortening is not working as expected.

 return (iconTheme ?? const IconThemeData()).copyWith(color: itemColor);

I think you missed the point initially or overlooked. The thing here is that itemColor can be null and the short variant is not covering this case. In any case, if I return my code to the previous state the tests are passing.
my logic is copied from the _effectiveTextStyle and changed to work for icon theme and item color.
I'm returning my way of writing, it is correct and it is following the same style as the _effectiveTextStyle.

P.S on additional look I see another problem that I miss. iconTheme will never be null in the condition cause we just assigned a fresh IconThemData. Will try to make it better.

P.S Also it seems that iconTheme should override not only iconColor, but also textStyle color.

I think it is fixed now.
Added more docs as well.

@darrenaustin is there something else that is blocking this PR?

@darrenaustin, hi there. I wonder, can I get a review again? It's been quite some time since I implemented the requested changes. I would really like this to be merged before starting other efforts for eventual material 3 migration, because I'm afraid the issues will end up in the new version as well. I have pinged in discord as well. If it is more convenient we can chat there.

@darrenaustin

I'm also kinda confused why Shifting bottom bar is so broken and should I try to fix that as well?

vs this in fixed

In the end if I'm going to implement the above suggested selected and unselected effectiveIconTheme

final IconThemeData effectiveSelectedIconTheme =
      _effectiveIconTheme(
        widget.selectedIconTheme ?? bottomTheme.selectedIconTheme,
        widget.selectedItemColor 
        ?? bottomTheme.selectedItemColor 
        ?? themeColor
      );
      
final IconThemeData effectiveUnselectedIconTheme =
      _effectiveIconTheme(
        widget.unselectedIconTheme ?? bottomTheme.unselectedIconTheme,
        widget.unselectedItemColor 
        ?? bottomTheme.unselectedItemColor 
        ?? themeData.unselectedWidgetColor
      );

and breaking that golden test, it would make sense to implement the colorTween separation as well

The white label and icons is partly caused by the tween for the shifting type, at least the label color
I don't think this is correct

Why would I have themeData.colorScheme.surface for begin and end, shouldn't it be themeColor for the end?

When I implement the suggested above nullish coalescing for the effectiveIconTheme the icon is colored correctly

And this is if I change the end value for colorTween for shifting type to themeColor

I think the right call would be to recreate the goldens with my patches in order to pass the tests. After all the policy of flutter is to make breaking changes if it is for the sake of fixing things.
Just give me a heads up if you would like me to push all the changes I have mentioned including the colorTweens

@darrenaustin in the end, would it make sense to drop all those fixes if there is a material 3 rewrite going? Or is the new material 3 navigation bar will be a new widget?

I saw #96480 this morning and filed a PR for it based on Hixie's comment, which addresses selectedLabelStyle and unselectedLabelStyle.

Now I found this PR and #64358

Just closed new issue #96480 for a duplicate of the issue linked here #64358

@darrenaustin

fix: BottomNavigationBarItem title's color is not overriden neither by selectedLabelStyle nor unselectedLabelStyle

I think my PR addressed the issue matching the Flutter docs

fix: BottomNavigationBarItem icon's color is not overriden neither by selectedLabelStyle nor unselectedLabelStyle

selectedLabelStyle or unselectedLabelStyle shouldn't update BottomNavigationBarItem icon's color.

@darrenaustin @TahaTesser if my PR is not needed anymore feel free to close. It's a shame that I was waiting for review months and @TahaTesser PR was reviewed and approved in a matter of hours. I understand that my PR was not perfect, but anyways.
I'm happy that's resolved. Do you think the shifting bottom bar colors should be fixed in a separate PR and update it's goldens?

@talamaska
My PR had to be reverted #102756, I would suggest keeping this PR open and making sure to address the issues related to revert in your PR.

What is the status of this PR? Did we end up fixing this issue in the other PR?

@talamaska sorry for the delays in dealing with this PR. You are welcome to come bug us on our Discord server (link in the contributing guidelines) if you would like to ask for reviews when we drop the ball. :-)

@Hixie Hi, well, it seems the PR is a no go, because it is breaking some golden tests. Which on my opinion just rely on a wrong behavior and in addition the reported issues are not included in the existing tests. I didn't get any feedback on the question about the shifting bottom bar styles or any other question in my comment to @darrenaustin. In the other PR #102756 that was reverted I got an explanation that this is a breaking change and there is a different process of implementing those - with temporary flags or something else that can gracefully help devs migrate to the new behavior. So I'm not sure what to do here. About the Discord channel I didn't get any response there when i was waiting for a review last time.

If it's breaking some customer tests then yeah, generally that means we end up putting a flag that flips between the old and new behaviours for a while, so that we can migrate the code. That's relatively straight forward; you just have a static boolean variable BottomNavigationBar.useLegacyColorScheme that defaults to true, and you implement your logic only when it's false. Then we land that, flip the flag in any customer code, make the tests pass, then we flip the default for the flag and remove the old behaviour, land that, remove the flag flip in the customer code, and then finally remove the flag. Ideally if we do this we'd also publish a migration guide, which for this kind of change would be really trivial, just telling people there's nothing to change, all we've done is make the colors better, and pointing them to the properties they can use to control the colors if they prefer the old styles.

Looks like the customer_testing shard is breaking because you may have done a merge instead of a rebase. I recommend squashing your commits then rebasing so that it's the last commit on your branch, that way the script knows which version of the customer tests to run.

I couldn't figure out what the shifting label issue was, can you elaborate on this? Where do the screenshots come from?

For the migration guide the documentation for doing that is in the template: https://github.com/flutter/website/blob/main/src/release/breaking-changes/template.md

More information about breaking changes is at: https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes

I couldn't figure out what the shifting label issue was, can you elaborate on this? Where do the screenshots come from?

@Hixie
The shifting label and icons are white (surface color) if the user doesn't set any colors or styles.
The screenshots are taken before v3. I'm almost sure they will be the same in master.

@Hixie will check the info about the breaking changes. For now the flag is implemented and all the conditional logic is there, so with the flag true, no tests are breaking and tests are testing with the flag equal to false. Thanks for sharing those with me.

Looks like the customer_testing shard is breaking because you may have done a merge instead of a rebase. I recommend squashing your commits then rebasing so that it's the last commit on your branch, that way the script knows which version of the customer tests to run.

Yes I merged from master. I didn't know I have to rebase. I'm not sure how to squash my commits and then rebase since i already merged master in my branch.

@Hixie Could you please elaborate on squashing and rebasing. I have like 3 merges from master thought the life of this branch. Do I need to revert from the beginning, make my changes, then rebase master into my branch? I'm sorry if this is a trivial question, but I have never rebased before and I see I can't squash commits if they include a merge in the middle. Would it be easier to just drop this PR, make a new branch from the current master, add my changes and submit a new PR?

Easiest way is probably to just create a new branch, then cherry-pick your commits onto it. Alternatively you might be able to do it using git rebase -i where you just select your commits and skip the merge commits (I'm not sure exactly how that works since I don't normally try to use merges). In general for Flutter we recommend using rebases, see also https://github.com/flutter/flutter/wiki/Tree-hygiene#using-git

@darrenaustin @Hixie closing this PR in favor of a new one #107924