Ok, thank you for your response. I understand that taking a screenshot is wrong. So why obfuscate the underlying form in the first place? Why making things like that the WebView is blank? Why not just leave a greyed-out transparency around the Dialog? I am asking just out of my own technical curiosity. I will check the other suggested variants out. Thank you. Regards
Il giorno martedì 22 dicembre 2020 alle 19:19:09 UTC+1 Steve Hannah ha scritto: > Yes you can "take a screenshot" of webviews in most platforms, but they > are generally very "slow" and aren't practical when you're trying to make a > seamless transition to a dialog - they cause jankiness. > > If you want to mix lightweight components with native components, it is > better to avoid Dialog, and use InteractionDialog or its variants (e.g. > ToastBar, Sheet). > > > On Tue, Dec 22, 2020 at 2:47 AM 'P5music' via CodenameOne Discussions < > [email protected]> wrote: > >> I am curious about whether the problems you refer to are on all supported >> platforms or just on some of them. >> Are you saying that for cross-platform coherence? Or is it like that it >> would work on Android and iOS? >> I think that Android and iOS are the main platforms. If something doesn't >> work on all platform, but does on Android and iOS, that should not be a >> reason to dismiss such a paramount function or not try to implement. >> It is just my opinion and It may not make sense >> but >> I read on StackOverflow many questions on "taking a screenshot" of the >> WebView with no issues at all. I do not understand where the problem is on >> Android and iOS. >> Regards >> >> Il giorno martedì 22 dicembre 2020 alle 03:49:27 UTC+1 Shai Almog ha >> scritto: >> >>> Native peer and browser component behavior is very platform dependent. >>> It's possible that CEF impacted that but what matters is the device >>> behavior not the simulator behavior. Showing a Dialog on top of a browser >>> component won't work well on the devices. >>> >>> On Monday, December 21, 2020 at 8:35:59 PM UTC+2 P5music wrote: >>> >>>> Sorry but I cannot find anything in that file. Maybe you may point me >>>> to the exact method where all it happens. >>>> >>>> However I have to say that I still can run the test application I >>>> created some weeks ago for the "BrowserComponent-blocking dialog" and in >>>> that application the BrowserComponent is not made blank at all when the >>>> Dialog appears. >>>> I think I have not updated that project as I did for my main project, >>>> maybe it has old libraries indeed. >>>> So I suspect that the blank-BC issue was recently introduced. >>>> Do you confirm? >>>> What can be done to revert to the old way, without reverting to the >>>> blocking behaviour? >>>> >>>> I think it is not acceptable in general that a Dialog makes the >>>> BrowserComponents blank. A lot of apps could be impacted. >>>> Regards >>>> >>>> Il giorno lunedì 21 dicembre 2020 alle 03:07:31 UTC+1 Shai Almog ha >>>> scritto: >>>> >>>>> We don't do it for browser component since that doesn't work well. But >>>>> the code implementing BrowserComponent is there. >>>>> The screenshot logic is in PeerComponent.java. >>>>> >>>>> On Sunday, December 20, 2020 at 4:17:30 PM UTC+2 P5music wrote: >>>>> >>>>>> Do you know where is the code that takes the screenshot of components >>>>>> when a dialog has to be displayed? >>>>>> I cannot find it. >>>>>> Thanks >>>>>> >>>>>> Il giorno domenica 20 dicembre 2020 alle 02:59:07 UTC+1 Shai Almog ha >>>>>> scritto: >>>>>> >>>>>>> IOSNative.m under IOSPort/native in >>>>>>> https://github.com/codenameone/CodenameOne/ >>>>>>> >>>>>>> On Saturday, December 19, 2020 at 5:22:02 PM UTC+2 P5music wrote: >>>>>>> >>>>>>>> Please let me know where that code is. >>>>>>>> Regards >>>>>>>> >>>>>>>> Il giorno venerdì 18 dicembre 2020 alle 05:54:57 UTC+1 Shai Almog >>>>>>>> ha scritto: >>>>>>>> >>>>>>>>> I didn't work on that but feel free to look at the code. >>>>>>>>> >>>>>>>>> On Thursday, December 17, 2020 at 11:16:25 AM UTC+2 P5music wrote: >>>>>>>>> >>>>>>>>>> I searched StackOverflow and it seems that your security concerns >>>>>>>>>> simply do not exist. So the WebView screenshot can be easily taken, >>>>>>>>>> with >>>>>>>>>> Objective-C or Swift, for iOS, and Java for Android. >>>>>>>>>> Furthermore it is the app itself taking a screenshot of one of >>>>>>>>>> its own view, so there's no way it can be a security flaw. >>>>>>>>>> Maybe you mean that some of the supported platforms of Codename >>>>>>>>>> cannot do that? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Il giorno giovedì 17 dicembre 2020 alle 04:37:55 UTC+1 Shai Almog >>>>>>>>>> ha scritto: >>>>>>>>>> >>>>>>>>>>> It's inconsistent on devices. That's the biggest problem. >>>>>>>>>>> We can't grab a screenshot of a browser component on the device >>>>>>>>>>> due to technical/security concerns so we can't implement dialog >>>>>>>>>>> properly >>>>>>>>>>> when a browser component is below it. >>>>>>>>>>> >>>>>>>>>>> On Wednesday, December 16, 2020 at 1:29:52 PM UTC+2 P5music >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I reverted my code back to using Dialogs instead of >>>>>>>>>>>> InteractionDialogs. The code is much simpler and readable. I see >>>>>>>>>>>> that now >>>>>>>>>>>> the Dialog does not block the BrowserComponents in the underlying >>>>>>>>>>>> layout, >>>>>>>>>>>> so it can be used. >>>>>>>>>>>> >>>>>>>>>>>> [I was said, if I am not wrong, that when the Dialog is >>>>>>>>>>>> displayed it is like another form is shown, unlike the >>>>>>>>>>>> InteractionDialog. >>>>>>>>>>>> And a sort of freezed image of the previous screen is displayed, >>>>>>>>>>>> it is sort >>>>>>>>>>>> of fake. No problems for me. >>>>>>>>>>>> When the Dialog is dismissed the BC comes back. It seems that >>>>>>>>>>>> it is just displayed again and not reloaded (I see no onload >>>>>>>>>>>> event). This >>>>>>>>>>>> is good. >>>>>>>>>>>> My advice is to perfection Dialog and not InteractionDialog, >>>>>>>>>>>> because with ID mouse events leak onto the underlying form and >>>>>>>>>>>> have to be >>>>>>>>>>>> handled, as also has the back command.] >>>>>>>>>>>> But >>>>>>>>>>>> I see that while the Dialog is displayed, the underlying >>>>>>>>>>>> BrowserComponents are empty and all white (although greyed out). >>>>>>>>>>>> When the Dialog is displayed I see that the other UI components >>>>>>>>>>>> are displayed with their content, so why just the BrowserComponent >>>>>>>>>>>> is >>>>>>>>>>>> blank? Maybe this is a bug and it was forgotten to make its >>>>>>>>>>>> "screenshot", >>>>>>>>>>>> like for other components? >>>>>>>>>>>> Is it so also on devices? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, regards >>>>>>>>>>>> >>>>>>>>>>>> -- >> You received this message because you are subscribed to the Google Groups >> "CodenameOne Discussions" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/codenameone-discussions/891d09e5-44b6-4b70-a901-64eef80e5dacn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/codenameone-discussions/891d09e5-44b6-4b70-a901-64eef80e5dacn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Steve Hannah > Software Developer > Codename One > http://www.codenameone.com > -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/967c3666-4d02-4e8d-8826-5c65c167d9b5n%40googlegroups.com.
