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.
