Closed
Description
Consider the following applet:
void main() {
runApp(
new MaterialApp(
title: 'Bug Showcase',
theme: new ThemeData(
primarySwatch: Colors.blue
),
home: new LayoutBuilder(
builder: (BuildContext context, BoxConstraints constraints) {
print(constraints);
return new Container();
}
)
)
);
}
Running with flutter run this outputs:
I/flutter : BoxConstraints(w=360.0, h=640.0)
Running with flutter run --release this outputs:
I/flutter : BoxConstraints(w=0.0, h=0.0)
I/flutter : BoxConstraints(w=360.0, h=640.0)
This is problematic especially in the case of animating a widget based on its initial constraints.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
eseidelGoogle commentedon Aug 5, 2016
Presumably this is a race? @abarth does this mean we're doing a build before we know the screen size? FYI @chinmaygarde @jason-simmons
chinmaygarde commentedon Aug 5, 2016
Window metrics can be updated at any time. Animations will have to account for the same in any case (not just the initial resize). Can you confirm you are getting
window.onMetricsChanged();at different spots on debug and release?chinmaygarde commentedon Aug 5, 2016
We can reorder initialization to make sure we call main after at least one resize.
dragostis commentedon Aug 5, 2016
I'm trying
right before
runApp(), but it doesn't print anything, regardless of whether or not I use--release.abarth commentedon Aug 5, 2016
The hook only takes one function and the framework is probably overwriting your function. You probably want to put your print in bindings.dart.
chinmaygarde commentedon Aug 8, 2016
@abarth, @dragostis: I am not sure where the fix for this lies. Backing up the initial call to main till the first resize on all platforms is convoluted. However, we can change the initial main closure be something else, say,
_start. This can then decide when to callmain.abarth commentedon Aug 8, 2016
IMHO, apps should be robust to being sized 0x0 at startup. If the issue is inconsistency, maybe we should make that happen every time instead of having it be a race.
dragostis commentedon Aug 8, 2016
@abarth Sure, the only issue might be the transition from 0x0 to WxH that the user might not consider. Anyway, this is not really user-facing.
abarth commentedon Aug 8, 2016
Exactly. We should force developers to consider those cases. Otherwise we'll have to slow down app launch to ensure that the width and height are always available at startup.
Hixie commentedon Sep 9, 2016
The complex_layout benchmark triggers this in a way that crashes the framework, fwiw.
Hixie commentedon Oct 26, 2016
This also affects --no-hot debug mode.
[-]Running in release mode pushed zero box constraints.[/-][+]In release mode we start off at 0x0 but we don't in debug mode[/+]Hixie commentedon Nov 14, 2017
Closing this in favour of #6537.
Roll engine to 4374ccc.
github-actions commentedon Aug 15, 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.