text:
AppBar back button focus/hover circle should not fill up whole height

Steps to reproduce

Set up two screens with an AppBar and add a way to navigate to the other one
Run the app. (I tried macOS, CanvasKit, and skwasm)
Navigate to the second page
Hover over the automatic back button in the top app bar
Notice its hover circle fills up the whole height rather than have a consistent hover target

Expected results
The circle from hovering over the back button wouldn't fill up the entire height of the app bar, nor expand when the height increases.
Actual results
The back button hover circle fills up the entire height of the app bar, both with the default height and at increased heights. See screenshots below for reference.
Code sample
Code sample
import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

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

class HomePage extends StatelessWidget {
  const HomePage({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Home screen'),
        elevation: 8,
        toolbarHeight: 96,
      ),
      body: Center(
        child: TextButton(
          child: const Text('Go to other screen'),
          onPressed: () {
            Navigator.push(
              context,
              MaterialPageRoute(
                builder: (BuildContext context) => const SecondScreen(),
              ),
            );
          },
        ),
      ),
    );
  }
}

class SecondScreen extends StatelessWidget {
  const SecondScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Other screen'),
        elevation: 8,
        toolbarHeight: 96,
      ),
      body: const Center(
        child: Text(
          'Other screen content',
        ),
      ),
    );
  }
}

Screenshots

Screenshots
Fill up whole height (default height):

Fill up whole height (expanded height):

Expected behavior:

Flutter version info
Version
Flutter 3.19.0-3.0.pre.43 • channel main • https://github.com/flutter/flutter
Framework • revision f961fdf2ba (4 hours ago) • 2024-01-10 17:37:07 -0500
Engine • revision a045134c91
Tools • Dart 3.4.0 (build 3.4.0-14.0.dev) • DevTools 2.31.0

it is given in app_bar.dart line 231 that in app_bar it will automatically take the back icon button if its not defined in the leading section and i think we can resolve it by fixing the height for icon widget in case of leading as it given in constraints that the leading icon can't have width more than leadingwidth and the height can't exceed toolbarheight, can anyone verify this ? please

Sir i have resolved the problem

see

The AppBar's leading widget fills the available space (height) because it's easy to align the widget within the space, e.g. with Center, but it's not possible enable filling the available space if the AppBar consumes it by default.

@HansMuller what about using container or material? I have used them and it was working on the leading

@nikkivirtuoso - yes wrapping the leading widget with another widget, like Container, that absorbs the additional height is a good solution.

I have done this and created a pull request but it is failing some test cases

@HansMuller can you please help me with these errors ?

@parlough I agree with you this is a bug. The default behavior should not be like this. You get the wrong size on the implicit leading back button's state layer in M3 mode, even if you do not change the size of the AppBar, and yes it grows with the size of the AppBar.
@HansMuller This is a Material-3 spec bug, the default icon state layer should be 40dp regardless of the size of the AppBar.
AppBar Implicit Back Button State Layer Bug
The state layer of an implicit back button in a AppBar gets the wrong size.
Expected result
Expect that the state layer of the implicit icon back button on the AppBar follow the Material 3 specification in Material-3 mode and that it thus is 40dp regardless of AppBar size.

Default Size
Bigger Size

Material 3 specification : https://m3.material.io/components/top-app-bar/specs
The icon button state layer should be 40dp and the tap target size 48dp.

Actual result
The state layer of size of the implicit back button gets the wrong size, it expands to fills the AppBar height.

Default Size
Bigger Size

Code sample for the actual result
import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

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

class HomePage extends StatelessWidget {
  const HomePage({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Home screen'),
        elevation: 3,
      ),
      body: Center(
        child: FilledButton(
          child: const Text('Go to other screen'),
          onPressed: () {
            Navigator.push(
              context,
              MaterialPageRoute(
                builder: (BuildContext context) => const SecondScreen(),
              ),
            );
          },
        ),
      ),
    );
  }
}

class SecondScreen extends StatelessWidget {
  const SecondScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        // toolbarHeight: 96,
        title: const Text('Other screen'),
        elevation: 3,
      ),
      body: const Center(
        child: Text(
          'Other screen content',
        ),
      ),
    );
  }
}

Issue Discussion
The correctly working expected result sample was made by using BackButtonIcon as leading icon in an IconButton. It gets the correct platform adaptive icon by default too and the state layer is correct, as was shown in the expected result.
class SecondScreen extends StatelessWidget {
  const SecondScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        // Leading icon used for correct style
        leading: IconButton(
          icon: const BackButtonIcon(),
          onPressed: () async {
            await Navigator.maybePop(context);
          },
        ),
        toolbarHeight: 96,
        title: const Text('Other screen'),
        elevation: 3,
      ),
      body: const Center(
        child: Text(
          'Other screen content',
        ),
      ),
    );
  }
}

The above uses the same BackButtonIcon widget as the implicit created one does, but doing it this way, via an IconButton works correctly.
If we insert the BackButton() widget that extends private _ActionButton(), so what the implicit creation uses, we do get the same issue as when using the implicit created button.
The ambient icon theme, which is correct, is not being applied to the BackButton() widget, for some reason that I did not dig into yet.
Flutter Doctor
Verified the issue on latest master, which was master, 3.23.0-14.0.pre.154
Doctor output
[✓] Flutter (Channel master, 3.23.0-14.0.pre.154, on macOS 14.5 23F79 darwin-arm64, locale en-US)
    • Flutter version 3.23.0-14.0.pre.154 on channel master at /Users/rydmike/fvm/versions/master
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 0b2a8e589e (13 hours ago), 2024-07-06 03:07:25 -0400
    • Engine revision d1ebc5fde6
    • Dart version 3.5.0 (build 3.5.0-323.0.dev)
    • DevTools version 2.37.0

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/rydmike/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.4)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15F31d
    • CocoaPods version 1.13.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)

[✓] IntelliJ IDEA Community Edition (version 2024.1.4)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin version 80.0.2
    • Dart plugin version 241.17890.8

[✓] VS Code (version 1.87.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.90.0

[✓] Connected device (5 available)
    • MrPinkPro (mobile)              • 74120d6ef6769c3a2e53d61051da0147d0279996 • ios            •
      iOS 17.5.1 21F90
    • iPhone 15 Pro Max (mobile)      • 056C5315-3EA8-44FE-BC53-441A08A340F9     • ios            •
      com.apple.CoreSimulator.SimRuntime.iOS-17-5 (simulator)
    • macOS (desktop)                 • macos                                    • darwin-arm64   •
      macOS 14.5 23F79 darwin-arm64
    • Mac Designed for iPad (desktop) • mac-designed-for-ipad                    • darwin         •
      macOS 14.5 23F79 darwin-arm64
    • Chrome (web)                    • chrome                                   • web-javascript •
      Google Chrome 126.0.6478.127

[✓] Network resources
    • All expected network resources are available.

• No issues found!

Investigated this issue today. This is caused by the underlying  ButtonStyleButton Icon Button in Material 3. The Material 2 IconButton doesn't use a  button style button.
It looks like a button style button expands to fill the space. This behavior can be observed with any button based on ButtonStyleButton.
Code sample

expand to view the code sample
import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      home: Material(
        child: Column(
          children: <Widget>[
            Expanded(
              child: FilledButton(
                onPressed: () {},
                child: const Text('B'),
              ),
            ),
          ],
        ),
      ),
    );
  }
}

The AppBar's leading widget fills the available space (height) because it's easy to align the widget within the space, e.g. with Center, but it's not possible enable filling the available space if the AppBar consumes it by default.

Then I looked into NavigationToolbar if it also does something similar, indeed the it makes the leading widget fill the whole space as Hans commented above so button ButtonStyleButton expands as expected.
This might be a relic of M2 era when we could get away with leading widget filling the whole vertical space and there was no ButtonStyleButton back then to reproduce this bug.

I will look into ways to make NavigationToolbar leading compatible with M3 style IconButton.

authors: HansMuller TahaTesser nikkivirtuoso parlough rydmike


text:
Migrate remaining internal iOS users of the Skia backend to Impeller

We'd like to prepare the ground work for removing Skia GPU from iOS applications.
To do that, we'll need to stop support --no-enable-impeller (tracked elsewhere, this is google3 only).

[ ] Flip the default (to match the 3P tool), i.e. explicitly required (the equivalent of) --no-enable-impeller.
[ ] Announce the changes.
[ ] Add and enforce an allow-list.
[ ] Move folks over (i.e. remove opt-outs).
[ ] Remove the ability entirely to use --no-enable-impeller.

I am starting on only the first part (flip the default), and the rest is subject to change (we're discussing it internally).
Note: This issue is locked as closed to flutter-hackers only.
/cc @chinmaygarde @dnfield @jonahwilliams @xster @CaseyHillers

Un-assigning as I'm working on more important issues at the moment.

source: gharchive/issue

repo: flutter/flutter

license_type: permissive

license_source: github-api


text:
RangeSlider : bad rounded value on 55

Steps to reproduce

Use a range slider with divisions param
Place slider on 55

Expected results
on 55, print 55
Actual results
on 55, print 55.00000000000001
Code sample
import 'package:flutter/material.dart';
/// Flutter code sample for [RangeSlider].
void main() => runApp(const RangeSliderExampleApp());
class RangeSliderExampleApp extends StatelessWidget {
const RangeSliderExampleApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
home: Scaffold(
appBar: AppBar(title: const Text('RangeSlider Sample')),
body: const RangeSliderExample(),
),
);
}
}
class RangeSliderExample extends StatefulWidget {
const RangeSliderExample({super.key});
@override
State createState() => _RangeSliderExampleState();
}
class _RangeSliderExampleState extends State {
RangeValues _currentRangeValues = const RangeValues(40, 80);
@override
Widget build(BuildContext context) {
return RangeSlider(
values: _currentRangeValues,
min: 0.0,
max: 100,
divisions: 20,
labels: RangeLabels(
_currentRangeValues.start.toString(),
_currentRangeValues.end.toString(),
),
onChanged: (RangeValues values) {
setState(() {
_currentRangeValues = values;
});
},
);
}
}
Screenshots or Video
No response
Logs
No response
Flutter Doctor output
[√] Flutter (Channel stable, 3.19.6, on Microsoft Windows [Version 10.0.22631.3593], locale en-BE)
• Flutter version 3.19.6 on channel stable at C:\src\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 54e66469a9 (6 weeks ago), 2024-04-17 13:08:03 -0700
• Engine revision c4cd48e186
• Dart version 3.3.4
• DevTools version 2.31.1
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
• Android SDK at C:\Users\dufgu\AppData\Local\Android\sdk
• Platform android-33, build-tools 33.0.0
• Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)
• All Android licenses accepted.
[√] Chrome - develop for the web
• Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.5.0)
• Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
• Visual Studio Community 2022 version 17.5.33414.496
• Windows 10 SDK version 10.0.22000.0
[√] Android Studio (version 2021.2)
• Android Studio at C:\Program Files\Android\Android Studio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.12+7-b1504.28-7817840)
[√] VS Code, 64-bit edition (version 1.89.1)
• VS Code at C:\Program Files\Microsoft VS Code
• Flutter extension version 3.90.0
[√] Connected device (3 available)
• Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.22631.3593]
• Chrome (web)      • chrome  • web-javascript • Google Chrome 125.0.6422.113
• Edge (web)        • edge    • web-javascript • Microsoft Edge 125.0.2535.67
[√] Network resources
• All expected network resources are available.
• No issues found!

@dufguix  while you can fix it by using  toStringAsFixed(0), method like : _currentRangeValues.start.toStringAsFixed(0)
However, this   shouldn't typically occur for such a simple integer conversion.

yes for sure. I imagine this behavior comes from the lerp function.
  // Returns a number between min and max, proportional to value, which must
  // be between 0.0 and 1.0.
  double _lerp(double value) => ui.lerpDouble(widget.min, widget.max, value)!;

Thanks for the report @dufguix,
This is a known issue being tracked at https://github.com/flutter/flutter/issues/39510. Closing this issue as a duplicate, so please follow up on it for further updates.

authors: IldySilva dufguix huycozy


text:
linux-25 is dead.

Type of Request
bug
Infrastructure Environment
LUCI, Github, Cocoon scheduler, Autosubmit, etc...
What is happening?
linux-25 is dead.

Steps to reproduce
Step 1:
Step 2:
..
Step n:
Expected results
I expect to see X when Y is finished.

Machine was hung and required power recycle to restart machine.


text:
MD5 compute hash file stronger slow in release mode

I download a 50MB file inside flutter application. Android OS.
I suprised that compute MD5 hash is very slow.
in debug mode : MD5 hash take 2 seconds.
in release mode (flutter build apk) : MD5 hash take 1 minute 15 seconds.
Steps to Reproduce
Code:
Future<String> calculateMD5SumAsync(String filePath) async
  {
    String ret = "";
    var file = new File(filePath);
    if (await file.exists())
    {
      try
      {

        var hash = await md5.bind(file.openRead()).first;
        ret = hex.encode(hash.bytes).toUpperCase();
      }
      catch (exception)
      {
        logger.severe("Unable to evaluate the MD5 sum :", exception);
        return null;
      }
    }
    else
    {
      logger.warning("'" + filePath + "' doesn't exits so unable to evaluate its MD5 sum.");
      return null;
    }
    return ret;

Logs
flutter analyze
Analyzing application...
No issues found! (ran in 5.3s)
flutter doctor -v
[√] Flutter (Channel beta, v0.11.13, on Microsoft Windows [version 10.0.17134.407], locale fr-FR)
    • Flutter version 0.11.13 at C:\flutter_sdk\flutter
    • Framework revision 58c8489fcd (2 days ago), 2018-11-29 19:20:18 -0500
    • Engine revision 7375a0f414
    • Dart version 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)

[√] Android toolchain - develop for Android devices (Android SDK 28.0.3)
    • Android SDK at C:\android-sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = C:\android-sdk
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b02)
    • All Android licenses accepted.

[√] Android Studio (version 3.1)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin version 26.0.1
    • Dart plugin version 173.4700
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b02)

[√] VS Code, 64-bit edition (version 1.29.1)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 2.21.0

[√] Connected device (1 available)
    • COL L29 • CLCDU18425007412 • android-arm64 • Android 8.1.0 (API 27)

• No issues found!

i try with other android device. i obtain same issue

@Thetyne is md5 from package:crypto or do you use some other package?
Is flutter run --release --target-platform android-arm64 any faster?

yes, i use md5 from package crypto.
crypto:
dependency: transitive
description:
name: crypto
url: "https://pub.dartlang.org"
source: hosted
version: "2.0.6"

Yes, with  the command "flutter run --release --target-platform android-arm64", the MD5 copute hash is fast.
Do i need always compile with arm64?

Thanks for checking!

Do i need always compile with arm64?

Unfortunately if you are targeting older phones you can't limit yourself to just ARM64.
I just wanted to verify that this is the same issue. I think AOT performance on this sort of code on ARM32 should be considerably better with HEAD Dart (not yet rolled into Flutter). I will check tomorrow.
However it is still far from perfect - further improvements are tracked in https://github.com/dart-lang/sdk/issues/34473

Ok, i am waiting for it

@Thetyne the Dart has not been rolled in Flutter because those rolls were suspended at least until Dec 10th. I will update this issue when you can try again.

@mraleph ok, thanks for this response

It seems this package is also affected by the same issue: https://github.com/Erly/dbcrypt

The original problem with JIT vs AOT discrepancy has been solved by @sjindel-google
» flutter run --debug --target-platform android-arm
I/flutter (10031): START {{{
I/flutter (10031): 5 mbytes hashed to 006a88ed7d5826af90d38dba4666fd89
I/flutter (10031): }}} DONE IN 570 ms.

» flutter run --release --target-platform android-arm
I/flutter (10145): START {{{
I/flutter (10145): 5 mbytes hashed to 006a88ed7d5826af90d38dba4666fd89
I/flutter (10145): }}} DONE IN 530 ms.

Let us know if things are still not fast enough.

authors: NBTX Thetyne mraleph


text:
Codelab + iOS Simulator: giant white screen looks like app is broken?

Hi! Working with a new Flutter user here. We had the iOS simulator running, and then ran the codelab project. Our iOS simulator screen was all white, which lead us to think we ran into a bug of some sort. Turns out, everything was working just fine! However, the default iOS simulator runs at 100%, and the initial codelab code has nothing but white in the middle of the screen. So all we saw was white. :)
Workaround: shrink iOS simulator to 50%, so you can see the whole screen, and thus notice the app is working.
I don't think we can expect everyone to start with 50% on their iOS simulator, so I'm wondering if we can put something in the middle of the codelab app? Or, not sure if we can detect that the simulator is running at 100% and suggest the user scale their simulator. But, looking at a giant white screen is a little confusing. :)
Thanks!

cc @qchong @collinjackson for ideas

In at least one of our instructions we recommend the user scale the simulator.

ah, good! Maybe we should bold it? :) To be fair, we weren't strictly looking at the codelab docs when we ran flutter run.

It's pretty clearly highlighted in a callout box in 'Step 4: Run your app'
https://codelabs-preview.appspot.com/?file_id=1esS56X44Nfo5mfVHOkV9Xh5IWbOmfzS0CD59wnjquEc#3
.
[image: Inline image 1]
On Tue, Mar 8, 2016 at 1:57 PM, Seth Ladd notifications@github.com wrote:

ah, good! Maybe we should bold it? :) To be fair, we weren't strictly
looking at the codelab docs when we ran flutter run.
—
Reply to this email directly or view it on GitHub
https://github.com/flutter/flutter/issues/2500#issuecomment-193985305.

--
Quddus Chong | Technical Writer - Turquoise | quddusc@google.com

Thanks for confirming. I'll close for now. We admittedly were not looking at the codelab docs at this point. We skipped ahead.

authors: eseidelGoogle qchong sethladd