"We can only fix bugs in the interconnect"

Yes, please have a look at that.
Thanks

Il giorno mercoledì 10 marzo 2021 alle 04:37:31 UTC+1 Shai Almog ha scritto:

> We can't fix different behaviors of Androids webkit browser, if a specific 
> div from the webkit implementation on Android doesn't send an event (or 
> does) for us the webkit is a black box.We can only fix bugs in the 
> interconnect.
>
> On Tuesday, March 9, 2021 at 6:19:43 PM UTC+2 P5music wrote:
>
>> There is not any difficult case, because on the simulator it works very 
>> well as expected.
>>
>> I am not mixing anything, please read this issue to be fixed:
>> https://github.com/codenameone/CodenameOne/issues/3378
>>
>> I just put a callback for mousedown and mouseup, and it gets called on a 
>> DIV, with a iFrame inside. 
>> The iFrame does not respond to mouse events, the DIV does.
>> Simple click works and the two events are fired and the callbacks get 
>> called.
>> Long press also works on the simulator, I just handle the different 
>> timing.
>>
>> But on Android it happens as I described, not working: I can select text 
>> on the iFrame but its style settings should not allow 
>> (pointerEvents='none') so it's not OK.
>> It causes or is related to the DIV not respoding to long press, while it 
>> still responds to simple click.
>>
>> I do not mind whether I have to handle it with JS or with the 
>> longPressListener, it is enough that it works, just tell me what is the 
>> right way.
>> I was said that JS is the right way. Ok, my source code is handling that 
>> way, it is ready, no modification is needed.
>>
>> Please ask for other details if necessary.
>>
>> Il giorno martedì 9 marzo 2021 alle 15:50:31 UTC+1 shannah ha scritto:
>>
>>> > Furthermore there is no such complex case as you seem to be thinking. 
>>> The issue is very simple:
>>> > text is selectable where it should not be (pointerEvents='none' on 
>>> iFrame), and this leads to mouse events being captured by the system and 
>>> not the BC or the CN layer, or viceversa, I do not know.
>>>
>>> That is not a simple case.  You're mixing event models between web and 
>>> CN1.  It's incredibly complex.
>>>
>>> I recommend you isolate your Javascript web portion so that you can test 
>>> it on each platform you target without CN1.  
>>>
>>> On Tue, Mar 9, 2021 at 6:34 AM 'P5music' via CodenameOne Discussions <
>>> [email protected]> wrote:
>>>
>>>> Hi Steve,
>>>> thanks for chiming in,
>>>> as you can read in the github issue I filed, the correct behaviour is 
>>>> already found on the simulator. 
>>>> No need to further debug, because debug has been already done on 
>>>> Android device too.
>>>> The issue is on Android and probably on iOS. I do not mind doing a test 
>>>> on iOS device myself but it cannot be done today because I must create 
>>>> certificates yet.
>>>> Furthermore there is no such complex case as you seem to be thinking. 
>>>> The issue is very simple:
>>>> text is selectable where it should not be (pointerEvents='none' on 
>>>> iFrame), and this leads to mouse events being captured by the system and 
>>>> not the BC or the CN layer, or viceversa, I do not know.
>>>> Regards
>>>>
>>>> Il giorno martedì 9 marzo 2021 alle 14:44:23 UTC+1 shannah ha scritto:
>>>>
>>>>> A couple of comments:
>>>>>
>>>>> 1. BrowserComponent is a heavyweight/native component and its 
>>>>> implementation will be different on different platforms.  
>>>>> 2. Debugging hybrid apps (that use both Javascript/HTML and CN1 UI) is 
>>>>> necessarily more complex than debugging an app where all the UI is in 
>>>>> Codename One.  You should use Safari's debugging tools to debug the 
>>>>> webview 
>>>>> on device.  You should use the Chrome debugging tools to debug the 
>>>>> webview 
>>>>> in the simulator and on Android device.  
>>>>> 3. Most important:  When developing complex JS your life will be 
>>>>> easier if you can structure it so that you can test it independently from 
>>>>> the Codename One app.  Create your HTML and javascript, host it on a 
>>>>> server 
>>>>> (even localhost - but not file:///), and test it in the web browsers of 
>>>>> the 
>>>>> platforms you want to support.  In your case you're looking for specific 
>>>>> behaviour related to events (whether text should be selected in response 
>>>>> to 
>>>>> a mouse event, etc..), so it may take a little tweaking to get it perfect 
>>>>> in an HTML only sandbox.  Once you have it working, then you can plug in 
>>>>> the CodenameOne piece.
>>>>> An intermediate step before fully integrating your JS with your 
>>>>> Codename One app, is to *just* load the HTML page in a Browser component 
>>>>> without any communication between Java and Javascript. See if any 
>>>>> functionality that works in the platform browser app breaks when run 
>>>>> inside 
>>>>> a BrowserComponent.
>>>>> After that is working perfectly, you're ready to add the java <-> 
>>>>> javascript communication piece.
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>>>
>>>>> On Thursday, February 25, 2021 at 2:50:14 AM UTC-8 P5music wrote:
>>>>>
>>>>>> I created a test case but before filing an issue I have to point out 
>>>>>> what follows. (You find the relevant code below)
>>>>>> The test app features a CEF BrowserComponent with some text inside.
>>>>>> Text lines are not so long horizontally to fill the view, so the 
>>>>>> right part is empty.
>>>>>> Also the bottom part is empty because only a few text lines are in 
>>>>>> the HTML.
>>>>>>
>>>>>> On the Android device:
>>>>>> I can click on text and I have the mousedown/mouseup sequence (events 
>>>>>> are fired and callbacks are issued).
>>>>>> I can click on the empty part on the right and I have the  
>>>>>> mousedown/mouseup sequence (events are fired and callbacks are issued). 
>>>>>>
>>>>>> If I click on the empty part on the bottom I have no callbacks.
>>>>>>
>>>>>> If I long-press on the text the Android text-selection interface 
>>>>>> appears.
>>>>>> If I long-press on the empty part on the right no callbacks are 
>>>>>> issued (this is the issue this thread is about but it is entwined with 
>>>>>> something else, read on).
>>>>>>
>>>>>> I remind that the empty part on the right is a DIV with the callbacks 
>>>>>> on it.
>>>>>> And the bottom part is really empty.
>>>>>>
>>>>>> Sofor my app to work
>>>>>> -the text should not be selectable in the BrowserComponent because in 
>>>>>> my app the long-press on any iFrame in the list is just for launching 
>>>>>> the 
>>>>>> pop-up menu.
>>>>>> -the long-press events should be issued also on the text, if present 
>>>>>> in the iFrames.
>>>>>>
>>>>>> How to have those two specs satisfied?
>>>>>> It seems that there are two questions, one is maybe the simplest to 
>>>>>> solve, the other is maybe a bug to file an issue about. 
>>>>>> And the two are together, it seems.
>>>>>> (They are not seen in the simulator)
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> public void start() {
>>>>>> if(current != null){
>>>>>> current.show();
>>>>>> return;
>>>>>> }
>>>>>> Form hi = new Form("Hi World");
>>>>>> hi.setLayout(new BorderLayout());
>>>>>> hi.add(BorderLayout.NORTH,new Label("Hi World"));
>>>>>> BrowserComponent bc=new BrowserComponent();
>>>>>>
>>>>>> bc.addWebEventListener("onLoad", new ActionListener() {
>>>>>> @Override
>>>>>> public void actionPerformed(ActionEvent evt) {
>>>>>> System.out.println("onload");
>>>>>> bc.addJSCallback("var div=document.getElementById('divId');" +
>>>>>> "callMouseDown 
>>>>>> =function(){callback.onSuccess('mousedown');};callMouseUp 
>>>>>> =function(){callback.onSuccess('mouseup');};"+
>>>>>> "div.addEventListener('mousedown', function () {"+
>>>>>> "callMouseDown();"+
>>>>>> "});"+
>>>>>> "div.addEventListener('mouseup', function () {"+
>>>>>> "callMouseUp();"+
>>>>>> "});"
>>>>>> , new SuccessCallback<BrowserComponent.JSRef>() {
>>>>>> @Override
>>>>>> public void onSucess(BrowserComponent.JSRef value) {
>>>>>> System.out.println("webview callback value="+value.getValue());
>>>>>> }});
>>>>>> }
>>>>>> });
>>>>>>
>>>>>> bc.setPage("<HTML><BODY><DIV id='divId' 
>>>>>> ><DIV>TEST</BR>TEST</BR>TEST</BR>TEST</BR>TEST</BR>TEST</BR>TEST</BR></DIV></DIV></BODY></HTML>","");
>>>>>>
>>>>>> hi.add(BorderLayout.CENTER,bc);
>>>>>> hi.show();
>>>>>> }
>>>>>> Il giorno mercoledì 24 febbraio 2021 alle 03:16:36 UTC+1 Shai Almog 
>>>>>> ha scritto:
>>>>>>
>>>>>>> If it's in JavaScript then it sounds like a bug. Can you extract a 
>>>>>>> test case and file an issue?
>>>>>>>
>>>>>>> On Tuesday, February 23, 2021 at 11:27:59 AM UTC+2 P5music wrote:
>>>>>>>
>>>>>>>> I am talking about are handled in javascript
>>>>>>>> indeed I explicitly wrote about callbacks.
>>>>>>>> (the longpress listener also is not called, it is in Java just for 
>>>>>>>> testing purposes as a fallback but it is not useful because it is not 
>>>>>>>> called either) 
>>>>>>>>
>>>>>>>> This is the problem:
>>>>>>>> The first event should be "mousedown"
>>>>>>>> and it is in the simulator, whatever kind of click type the user 
>>>>>>>> does, i.e. click or longpress.
>>>>>>>> The second event should be "mouseup"
>>>>>>>> and it is in the simuator, whatever kind of click type the user 
>>>>>>>> does, i.e. click or longpress, just the difference is timing.
>>>>>>>> The Javascript callbacks work and a suitable part of the code is 
>>>>>>>> called for each of the above mentioned events.
>>>>>>>> (It is not a simulator bug, it works as it should)
>>>>>>>> So In case of click those events are fired correctly both in 
>>>>>>>> simulator and also in the Android device.
>>>>>>>>
>>>>>>>> Instead
>>>>>>>> in case of long press on the real Android device only click is 
>>>>>>>> handled correctly and I see the correct sequence of mouse events,
>>>>>>>> but with long press those events are not fired, like they are 
>>>>>>>> gobbled down.
>>>>>>>> So both the down event and the up event are not handled, they do 
>>>>>>>> not trigger the callbacks, they are not fired ore they are gobbled.
>>>>>>>>
>>>>>>>> It seems that the WebView has a timer itself and decides whether to 
>>>>>>>> fire the first event according to the timing of the second.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Il giorno martedì 23 febbraio 2021 alle 04:04:20 UTC+1 Shai Almog 
>>>>>>>> ha scritto:
>>>>>>>>
>>>>>>>>> That sounds like a bug in the simulator not on the device. If you 
>>>>>>>>> click in the browser component the event should be delivered there. 
>>>>>>>>> Not to 
>>>>>>>>> Codename One. You need to intercept it in JavaScript.
>>>>>>>>>
>>>>>>>>> On Monday, February 22, 2021 at 10:22:12 AM UTC+2 P5music wrote:
>>>>>>>>>
>>>>>>>>>> The click is on the iFrames inside the HTML, so it is on the BC.
>>>>>>>>>> It works on the simulator:
>>>>>>>>>> click and long-press gestures are handled with a timer and 
>>>>>>>>>> comparing the timestamps.
>>>>>>>>>> The issue is that 
>>>>>>>>>> when I long-press on the BC when the app runs on the real Android 
>>>>>>>>>> device,
>>>>>>>>>> even the first mouse event (mousedown) is not fired,
>>>>>>>>>> it is like the BC has a timer itself and does not fire the 
>>>>>>>>>> mousedown event if the mouseup event is too far in time,
>>>>>>>>>> while in the simulator the mousedown event is issued every time, 
>>>>>>>>>> regardless of the timing of the subsequent mouseup event.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> Il giorno lunedì 22 febbraio 2021 alle 03:29:37 UTC+1 Shai Almog 
>>>>>>>>>> ha scritto:
>>>>>>>>>>
>>>>>>>>>>> Are you long clicking on the browser component or somewhere 
>>>>>>>>>>> else? It's unclear from the question.  Do you have a screenshot of 
>>>>>>>>>>> the 
>>>>>>>>>>> place you're clicking on?
>>>>>>>>>>>
>>>>>>>>>>> On Sunday, February 21, 2021 at 1:17:56 PM UTC+2 P5music wrote:
>>>>>>>>>>>
>>>>>>>>>>>> P5music
>>>>>>>>>>>> 12:16 (ora) 
>>>>>>>>>>>> a CodenameOne Discussions
>>>>>>>>>>>> I am testing my CodenameApp on a real Android device.
>>>>>>>>>>>> The main screen has a table layout with a container on the left.
>>>>>>>>>>>> The container has a container inside, that has a 
>>>>>>>>>>>> BrowserComponent inside in BorderLayout.CENTER.
>>>>>>>>>>>> The issue is not about layout.
>>>>>>>>>>>>
>>>>>>>>>>>> I have some callbacks for the BC that on the simulator handle 
>>>>>>>>>>>> mouseup/down on the iFrames in the HTML.
>>>>>>>>>>>> That callback work also for handing long-press on the same HTML 
>>>>>>>>>>>> elements.
>>>>>>>>>>>> Everything is fine. If I add a LongPressListener it gets not 
>>>>>>>>>>>> called but it is not needed at all.
>>>>>>>>>>>>
>>>>>>>>>>>> When using the app on the real Android device the clicks are 
>>>>>>>>>>>> handled as in the simulator
>>>>>>>>>>>> while
>>>>>>>>>>>> the long press is not.
>>>>>>>>>>>> I debugged and it seems that the events are not fired at all.
>>>>>>>>>>>> I mean,
>>>>>>>>>>>> a click is mousedown and mouseup within a short time range.
>>>>>>>>>>>> a longpress is the same where the mouseup event is after 500ms. 
>>>>>>>>>>>> The app uses a timer.
>>>>>>>>>>>>
>>>>>>>>>>>> But the initial mousedown event itself is not called, and also 
>>>>>>>>>>>> the LongPressListener is not called.
>>>>>>>>>>>>
>>>>>>>>>>>> So what is happening? This is very important because the 
>>>>>>>>>>>> long-press is for displaying a pop-up  menu. But only clicks work.
>>>>>>>>>>>> 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/bc6eb9a2-32d0-4285-93e3-f9b6bea8060an%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/codenameone-discussions/bc6eb9a2-32d0-4285-93e3-f9b6bea8060an%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>> -- 
>>> Steve Hannah
>>> Web Lite Solutions Corp.
>>>
>>

-- 
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/a29c04d9-caee-4176-b5e8-0b219d9ccaeen%40googlegroups.com.

Reply via email to