BrowserComponent becomes blank when a Dialog is displayed

[P5music]

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

[Shai Almog]

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.

[P5music]

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?

[Shai Almog]

I didn't work on that but feel free to look at the code.

[P5music]

Please let me know where that code is.

Regards

[Shai Almog]

IOSNative.m under IOSPort/native in https://github.com/codenameone/CodenameOne/

[P5music]

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

[Shai Almog]

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.

[P5music]

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

[Shai Almog]

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.

[P5music]

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

[Steve Hannah]

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).

--
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 codenameone-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/891d09e5-44b6-4b70-a901-64eef80e5dacn%40googlegroups.com.

--

Steve Hannah

Software Developer

Codename One

http://www.codenameone.com

[P5music]

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

[Steve Hannah]

So why obfuscate the underlying form in the first place? Why making things like that the WebView is blank?

Dialog IS a Form.  Only one Form is displayed at a time.  To create the effect that the previous form is present, we take a screenshot of the form, and display it as a background to the Dialog.

An InteractionDialog is NOT a Form.  It is a component that is rendered in the current form's hierarchy.

This is the fundamental distinction, and all other differences in behaviour stem from this.

[P5music]

Thank you for your response.

I wonder if it is possible to have an alternate Dialog constructor with a boolean parameter

Dialog(boolean wantsToTakeWebViewScreenshot)

{

...

}

The WebView screenshot could be to added the other components' screeshot list, optionally.

Optionally means that there is a caveat for the developer.

I think that the doing the screenshot for the WebView does not take so long, at least for my application. 

So I could test it on common devices or emulators, and the slowest ones could be declared not compatible if the waiting time is really too much.

What about this?

[Shai Almog]

That's not a practical solution. The screenshot process happens very frequently.

[P5music]

Ok, now I understand how you implemented that. As it seems, you try to have a real-time sampling of the existing UI components of the underlying form, 

that are alive "somewhere" in memory.

I thought you make one screenshot. For me a single static screenshot would be enough, but I see that it can be not practical for other developers, so they would not use the Dialog at all in presence of a BrowserComponents (useful for maps, instructions viewers, payment screens, and so on).

But at this point I think you have the possibility to create a method like:

WebView.setScreenshotFramerate(int value)

where value is 0 for static refresh

10 is ten per second, and so on.

There is a caveat for the developer who has to test it on real devices if necessary and create a table of values 

or, as in my case, just put 0 for a simple solution.

0 corresponds to a convenience screenshot not to see the BC become blank. In my app this means that almost all the UI disappears. And so it is also where a map is displayed, or an on-line payment is going on, for example when the security code has to be entered over the credit-card webpage.

Regards

[Shai Almog]

That wouldn't fit and would again create a bad UX for the end user.