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/e239e9ef-4183-42a5-95dd-f76a1a953021n%40googlegroups.com.
