io.Platform.localeName is "null" (the string) on iOS simulator

[SteveAlexander]

On today's master, I'm seeing io.Platform.localeName is "null" — that is, the string "null" excluding the quotes.

Time machine is still broken with this, as it (reasonably, I think) expects it to be a valid locale string xx_YY or an actual null.

See also #23241

See also Dana-Ferguson/time_machine#10

$ flutter doctor -v
[✓] Flutter (Channel master, v0.10.2-pre.53, on Mac OS X 10.13.6 17G2307, locale en-GB)
    • Flutter version 0.10.2-pre.53 at /Users/steve/code/flutter
    • Framework revision 549e8e07c6 (15 hours ago), 2018-10-24 14:41:16 -0700
    • Engine revision 2586e94122
    • Dart version 2.1.0-dev.7.1.flutter-45f9462398

[✓] Android toolchain - develop for Android devices (Android SDK 28.0.1)
    • Android SDK at /Users/steve/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.1
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 10.0)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 10.0, Build version 10A255
    • ios-deploy 2.0.0
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 26.0.1
    • Dart plugin version 173.4700
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)

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

[✓] Connected device (1 available)
    • iPhone X • EF563F7A-675E-4CF8-AFFF-E518AF44A1F2 • ios • iOS 12.0 (simulator)

• No issues found!

[tvolkert]

@GaryQian can you have a look?

[zoechi]

#24481 looks like it is supposed to fix this.

Is this normal?

This from above

[✓] Flutter (Channel master, v0.10.2-pre.53, on Mac OS X 10.13.6 17G2307, locale en-GB)
    • Flutter version 0.10.2-pre.53 at /Users/steve/code/flutter
    • Framework revision 549e8e07c6 (15 hours ago), 2018-10-24 14:41:16 -0700

vs from my local setup

[✓] Flutter (Channel beta, v0.11.9, on Mac OS X 10.14.1 18B75, locale en-AT)
    • Flutter version 0.11.9 at /Users/zoechi/flutter/flutter
    • Framework revision d48e6e433c (5 days ago), 2018-11-20 22:05:23 -0500
    • Engine revision 5c8147450d
    • Dart version 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)

where a 5 days old beta is v0.11.9, while the 15h old master is v0.10.2-pre.53

[tvolkert]

@SteveAlexander it looks like you're not synced to the latest master. 549e8e07c6 is over a month old. If you flutter upgrade are you still on that revision?

[SteveAlexander]

flutter upgrade
Upgrading Flutter from /Users/steve/code/flutter...
Already up to date.

Upgrading engine...
Already up-to-date.

Flutter 0.11.10-pre.3 • channel master • https://github.com/flutter/flutter.git
Framework • revision 06e4ccc9a9 (32 hours ago) • 2018-11-25 04:55:23 -0500
Engine • revision 99e73d8c64
Tools • Dart 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)

Running "flutter packages upgrade" in am-protasis...        11.4s

Running flutter doctor...
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel master, v0.11.10-pre.3, on Mac OS X 10.13.6 17G3025, locale en-GB)
[✓] Android toolchain - develop for Android devices (Android SDK 28.0.1)
[✓] iOS toolchain - develop for iOS devices (Xcode 10.1)
[✓] Android Studio (version 3.1)
[✓] VS Code (version 1.29.1)
[✓] Connected device (1 available)

• No issues found!

[tvolkert]

Thanks! doctor is now reporting that you're on the latest revision, so now, on that revision, do you still see this bug?

[yjbanov]

Some of our internal customers are observing this bug too. I think we should fix it asap.

[SteveAlexander]

yes, I'm still seeing that io.Platform.localeName returns "null"

[GaryQian]

We recently changed the locale system to have a preferred locale of null before it receives information from the OS (before, we always said 'en_US', which is misleading). It is seems that the code in io.Platform is not passing the locale through the locale resolution stack (which should sanitize the null), therefore leaving it null for a brief period before the OS has a chance to pass the locale to flutter/dart.

[tvolkert]

I think returning null makes sense.

[SteveAlexander]

Return a Future, as the real locale will show up eventually?

[GaryQian]

flutter/engine#6936

A future may not work here, as there is no guarantee that the locale will ever show up. There are platforms where there are no locales at all.

On Flutter-side, I can return null instead of calling toString on the null locale. Then, hand it off to dart io.Platform, which will resolve it to the _localeName() call (see platform_impl.dart). At that point, the dart fallback system should be able to handle it.

[yjbanov]

A Future might technically work. We have three situations:

• we have a locale
• we don't have a locale yet
• we will never have a locale

So if we were to use a Future-based API, we can cover all the cases as follows:

• SynchronousFuture carrying a Locale object indicates we already have a locale
• An async Future indicates that we are working on getting a locale
• Any Future that evaluates to null indicates we will never have a locale

Having said that we already have onLocaleChanged and I think it would be great if we found a way to reuse that mechanism. Adding another Future-based mechanism if fraught with complexity and race conditions.

[GaryQian]

In any case, I think from flutter's perspective, we do not directly control the io.Platform.localeName() function. That is Dart's. We do supply the _localeClosure() which was providing an unexpected string value, when it should have returned null to allow io.Platform.localeName() to continue with its own fallback mechanism.

In terms of the scope of this bug, I believe making sure _localeClosure() returns null is enough to allow the rest of the existing Dart logic to handle this case. localeName() already checks for the case of _localeClosure() returning null.

[github-actions]

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.