Repository navigation
ThemeData issues with operator, copyWith and debugFillProperties #91587
Description
ThemeData Class has the following issues
1) Two properties are missing from == operator override
The properties:
- focusColor
- hoverColor
That exists as properties in ThemeData.raw and in hashCode are missing from operator. The lines:
&& other.focusColor== focusColor
&& other.hoverColor== hoverColorshould be added to operator.
The current operator implementation will cause issues. I had some, and it led me to investigate these overrides more closely, which is why I found this and the other issues in this report.
2) copyWith includes brightness parameter
The brightness is a getter in ThemeData that returns brightness from ThemeData.colorScheme. It can thus not be modified with a copyWith of ThemeData, nor does returned ThemeData.raw from the copyWith include any brightness value!
If somebody tries to modify theme brightness with this copyWith, they will not succeed and "might" be confused.
The
brightnessin thecopyWithparameter list is probably a remnant from whenbrightnessexisted inThemeDatadirectly. It should however be removed in current implementation fromcopyWithas a parameter.
| Brightness? brightness, |
3) debugFillProperties has the following issues
The textSelectionTheme is added to it twice, as two consecutive rows:
| properties.add(DiagnosticsProperty<TextSelectionThemeData>('textSelectionTheme', textSelectionTheme, defaultValue: defaultData.textSelectionTheme, level: DiagnosticLevel.debug)); |
| properties.add(DiagnosticsProperty<TextSelectionThemeData>('textSelectionTheme', textSelectionTheme, defaultValue: defaultData.textSelectionTheme, level: DiagnosticLevel.debug)); |
The following ThemeData properties are missing from debugFillProperties:
visualDensityprimaryColorLightprimaryColorDarksplashFactoryfixTextFieldOutlineLabeluseTextSelectionTheme
For correct toString() and debug DevTools, functionality the extra entry of textSelectionTheme should be removed and the missing properties added.
The debugFillProperties also includes brightness, but since it is not a property of ThemeData it should be removed.
| properties.add(EnumProperty<Brightness>('brightness', brightness, defaultValue: defaultData.brightness, level: DiagnosticLevel.debug)); |
- Observation: The order of the properties in
debugFillPropertiesdeviates significantly from the order of properties inoperator,hashCodeandThemeData.rawit would be helpful if they were in the same order.
How to Reproduce
The above errors can be observed in the source code in all current versions from stable 2.5.2 and all channels up to master 2.6.0-12.0.pre.287.
Issue Visualized
The attached image table shows the issues. In order to easier compare and find what was going on with the
properties I copy-pasted the props in the image from ThemeData from master channel, into a table in order to compare and easier see what is going. I added it here as well, but the found issues are summarized above and fixes are straight forward.
In the table the debugFillProperites have been manually re-ordered into same order as the other methods properties, to be able to see the gaps more easily. I recommend putting them in the same order in the code as well.
Turns out that the parameters to copyWith and its return values, are not in the same order and neither of them agrees with the order used on ThemeData.raw, operator and hashCode. The copyWith params and return order that are off, in relation to them are marked in green. They are shown in the order they appeared in the code. They are all there though, so no issue, but again, same order would be nice.

Activity
maheshj01 commentedon Oct 11, 2021
Hi @rydmike, Thanks for the detailed issue. All three issues with the
ThemeDataclass can be reproduced on stable 2.5.2 and themaster 2.6.0-12.0.pre.287channel.Summing up the source code links from master
focusColorandhoverColorshould be exactly below dividerColor in orderBrightness cannot be set using
copywithconstructorduplicate debugFillProperties
flutter doctor -v
guidezpl commentedon Oct 13, 2021
Please note,
hashCodealso needsfocusColorandhoverColordarrenaustin commentedon Oct 13, 2021
@rydmike thanks for the detailed report. I have just submitted a PR that should resolve most of these issues if approved. The one I didn't address was the removal of
brightnessfromcopyWith. I understand what you are getting at, and it is a little odd. However it is still functionally equivalent to what was there whenbrightnesswas its own property.The main reason it is still there however, is that we can't remove it immediately without potentially breaking existing apps that use it. We could deprecate it so that we would be able to remove it in the future. We will consider this going forward.
I also left the diagnostic properties in their current order. I am thinking we may want to do a separate ordering pass on this and either make them all alphabetical or something like what @guidezpl is proposing in #91497.
rydmike commentedon Oct 14, 2021
Hi @darrenaustin totally agree on your comment on the
brightnessand itscopyWith. I missed the "deep"copyWithdone for it oncolorScheme. I noticed it the other day too and was about to add a comment that it should indeed be there. Good catch!Normally one would not expect to find that in data class like this, but I totally get why it is there. It used to be a direct property in
ThemeData. Now I see how nicely it was moved intocolorSchemewith the getter and the deep copy, even looked up its PR: #56956 last year in May, so not so super long ago. And sure removing that would break a lot of stuff, no doubt. Have to remember this neat setup to keep API intact myself too if I need it.Thanks for adding the missing props to the == operator, when it lands that should fix my failing tests that I had to skip. The
debugFillPropertiesare less critical, but nice to have all props there now too.About the order, certainly not important for the functionality. Still I think when there are as many properties in class as in
ThemeDatathat alphabetical order would make most sense, at least it makes it easier to check that you have not forgotten anything when you modify it. Which I guess is what happened here.github-actions commentedon Nov 5, 2021
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 -vand a minimal reproduction of the issue.