composer hideOverlay isModal - no touch blocker during transition?

Solar2D Composer
#1

i wish the bug submission were searchable…

basically trying to figure out if this is a known issue, or maybe just some misunderstanding on my part, before i go to the effort of crafting a bug submittal…

scenario: you call showOverlay and have isModal=true, so that a “touch-blocker” is added underneath, so that no touch/tap events can make it through to the parent scene.  fine so far.  but then call hideOverlay (with a nice long time so that you can experiment during the transition) and the touch-blocker is *immediately* removed, not at the end of the transition.  Ideally, I’d not want any events leaking through til overlay is completely gone, but that’s not happening.

so you can interact with the parent scene during the hide transition, including potentially even pushing the button that called showOverlay to begin with!  and this causes all sorts of problems.  fe, you can “interrupt” the hide transition by starting a whole new “show” transition, the two “fight” for control, though the later show transition usually wins, and it appears the hide transition isn’t fully cancelled because you can get really weird sequences of events.  sprinkle print statements around and you’ll see show-will + show-did as expected, followed by a late destroy lingering from the hide, followed immediately by another show-did.  (what? show-did? on a supposedly just-destroyed scene!?)

You can even get the whole system to appear “locked up” – where the touch-blocker remains after an interrupted-hide-new-show-then-delete, overlay scene is not visible, but parent scene still covered by active touch-blocker.

(aside/separate feature-request:  i also wish we had “access” to that internal touch-blocker so that we could style it – it’d be handy to be able to SEE it when present)

Q:  i thought touch/tap events were meant to be fully blocked during ALL transitions??

thx, cheers

#2

IMHO it’s doing what it says it should. Maybe you want it to block for the lifetime of the overlay, whether fully transitioned or not, but some people might not. I guess it’s something you have to take as an assumption which doesn’t get picked up enough as to warrant any further work.

You could submit a feature request and/or bug (if you consider it one) to have the option to make the transition period modal.

For now, it’s not that hard to just add an extra interaction blocker below - the isModal flag is really just a convenience anyway.

#3

maybe i should clarify, because composer appears to have two separate touch-blockers…

the isModal one appears to work fine, blocking touches while the overlay is in place, no issues there.

the “during transition” one (which is also used during normal non-overlay scene transitions) is only in effect during showOverlay, and is NOT in effect during hideOverlay – that is what appears to be a bug.

#4

Personally, I agree.  The touch-block should exist for the entire lifetime of the overlay including transitions.  I disable my touch handlers on the parent scene on overlays “just in case” and have never had any issues

#5

Yep, and thanks, I’ve been thinking I’ll need to do something of that sort if this isn’t considered a “flaw” in Composer and corrected.

[tooting my own horn]

For my own work, I use my own scene manager, which supports multiple simultaneous overlays, or stacked modality (a modal dialog itself opening a modal dialog), and it handles all the necessary modal and during-transition touch blockers just fine, sparing me from having to explicitly disable the listeners.  I think that was the intent of Storyboard/Composer’s touch blockers too, but it’s not implemented rigorously enough for me to rely on.

[end of tooting]

But for this project, it’s gotta be Composer, so I’m struggling with it.

Am prepping for a bug submission, attached for anyone curious.  (steps to reproduce as comments inside main.lua)

#6

Go ahead and file the bug. You will need to email support@coronalabs.com since we are changing our bug tracking system.  It will need a complete project (main.lua, build.settings, config.lua and any assets needed to build and run the app) that demos the problem. 

Rob

#7

This should be fixed in daily build 2017.3119 and later.

Rob

#8

IMHO it’s doing what it says it should. Maybe you want it to block for the lifetime of the overlay, whether fully transitioned or not, but some people might not. I guess it’s something you have to take as an assumption which doesn’t get picked up enough as to warrant any further work.

You could submit a feature request and/or bug (if you consider it one) to have the option to make the transition period modal.

For now, it’s not that hard to just add an extra interaction blocker below - the isModal flag is really just a convenience anyway.

#9

maybe i should clarify, because composer appears to have two separate touch-blockers…

the isModal one appears to work fine, blocking touches while the overlay is in place, no issues there.

the “during transition” one (which is also used during normal non-overlay scene transitions) is only in effect during showOverlay, and is NOT in effect during hideOverlay – that is what appears to be a bug.

#10

Personally, I agree.  The touch-block should exist for the entire lifetime of the overlay including transitions.  I disable my touch handlers on the parent scene on overlays “just in case” and have never had any issues

#11

Yep, and thanks, I’ve been thinking I’ll need to do something of that sort if this isn’t considered a “flaw” in Composer and corrected.

[tooting my own horn]

For my own work, I use my own scene manager, which supports multiple simultaneous overlays, or stacked modality (a modal dialog itself opening a modal dialog), and it handles all the necessary modal and during-transition touch blockers just fine, sparing me from having to explicitly disable the listeners.  I think that was the intent of Storyboard/Composer’s touch blockers too, but it’s not implemented rigorously enough for me to rely on.

[end of tooting]

But for this project, it’s gotta be Composer, so I’m struggling with it.

Am prepping for a bug submission, attached for anyone curious.  (steps to reproduce as comments inside main.lua)

#12

Go ahead and file the bug. You will need to email support@coronalabs.com since we are changing our bug tracking system.  It will need a complete project (main.lua, build.settings, config.lua and any assets needed to build and run the app) that demos the problem. 

Rob

#13

This should be fixed in daily build 2017.3119 and later.

Rob

#14

What about other transitions ? I just found that if I set a button disabled and then start a transition, the touch is still handled. It means setEnabled(false) did not work…
build 2021.3640