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.
