In release mode we start off at 0x0 but we don't in debug mode

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.

@abarth

Presumably this is a race? @abarth does this mean we're doing a build before we know the screen size? FYI @chinmaygarde @jason-simmons

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?

We can reorder initialization to make sure we call main after at least one resize.

I'm trying

  ui.window.onMetricsChanged = () {
    print(ui.window.size);
  };

right before runApp(), but it doesn't print anything, regardless of whether or not I use --release.

The hook only takes one function and the framework is probably overwriting your function. You probably want to put your print in bindings.dart.

@abarth

@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 call main.

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.

@abarth

@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.

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.

The complex_layout benchmark triggers this in a way that crashes the framework, fwiw.

This also affects --no-hot debug mode.

Closing this in favour of #6537.

Roll engine to 4374ccc.

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.

Navigation Menu

Repository navigation

In release mode we start off at 0x0 but we don't in debug mode #5259

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

In release mode we start off at 0x0 but we don't in debug mode #5259

Description

Activity

eseidelGoogle commented on Aug 5, 2016

chinmaygarde commented on Aug 5, 2016

chinmaygarde commented on Aug 5, 2016

dragostis commented on Aug 5, 2016

abarth commented on Aug 5, 2016

chinmaygarde commented on Aug 8, 2016

abarth commented on Aug 8, 2016

dragostis commented on Aug 8, 2016

abarth commented on Aug 8, 2016

Hixie commented on Sep 9, 2016

Hixie commented on Oct 26, 2016

Hixie commented on Nov 14, 2017

github-actions commented on Aug 15, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions