You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Disclaimer: As my time is currently severely limited, this report might be lacking some nicer or more appropriate phrasings and is likely not as polished as I would like it to be. I am sorry for this. This is also the reason why I am, at least at the moment, not able to provide a fix by myself and open a pull request.
Describe the bug
In bfe7ce3 all location usages were replaced with uri.toString() calls.
However, this broke the deep linking feature and possibly even more.
Now when triggering a deep link the link gets appended to the root URI (/), which results in weird and incorrect route URLs.
Example:
App is in route /.
User triggers Deep Link example://app/settings
Behaviors before and after the mentioned commit:
Before: App routes to /setttings.
After: App routes to /example://app/settings.
This happens because the absolute path check is broken in at leastUtils#maybeAppend, however, a quick search through the code found more possible breakages due to the above-mentioned replacement action.
Beamer version: (e.g. v0.14.1, master, ...)
v1.6.0
To Reproduce
Steps to reproduce the behavior:
Have a Flutter app that is configured for Deep Links.
Trigger a deep link.
Watch as the route URI is mangled with the deep link URI.
Expected behavior
Correctly checking for an absolute URI, so the deep link isn't incorrectly appended.
Device (please complete the following information):
Not applicable.
Additional context
The following code has been changed to just check if the whole URI starts with a slash instead of, as before, just the location (aka. the path part of a URI).
As the old check only considered the path part, simply switching to uri.toString() broke it for every URI that has a scheme and/or authority part (which is now possible due to the new type):
Therefore, the new absolute URI (example://app/settings) is simply appended to the existing URI (/)
Possible Fix
This seems to be a usable fix for this exact method (there are potentially more needing a similar fix) that allows deep links to work again, at the very least, in my short use case test:
Note: This would still be mishandling URIs that are not absolute but contain a scheme or authority, however, I am not sure if such a URI would be even valid!
The text was updated successfully, but these errors were encountered:
Note
Disclaimer: As my time is currently severely limited, this report might be lacking some nicer or more appropriate phrasings and is likely not as polished as I would like it to be. I am sorry for this. This is also the reason why I am, at least at the moment, not able to provide a fix by myself and open a pull request.
Describe the bug
In bfe7ce3 all
location
usages were replaced withuri.toString()
calls.However, this broke the deep linking feature and possibly even more.
Now when triggering a deep link the link gets appended to the root URI (
/
), which results in weird and incorrect route URLs.Example:
/
.example://app/settings
/setttings
./example://app/settings
.This happens because the absolute path check is broken in at least
Utils#maybeAppend
, however, a quick search through the code found more possible breakages due to the above-mentioned replacement action.Beamer version: (e.g.
v0.14.1
,master
, ...)v1.6.0
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Correctly checking for an absolute URI, so the deep link isn't incorrectly appended.
Device (please complete the following information):
Not applicable.
Additional context
The following code has been changed to just check if the whole URI starts with a slash instead of, as before, just the location (aka. the
path
part of a URI).As the old check only considered the
path
part, simply switching touri.toString()
broke it for every URI that has ascheme
and/orauthority
part (which is now possible due to the new type):beamer/package/lib/src/utils.dart
Lines 250 to 264 in bfe7ce3
Therefore, the new absolute URI (
example://app/settings
) is simply appended to the existing URI (/
)Possible Fix
This seems to be a usable fix for this exact method (there are potentially more needing a similar fix) that allows deep links to work again, at the very least, in my short use case test:
Note: This would still be mishandling URIs that are not absolute but contain a
scheme
orauthority
, however, I am not sure if such a URI would be even valid!The text was updated successfully, but these errors were encountered: