That's an array for the multi-touch behavior not a buffer of touches. That
means that if you have 2, 3+ fingers on the screen we'll get the events for
all of them.
On Friday, March 5, 2021 at 10:47:50 AM UTC+2 P5music wrote:
> Well, I would like to compare to the relevant Android code, because I
> meant that code, however you pointed me to the iOS code so I looked at that.
>
> If the Android and iOS are similar, I can see that an array of touches is
> managed and some touches could be lost.
>
> Some code fragments that hint at that direction:
>
> things like
> pointerDraggedC(xArray, yArray, [touches count]);
> or
> pointerDraggedC(xArray, yArray, [touchesArray count]);
> in
> -(void)touchesBegan
> -(void)touchesEnded
> -(void)touchesCancelled
> or also
> skipNextTouch
> all seem to prune the events.
>
> But I think that also the text-selection interface that pops up on Android
> could lead to a cancellation of events if this code is also in Android:
> if(touchesArray != nil) {
> [touchesArray removeAllObjects];
> }
> in
> (void)updateCanvas:(BOOL)animated
>
> Regards
>
> Il giorno venerdì 5 marzo 2021 alle 05:09:19 UTC+1 Shai Almog ha scritto:
>
>> It's generally the touch events in the glviewcontroller file. From there
>> you can just follow the flow all the way out to the Java code in
>> IOSImplementation.
>>
>> On Thursday, March 4, 2021 at 2:40:18 PM UTC+2 P5music wrote:
>>
>>> Please can you point me to some source code so I can inspect it about
>>> the issue I filed?
>>> It's about CEF so it boils down to some interface for mouse events.
>>> Thanks
>>>
>>>
>>> Il giorno giovedì 4 marzo 2021 alle 03:09:12 UTC+1 Shai Almog ha scritto:
>>>
>>>> I don't know, it's hard to tell from a review of the code.
>>>>
>>>> On Wednesday, March 3, 2021 at 12:52:36 PM UTC+2 P5music wrote:
>>>>
>>>>> I need the information whether this issue could impact iOS or not.
>>>>> Is it possible to know this while the issue is not fixed yet on
>>>>> Android?
>>>>> If it is not on iOS too, for example thanks to more consistent APIs, I
>>>>> could start testing on those devices, but some kind of action has to be
>>>>> taken on my side, so it would be useful to know in advance.
>>>>> Thanks in advance
>>>>>
>>>>> Il giorno venerdì 26 febbraio 2021 alle 08:49:44 UTC+1 P5music ha
>>>>> scritto:
>>>>>
>>>>>> CEF BrowserComponent: mouse events handled differently in Android
>>>>>> device than simulator · Issue #3378 · codenameone/CodenameOne
>>>>>> (github.com)
>>>>>> <https://github.com/codenameone/CodenameOne/issues/3378>
>>>>>>
>>>>>> Il giorno venerdì 26 febbraio 2021 alle 07:09:36 UTC+1 Shai Almog ha
>>>>>> scritto:
>>>>>>
>>>>>>> OK, is this filed as an issue so I can assign it to Steve?
>>>>>>>
>>>>>>> On Thursday, February 25, 2021 at 12:50:14 PM UTC+2 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/3cdc24b5-14b8-4690-a97f-8474e217cba7n%40googlegroups.com.
