We had a bit of an internal discussion on this. The issue Steve worked around was related to the FX browser which is no longer applicable. So we decided to remove that as there might be performance implications.
On Thursday, November 26, 2020 at 12:00:21 PM UTC+2 P5music wrote: > My app is very simple so the BC-blocking issue is not very profound in > terms of threading I think. > I just need that the BC is unblocked. > Is it possible to have a method on the BC class that can be invoked > manually to unblock the BC? > I mean, something like > myWebView.releaseBlock(); > I can call it after any of my dialogs have finished interacting with the > user and close. > I think that it would not bother, because I am using the dialog to return > the command and it simplifies the code a lot (no runnables around), so it > is a little price to pay to have this. > Regards > Il giorno giovedì 26 novembre 2020 alle 03:30:42 UTC+1 Shai Almog ha > scritto: > >> This releases the invokeAndBlock thread more often and reduces the period >> the monitor is held. Honestly, I'm not sure if it's a good fix though. >> >> On Wednesday, November 25, 2020 at 12:18:18 PM UTC+2 P5music wrote: >> >>> I see that a modification has been made to a file about the issue I >>> opened: >>> https://github.com/codenameone/CodenameOne/issues/3300 >>> I am curious about what's the meaning and the gist of that modification: >>> >>> https://github.com/codenameone/CodenameOne/commit/ceccd47bdcc3dd3c8f836ec53c10a0fcd3827814 >>> if you may explain it to me. >>> Furthermore I see that some days ago another modification has been made: >>> >>> https://github.com/codenameone/CodenameOne/commit/8f847a45e19de2dbac3bf86e9fcd93d5761471cf >>> I think it could be related to my issue too. Am I right? >>> What can be done? Where I could study this problem on source code? >>> Thanks in advance >>> Regards >>> Il giorno martedì 3 novembre 2020 alle 21:06:04 UTC+1 P5music ha scritto: >>> >>>> Only execute() is used, and moreover that methods and the dialog method >>>> correctly return, nothing is blocked in debugging mode. It has to be >>>> something internal. >>>> Indeed I created a test case with no Javascript execution at all. >>>> Javascript is not causing the BrowserComponent to block (in the simulator). >>>> See the attached file. It is from a bare-bone app. A button launches a >>>> blocking dialog. Also another dialog is launched at startup that's not >>>> blocking. >>>> You cannot select text inside the BC after you launch the blocking >>>> dialog. >>>> Thanks >>>> Il giorno martedì 3 novembre 2020 alle 13:44:34 UTC+1 Steve Hannah ha >>>> scritto: >>>> >>>>> Hard to say from just that code. In general, try to use >>>>> invokeAndBlock() sparingly as it comes with a cost, and may not behave >>>>> the >>>>> way you expect in cases where there are multiple blocking calls >>>>> overlapping. Dialog uses invokeAndBlock for showDialog(). If you're >>>>> using >>>>> any "xxxAndWait()" methods in the BrowserComponent, those use >>>>> invokeAndBlock also. >>>>> >>>>> >>>>> >>>>> On Tue, Nov 3, 2020 at 1:19 AM 'P5music' via CodenameOne Discussions < >>>>> [email protected]> wrote: >>>>> >>>>>> Found the culprit. It was not Javascript, it was not JSON, >>>>>> >>>>>> it was Dialogs. >>>>>> At the completion of an import feature in my app a dialog is shown. I >>>>>> created a class with static methods that handle dialogs. A method like >>>>>> the >>>>>> one below causes the blocking of the BrowserComponent. In another >>>>>> container >>>>>> (it's a sort of master/detail layout) another BC is also blocked, but >>>>>> not >>>>>> the TextFields for example. >>>>>> Here's the method: >>>>>> public static void openAlertDialog( String s1, String s2) >>>>>> { >>>>>> Dialog alertDialog=new Dialog(s1); >>>>>> Button okButton=new Button(okCommand); >>>>>> alertDialog.setLayout(BoxLayout.y()); >>>>>> Container c1=new Container(); >>>>>> c1.setLayout(BoxLayout.x()); >>>>>> alertDialog.add(new SpanLabel(s2, "DialogBody")); >>>>>> c1.add(okButton); >>>>>> alertDialog.add(c1); >>>>>> alertDialog.showDialog(); >>>>>> } >>>>>> The dialog closes as expected but as I can understand I forgot some >>>>>> closing/unblocking instruction. >>>>>> Is that it? >>>>>> Il giorno martedì 3 novembre 2020 alle 04:31:24 UTC+1 Shai Almog ha >>>>>> scritto: >>>>>> >>>>>>> Try thinking how the test case differs from your actual >>>>>>> implementation. I'll ask Steve if he has an idea. >>>>>>> >>>>>>> On Monday, November 2, 2020 at 10:48:29 PM UTC+2 P5music wrote: >>>>>>> >>>>>>>> I checked it out and it is true, BCs get stuck together >>>>>>>> but >>>>>>>> it is not Javascript fault. >>>>>>>> >>>>>>>> I stripped away all lines of code step by step >>>>>>>> and so just it seems to be a problem caused by JSON reading json >>>>>>>> text with json array inside, or something related to ArrayLists, or >>>>>>>> creating instances of a certain class from json array elements. >>>>>>>> >>>>>>>> The strange thing is that the JSON array is correctly extracted and >>>>>>>> all is completed with no errors, data are created correctly >>>>>>>> but after it the BC is stuck. >>>>>>>> >>>>>>>> If I comment that methods that has JSON import inside the BC is not >>>>>>>> blocked. >>>>>>>> >>>>>>>> As I can understand something is causing a silent crash inside the >>>>>>>> simulator (?!?). >>>>>>>> I created a test case but it Does work, so I cannot reproduce the >>>>>>>> issue, indeed the BC is Not blocked. >>>>>>>> >>>>>>>> I have no means to further debug my app. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Il giorno lunedì 2 novembre 2020 alle 03:54:16 UTC+1 Shai Almog ha >>>>>>>> scritto: >>>>>>>> >>>>>>>>> AFAIK they all use a single browser engine and are as a result >>>>>>>>> single threaded. If JS in another component is blocking (or a >>>>>>>>> navigation >>>>>>>>> listener) then there could be cascading effects. >>>>>>>>> >>>>>>>>> On Sunday, November 1, 2020 at 3:46:22 PM UTC+2 P5music wrote: >>>>>>>>> >>>>>>>>>> That error was a one-time event, I think. >>>>>>>>>> In fact the Javascript code is executed, for examples commands >>>>>>>>>> like this: >>>>>>>>>> var div=document.createElement('DIV');div.innerText="TEXT >>>>>>>>>> INJECTED";div.style.position="relative";div.id >>>>>>>>>> ="0";document.body.appendChild(div); >>>>>>>>>> but then the BC is stuck. >>>>>>>>>> Do you deem that another BC elsewhere in the application with >>>>>>>>>> other Javascript injection could cause this? Have the BCs something >>>>>>>>>> in >>>>>>>>>> common that can be cross-locked? >>>>>>>>>> Il giorno domenica 1 novembre 2020 alle 03:28:13 UTC+1 Shai Almog >>>>>>>>>> ha scritto: >>>>>>>>>> >>>>>>>>>>> Yes that could be relevant. >>>>>>>>>>> Can you update the Codename One libraries via Codename One >>>>>>>>>>> Settings and try to reproduce this? >>>>>>>>>>> That line number is no longer applicable. >>>>>>>>>>> >>>>>>>>>>> On Saturday, October 31, 2020 at 4:10:38 PM UTC+2 P5music wrote: >>>>>>>>>>> >>>>>>>>>>>> I do not see Javascript errors in Chrome (previously, syntax >>>>>>>>>>>> errors where shown and I fixed them, now there is nothing) >>>>>>>>>>>> But I see this error in log, could it be relevant? >>>>>>>>>>>> Exception in thread "Thread-154" java.lang.NullPointerException >>>>>>>>>>>> at >>>>>>>>>>>> com.codename1.impl.javase.cef.ResourceHandler.getResponseHeaders(ResourceHandler.java:39) >>>>>>>>>>>> Il giorno sabato 31 ottobre 2020 alle 06:04:48 UTC+1 Shai Almog >>>>>>>>>>>> ha scritto: >>>>>>>>>>>> >>>>>>>>>>>>> Have you tried the chrome JavaScript debugger to see where >>>>>>>>>>>>> it's stuck? >>>>>>>>>>>>> Just inject some event code to see where things are blocked >>>>>>>>>>>>> and see if breakpoints are reached. >>>>>>>>>>>>> >>>>>>>>>>>>> On Friday, October 30, 2020 at 9:30:16 AM UTC+2 P5music wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I realized that the executeAndWait call came from myApp, but >>>>>>>>>>>>>> in another BC that's in another container. >>>>>>>>>>>>>> Now all calls are of the execute() type. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I debugged and I see that the calls are completed and the app >>>>>>>>>>>>>> runs again. >>>>>>>>>>>>>> So the BC is not blocked by the Javascript injection. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I created a test case but I see that this blocking does >>>>>>>>>>>>>> happen only in my app. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What further debugging is possible, said that the execute() >>>>>>>>>>>>>> method seems not to the cause? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Il giorno venerdì 30 ottobre 2020 alle 07:06:54 UTC+1 Shai >>>>>>>>>>>>>> Almog ha scritto: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> executeAndWait uses invokeAndBlock to wait. That means that >>>>>>>>>>>>>>> the JavaScript call never completed. >>>>>>>>>>>>>>> Since this happens in the simulator it's pretty easy to >>>>>>>>>>>>>>> place a breakpoint on executeAndWait to find out who invoked it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thursday, October 29, 2020 at 11:03:17 AM UTC+2 P5music >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It seems that it is stuck repeating here: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> while (!res.complete) { >>>>>>>>>>>>>>>> Display.getInstance().invokeAndBlock(new Runnable() { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> public void run() { >>>>>>>>>>>>>>>> Util.wait(res, 1000); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> }); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> in executeAndWait. >>>>>>>>>>>>>>>> Notice that in my app this method is not called, instead >>>>>>>>>>>>>>>> the normal execute() is. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Il giorno giovedì 29 ottobre 2020 alle 04:25:43 UTC+1 Shai >>>>>>>>>>>>>>>> Almog ha scritto: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I don't know. We'll need to see an issue in isolation in >>>>>>>>>>>>>>>>> the issue tracker to debug this. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wednesday, October 28, 2020 at 11:02:11 AM UTC+2 >>>>>>>>>>>>>>>>> P5music wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> No errors in JS console. >>>>>>>>>>>>>>>>>> Could it be possible that the execute() instruction is >>>>>>>>>>>>>>>>>> waiting for some call like onSuccess() ? >>>>>>>>>>>>>>>>>> If I am not wrong, documentation says it is not the case >>>>>>>>>>>>>>>>>> but maybe it is an issue of the method. >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> Il giorno mercoledì 28 ottobre 2020 alle 03:37:21 UTC+1 >>>>>>>>>>>>>>>>>> Shai Almog ha scritto: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Did you open this in the JavaScript debugger and looked >>>>>>>>>>>>>>>>>>> at the JS console while doing that? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tuesday, October 27, 2020 at 12:15:15 PM UTC+2 >>>>>>>>>>>>>>>>>>> P5music wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> It is not a regression, I created a test case with a >>>>>>>>>>>>>>>>>>>> similar layout and it worked with a Google page. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I debugged my app and it turned up being Javascript >>>>>>>>>>>>>>>>>>>> injections' fault. >>>>>>>>>>>>>>>>>>>> But it is very strange: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The initial page of the BC is made by: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> webView.setPage("<HTML><BODY >>>>>>>>>>>>>>>>>>>> style=\"display:flex;flex-direction:column;\" >"+ >>>>>>>>>>>>>>>>>>>> createLines()+ >>>>>>>>>>>>>>>>>>>> "</BODY></HTML>",""); >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> where it is >>>>>>>>>>>>>>>>>>>> private String createLines() >>>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>>> String result=""; >>>>>>>>>>>>>>>>>>>> for (int i=0;i<100;i++) >>>>>>>>>>>>>>>>>>>> result=result+"<BR/><P>TEXT - LINE >>>>>>>>>>>>>>>>>>>> "+i+"</P>"; >>>>>>>>>>>>>>>>>>>> return result; >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> It is just to have a long page. At this stage the >>>>>>>>>>>>>>>>>>>> scrollbar and the mouse wheel work, and the page is >>>>>>>>>>>>>>>>>>>> scrollable. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Then a list of commands like >>>>>>>>>>>>>>>>>>>> var >>>>>>>>>>>>>>>>>>>> div=document.createElement('DIV');div.style.position="relative"; >>>>>>>>>>>>>>>>>>>> div.id="1";document.body.appendChild(div); >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> are injected, in a single string. >>>>>>>>>>>>>>>>>>>> As I can see the BC does not like that commands, even >>>>>>>>>>>>>>>>>>>> just one of them (I tried just one of them too). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The divs are correctly displayed, also with real >>>>>>>>>>>>>>>>>>>> content inside them, but the issue is present even with >>>>>>>>>>>>>>>>>>>> this bare empty div >>>>>>>>>>>>>>>>>>>> HTML. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> When that command is injected the BC is no more >>>>>>>>>>>>>>>>>>>> responsive to mouse events. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This method is used: >>>>>>>>>>>>>>>>>>>> public void executeJS(String command) >>>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>>> webView.execute(command); >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> What's wrong with that Javascript injection? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Il giorno martedì 27 ottobre 2020 alle 03:55:28 UTC+1 >>>>>>>>>>>>>>>>>>>> Shai Almog ha scritto: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> In that case it could be a CEF regression. Can you >>>>>>>>>>>>>>>>>>>>> isolate a runnable test case that reproduces the problem >>>>>>>>>>>>>>>>>>>>> and file an issue? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Monday, October 26, 2020 at 1:10:53 PM UTC+2 >>>>>>>>>>>>>>>>>>>>> P5music wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I cannot test on the FX version, I am testing the CEF >>>>>>>>>>>>>>>>>>>>>> one on the Simulator (no device test available too). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yes I see the vertical scrollbar of the >>>>>>>>>>>>>>>>>>>>>> BrowserComponent, and it stays also with >>>>>>>>>>>>>>>>>>>>>> setScrollVisible(false); >>>>>>>>>>>>>>>>>>>>>> But the BC does not scroll with that, and it does not >>>>>>>>>>>>>>>>>>>>>> scroll even using the mouse wheel, or dragging over with >>>>>>>>>>>>>>>>>>>>>> the mouse. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Il giorno lunedì 26 ottobre 2020 alle 04:44:34 UTC+1 >>>>>>>>>>>>>>>>>>>>>> Shai Almog ha scritto: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Do you see a scroll bar on the browser component? >>>>>>>>>>>>>>>>>>>>>>> Did you try this on the device? Did you try it with >>>>>>>>>>>>>>>>>>>>>>> the FX version of the browser component? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Sunday, October 25, 2020 at 12:28:46 PM UTC+2 >>>>>>>>>>>>>>>>>>>>>>> P5music wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> So I removed all useless calls to setScrollable >>>>>>>>>>>>>>>>>>>>>>>> kind of methods. >>>>>>>>>>>>>>>>>>>>>>>> It is called just on the mainForm and/or its >>>>>>>>>>>>>>>>>>>>>>>> content pane. >>>>>>>>>>>>>>>>>>>>>>>> mainForm.setScrollable(false); >>>>>>>>>>>>>>>>>>>>>>>> OR >>>>>>>>>>>>>>>>>>>>>>>> mainForm.getContentPane().setScrollableY(false); >>>>>>>>>>>>>>>>>>>>>>>> is needed to let not scroll the entire user >>>>>>>>>>>>>>>>>>>>>>>> interface. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> But the BC is not scrollable. >>>>>>>>>>>>>>>>>>>>>>>> If I set scrollableY=true for the left container it >>>>>>>>>>>>>>>>>>>>>>>> does not scroll either. >>>>>>>>>>>>>>>>>>>>>>>> One of the BC or the left container has to be >>>>>>>>>>>>>>>>>>>>>>>> scrollable to fulfill my needs. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> What further checks can be done? >>>>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>>> Il giorno domenica 25 ottobre 2020 alle 03:14:39 >>>>>>>>>>>>>>>>>>>>>>>> UTC+1 Shai Almog ha scritto: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Don't change the scrollability of the browser >>>>>>>>>>>>>>>>>>>>>>>>> component. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> That option is under zoom and it relates to the >>>>>>>>>>>>>>>>>>>>>>>>> scrolling of the simulator skin itself. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> You don't need to explicitly call >>>>>>>>>>>>>>>>>>>>>>>>> setScrollable(false) since that's the default. The >>>>>>>>>>>>>>>>>>>>>>>>> only thing that's >>>>>>>>>>>>>>>>>>>>>>>>> scrollable by default if the content pane of the main >>>>>>>>>>>>>>>>>>>>>>>>> form. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, October 24, 2020 at 2:09:05 PM UTC+3 >>>>>>>>>>>>>>>>>>>>>>>>> P5music wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The CEF BC is used. >>>>>>>>>>>>>>>>>>>>>>>>>> for the mainform: setScrollable(false) >>>>>>>>>>>>>>>>>>>>>>>>>> for the BC: setScrollableY(true) >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> There is no simulator menu entry "scrollable" to >>>>>>>>>>>>>>>>>>>>>>>>>> uncheck, and I do not understand why to uncheck it >>>>>>>>>>>>>>>>>>>>>>>>>> anyway, and what it >>>>>>>>>>>>>>>>>>>>>>>>>> would refer to? >>>>>>>>>>>>>>>>>>>>>>>>>> Please can you explain? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I have nested containers and I set them all with >>>>>>>>>>>>>>>>>>>>>>>>>> setScrollableX(false) and setScrollableY(false). >>>>>>>>>>>>>>>>>>>>>>>>>> Also the result container of fab binding is set >>>>>>>>>>>>>>>>>>>>>>>>>> the same. (this result container is added to the >>>>>>>>>>>>>>>>>>>>>>>>>> form) >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> A thing has be noticed. >>>>>>>>>>>>>>>>>>>>>>>>>> The most deep nested level is a BorderLayout. It >>>>>>>>>>>>>>>>>>>>>>>>>> has in the north a vertically-short container, then >>>>>>>>>>>>>>>>>>>>>>>>>> in the center it has >>>>>>>>>>>>>>>>>>>>>>>>>> the BrowserComponent. >>>>>>>>>>>>>>>>>>>>>>>>>> When attempting to scroll the BC, just sometimes >>>>>>>>>>>>>>>>>>>>>>>>>> I see a very tiny movement of the entire BC >>>>>>>>>>>>>>>>>>>>>>>>>> including the vertical >>>>>>>>>>>>>>>>>>>>>>>>>> scrollbar, but not the other container in north >>>>>>>>>>>>>>>>>>>>>>>>>> position. >>>>>>>>>>>>>>>>>>>>>>>>>> This reminds me that something is scrolling >>>>>>>>>>>>>>>>>>>>>>>>>> that's surrounding the BC but I cannot understand >>>>>>>>>>>>>>>>>>>>>>>>>> what. >>>>>>>>>>>>>>>>>>>>>>>>>> Do you see anything about this? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Il giorno sabato 24 ottobre 2020 alle 07:32:54 >>>>>>>>>>>>>>>>>>>>>>>>>> UTC+2 Shai Almog ha scritto: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> How is it set to scrollable? >>>>>>>>>>>>>>>>>>>>>>>>>>> If you mean in the simulator menu try to uncheck >>>>>>>>>>>>>>>>>>>>>>>>>>> scrollable. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Are you using CEF or the FX based browser? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Friday, October 23, 2020 at 5:41:50 PM UTC+3 >>>>>>>>>>>>>>>>>>>>>>>>>>> P5music wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> My CodenameApp has a main form that splits the >>>>>>>>>>>>>>>>>>>>>>>>>>>> screen like a master detail layout in landscape >>>>>>>>>>>>>>>>>>>>>>>>>>>> mode. It is set not >>>>>>>>>>>>>>>>>>>>>>>>>>>> scrollable. >>>>>>>>>>>>>>>>>>>>>>>>>>>> A table layout is used with some constraints to >>>>>>>>>>>>>>>>>>>>>>>>>>>> have this appearance. >>>>>>>>>>>>>>>>>>>>>>>>>>>> I am testint the app in the simulator. >>>>>>>>>>>>>>>>>>>>>>>>>>>> In the left part a BrowserComponent is inside a >>>>>>>>>>>>>>>>>>>>>>>>>>>> container and displays some HTML code. >>>>>>>>>>>>>>>>>>>>>>>>>>>> I see that the vertical bar appears on the BC >>>>>>>>>>>>>>>>>>>>>>>>>>>> because the HTML overflows vertically, but cannot >>>>>>>>>>>>>>>>>>>>>>>>>>>> be moved, it is blocked. >>>>>>>>>>>>>>>>>>>>>>>>>>>> The BC is not resposive to the mouse wheel too. >>>>>>>>>>>>>>>>>>>>>>>>>>>> It is set scrollable. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> The container is bound to the >>>>>>>>>>>>>>>>>>>>>>>>>>>> FloatingActionButton that is floating on the >>>>>>>>>>>>>>>>>>>>>>>>>>>> container itself and the BC. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you know any issue that prevents the BC from >>>>>>>>>>>>>>>>>>>>>>>>>>>> being scrolled? Is it something related to the >>>>>>>>>>>>>>>>>>>>>>>>>>>> Version 7.0 milestone issues? >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks in advance >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>> 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/d61c5dba-dcb1-439d-8d6c-a147f4ebd300n%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/codenameone-discussions/d61c5dba-dcb1-439d-8d6c-a147f4ebd300n%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/7d899dd0-ad08-4459-a250-e6a0114f3765n%40googlegroups.com.
