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/2ae32b17-54d5-48fa-9413-ce803fc94782n%40googlegroups.com.

Reply via email to