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/CAGOYrKUPQL4DrGgWqUXkWbwk3N7U5C2B3eHbO70Vj6wVQzv_0Q%40mail.gmail.com.
