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/bf218f8c-e044-4cf2-a207-f5bafe01af0fn%40googlegroups.com.
