Overflow warnings are impossible to disable

[esDotDev]

Problem

There are often times where we intentionally have overflow by design (example below).

Although this will look fine in production, this spamming of the console, and on-screen clutter negatively impacts developer productivity.

This is disruptive to development because it prevents you from clearly seeing the UI you are working on. You can switch to profile mode, but then you lose the ability for hot reload. Further, Android Simulator does not support profile mode.

It also confuses team members who report errors / log bugs, when they spot overflow in the console, when it was intentional by another developer. Causing a lot of wasted time and repetitive discussions.

Essentially feels like we are fighting the framework here, and it won't co-operate with what we want to do.

Possible Solution

It would be nice if the developer had the option to tell a parent not throw overflow errors at specific points in the tree.

The idea is not to disable Overflow warnings globally, but to tell specific sub-trees to not display an error.

OR

The framework could properly detect when ClipRect is applied, and then not throw the warning. Currently while it does tell you do add a ClipRect, this seems to have no effect on whether the warning is thrown or not.

Example 1

Here we have a panel that, when child is changed, it will size itself to match that child. This requires that, when changing children, some of the content is temporarily clipped. By design.

yiHPAxzqAz.mp4

Example on dartpad here: https://dartpad.dev/?id=8879b345a2f5eef780fa4840c3a4be30
Gist: https://gist.github.com/esDotDev/8879b345a2f5eef780fa4840c3a4be30

Resulting in this error:

The suggested fixes of adding a ClipRect or a ListView are not desired. A ClipRect is already in place in the parent, and a ListView is not desired as it adds a ton of complications and potential bugs, to an otherwise simple implementation.

Example 2

In another situation, we have a visual decorator that is already clipped (otherwise the effect wouldn't work), and we want to spin the circle around, to reveal another title, while the previous title is clipped out of view.

Again the framework decides it knows best, and aggressively tells us we're doing something wrong, when this really a nice elegant approach, and overdraw is minimal (and clipped regardless, as you can see)

You can also see how this blocks me from seeing the top or bottom of the widget, actively slowing down my development, and preventing me from seeing potential errors.

Example 3

Here we use an animated container to hide or reveal a child widget. Normally the child would scale-down here, but our design would prefer that the widget keep its natural size, and instead be cropped out of view.

This can be done simply and robustly with something like:

AnimatedContainer(
  width: _isOpen: 60 : 0,
  child: ClipRect( 
      child: UnconstrainedBox(
         child: FlutterLogo(50);
      )))

But again, the overflow error blocks us from really seeing the finer pts of the animation, unless we run in profile mode. Also weird how we are usng a ClipRect, but the framework complains we should be using a ClipRect.

[maheshj01]

Hi @esDotDev, thanks for filing the issue, I believe you are trying to hide the errors shown from the Flutter framework, I believe onError can help you to handle the custom error and also hide it.
Please take a look at the below code sample which just prints to the console when the overflow error occurs.

code sample

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
  FlutterError.onError = (FlutterErrorDetails details) {
    print('flutter error hidden from console');
    // FlutterError.dumpErrorToConsole(details, forceReport: false);
  };
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      home: PageOne(),
    );
  }
}

class PageOne extends StatelessWidget {
  const PageOne({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Column(
        children: [
          for (int i = 0; i < 100; i++) Text('$i'),
        ],
      ),
      floatingActionButton: FloatingActionButton(
        child: const Icon(Icons.add),
        onPressed: () {},
      ),
    );
  }
}

class PageTwo extends StatelessWidget {
  const PageTwo({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Builder(builder: (context) {
        return Center(
          child: ElevatedButton(
            child: const Text('Show SnackBar'),
            onPressed: () {
              ScaffoldMessenger.of(context).showSnackBar(
                const SnackBar(
                  content: Text('SnackBar!'),
                  behavior: SnackBarBehavior.floating,
                ),
              );
            },
          ),
        );
      }),
    );
  }
}

[esDotDev]

Thanks! That does indeed help a little for cleaning up the console.

But it's not really what I'm looking for:

• I want to turn off overflow errors for a specific widget, when I am doing it on purpose. I don't want to globally remove overflow errors.
• While less verbose, this method does not remove the yellow lines in debug mode, and still produces an error message, which will still confuse team members making them think something is wrong.

Basically asking for some sort of "developer knows best" hook, where we can tell a specific child widget to quiet down about its overflow errors.

[esDotDev]

It's actually quite disruptive to development. I either have these giant yellow bars that stop me from accurately evaluating / tweaking my UI, or I am forced to run it in profile mode, which disables hot-reload, also preventing me from efficiently working on the UI.

The frame work is just doing to much here, assuming too much. Untie our hands!

[maheshj01]

Thanks for the info, Labelling this issue for further insights from the team.

[esDotDev]

Thanks for the info, Labelling this issue for further insights from the team.

Thx! I have updated the original post to include a running example on dartpad:
https://dartpad.dev/?id=8879b345a2f5eef780fa4840c3a4be30