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/00fc01f2-2938-4f16-baf0-f9e81df8cd53n%40googlegroups.com.
