Skip to content

Userfeedback in date picker throws stacktrace with flutter in modular. #228

Description

@FlutterIssues

Issue by ksimbili
Monday Oct 26, 2015 at 17:47 GMT
Originally opened as https://github.com/flutter/engine/issues/1787


We are running date picker with versions
mojo-0.3.0
mojo_services-0.4.0
mojom-0.2.3
sky_services-0.0.41
sky_engine-0.0.41
flutter-0.0.11

Clicking on date in date picker throws the following stack.

[1026/123659:ERROR:dart_error.cc(16)] Unhandled exception:
'/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/sky_services/activity/activity.mojom.dart': Failed assertion: line 1557: '_proxyImpl.isBound' is not true.
#0      _AssertionError._throwNew (dart:core-patch/errors_patch.dart:27)
#1      _ActivityProxyCalls.getUserFeedback (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/sky_services/activity/activity.mojom.dart:1557)
#2      _initUserFeedbackProxy (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/services/activity.dart:34)
#3      _userFeedbackProxy (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/services/activity.dart:38)
#4      _userFeedbackProxy (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/services/activity.dart:38)
#5      userFeedback (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/services/activity.dart:39)
#6      userFeedback (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/services/activity.dart:39)
#7      _DatePickerState._handleDayChanged (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/material/date_picker.dart:63)
#8      DayPicker.build.<anonymous closure> (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/material/date_picker.dart:246)
#9      TapGestureRecognizer.handlePrimaryPointer (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/gestures/tap.dart:26)
#10     PrimaryPointerGestureRecognizer.handleEvent (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/gestures/recognizer.dart:108)
#11     PointerRouter.route (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/gestures/pointer_router.dart:45)
#12     FlutterBinding.handleEvent (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/rendering/binding.dart:246)
#13     FlutterBinding.dispatchEvent (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/rendering/binding.dart:240)
#14     FlutterBinding._handlePointerInputEvent (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/rendering/binding.dart:225)
#15     FlutterBinding._handleEvent (/usr/local/google/home/ksimbili/tq/modular/src/out/android_Debug/gen/dart-pkg/packages/flutter/src/rendering/binding.dart:183)

Activity

  1. FlutterIssues commented on Nov 9, 2015

    @FlutterIssues
    Author

    Comment by abarth
    Tuesday Oct 27, 2015 at 04:08 GMT


    @zanderso I think we want the bindings to silently swallow messages when the remote end of a mojo pipe closes. That's what the C++ bindings do. That makes the system more loosely coupled in case one side crashes or didn't implement the expected interface. Should I file this bug again in the mojo issue tracker?

  2. FlutterIssues commented on Nov 9, 2015

    @FlutterIssues
    Author

    Comment by zanderso
    Tuesday Oct 27, 2015 at 05:10 GMT


    Ah, yah. That assert is wrong. Under the current design what it should do is complete the response future with an error if a response is expected, or throw an error if no response is expected.

    What I can do instead is complete the response future with null if a response is expected, and just return if no response is expected, and audit to make sure we're being consistent about that.

    I wonder if it might make sense to add an option to Proxy to turn the more noisy failures back on.

    If you could file as well on the Mojo side that would be great.

  3. FlutterIssues commented on Nov 9, 2015

    @FlutterIssues
    Author

    Comment by abarth
    Tuesday Oct 27, 2015 at 05:20 GMT


    @zanderso Done.

  4. abarth commented on Nov 18, 2015

    @abarth
    Contributor

    I believe this is now fixed. Please re-open if this still occurs.

  5. added
    frameworkflutter/packages/flutter repository. See also f: labels.
    and removed on Feb 2, 2017
  6. github-actions commented on Sep 5, 2021

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

  7. locked as resolved and limited conversation to collaborators on Sep 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    dependency: fuchsiaFuchsia team may need to help usframeworkflutter/packages/flutter repository. See also f: labels.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions