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
There seems to be a regression in 1.5.8 that prevents customs fragments from being interacted with if they have canGoForward set to false.
I have a custom fragment that has canGoForward overwritten with a boolean to return false until a condition is met in the custom fragment.
Tapping anywhere on the screen dismisses the keyboard and all touch events start getting eaten.
If you follow the code in the debugger, you'll eventually see that notifyDatasetChanged() is called as soon as you tap on the screen, leading me to believe that the following commit is the offending commit.
My guess is the intercept touch code is not working as expected for custom fragments, or that the locking logic isn't quite right. If you have a hard time reproducing I can try and create a sample project.
Heres a gif of what it looks like in practice.
The text was updated successfully, but these errors were encountered:
kevinthecity
changed the title
Regression 1.5.8 - Recreate fragments when swiping is lock
Regression 1.5.8 - Recreate fragments when swiping is locked
Sep 3, 2016
Yeah, this is a pretty major bug. Same thing happening here. I am guessing that commit 4d5af6d was the culprit. This is way worse than the previous issue as it totally renders my login setup useless.
Here's a little video of more glitched behaviour. Working on a pull request now.
Keep up the great work!
Edit: I see that kevinthecity has already noted that.
There seems to be a regression in 1.5.8 that prevents customs fragments from being interacted with if they have
canGoForward
set to false.canGoForward
overwritten with a boolean to return false until a condition is met in the custom fragment.If you follow the code in the debugger, you'll eventually see that notifyDatasetChanged() is called as soon as you tap on the screen, leading me to believe that the following commit is the offending commit.
4d5af6d
My guess is the intercept touch code is not working as expected for custom fragments, or that the locking logic isn't quite right. If you have a hard time reproducing I can try and create a sample project.
Heres a gif of what it looks like in practice.
The text was updated successfully, but these errors were encountered: