Skip to content

DevTools pages create bad URLs when the base contains ?wasm=true #5365

Closed

Description

@kenzieschmoll

Here's a URL that was produced by triggering the "Open DevTools in the browser" action:

http://127.0.0.1:9100/?wasm=true#?cacheBust=dart-3.7.0-188.0.dev-flutter-3.27.0-1.0.pre.669&ide=VSCode&ideFeature=command&theme=dark&uri=ws%3A%2F%2F127.0.0.1%3A60408%2FZJPl0ajZ8IM%3D%2Fws&page=home

The cacheBust param and all following are tacked on to the end instead of adding to the existing query parameters like wasm=true. Additionally, we shouldn't need the # sign which may be getting added by VS code.

Activity

  1. DanTup commented on Dec 6, 2024

    @DanTup
    Member

    @kenzieschmoll how would I reproduce this? Where is the wasm=true coming from? Is it being added in the value that comes in the server-started json event?

    If so, I think we currently assume the URL is just a "base url" because we may also append page names like /inspector.

    We can change this to parse the URI and insert the parts at the correct place, but it may be worth checking whether IntelliJ has similar assumptions that will need updating too (@jwren fyi).

  2. added this to the v3.104.0 milestone on Dec 6, 2024
  3. changed the title [-]Open DevTools In the Browser creates bad URL[/-] [+]DevTools pages create bad URLs when the base contains `?wasm=true`[/+] on Dec 6, 2024
  4. kenzieschmoll commented on Dec 6, 2024

    @kenzieschmoll
    Author

    If you open DevTools from VS code (as long as you are on flutter beta or master), and then open the DevTools settings menu, you'll see a check box to enable WASM. This will store a setting to DevTools preferences. The next time you open DevTools in the browser from VS code, the wasm=true parameter should be applied.

    The wasm parameter is set in the DevTools flutter_bootstrap.js logic: https://github.com/flutter/devtools/blob/master/packages/devtools_app/web/flutter_bootstrap.js/#L60

    And it is set when the preference changes: https://github.com/flutter/devtools/blob/master/packages/devtools_app/lib/src/shared/preferences/preferences.dart/#L176

    For the issue I was hitting, I already had the preference enabled, so it was most getting set from the bootstrap logic.

  5. DanTup commented on Dec 9, 2024

    @DanTup
    Member

    I can reproduce this - it happens when we ask the DevTools server to open DevTools in the browser. It seems to have some code that still assumes we're using the # fragment for the URL. I'll update it and verify it fixes this.

  6. DanTup commented on Dec 9, 2024

    @DanTup
    Member
  7. modified the milestones: v3.104.0, v3.106.0 on Dec 19, 2024
  8. modified the milestones: v3.106.0, v3.104.0 on Dec 30, 2024
  9. DanTup commented on Jan 8, 2025

    @DanTup
    Member

    This was fixed by dart-lang/sdk@acf43c7

  10. added
    relies on sdk changesSomething that requires changes in the Dart/Flutter SDK to ship before it will become available
    on Jan 8, 2025
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

    in devtoolsRelates to integration with Dart/Flutter DevToolsis bugrelies on sdk changesSomething that requires changes in the Dart/Flutter SDK to ship before it will become available

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions