So, as I said, the LongPressListener method is not called, so it has to be
fixed, but I recall that you said that I should handle those events with
Javascript.
Said that,
whatever method will work when the issue is fixed (I hope that on iOS the
issue is not present but I have yet to check)
it seems that the code
if(touchesArray != nil) {
[touchesArray removeAllObjects];
}
in
(void)updateCanvas:(BOOL)animated
could remove the events
when the text-selection-interface is triggered.
It seems that you used the gestures, not the touches so it could lead to
this behaviour.
I can manage the non-wanted mouse events from long-pressing the iFrames
but
the interface for text-selection has not to appear.
Regards
Il giorno domenica 7 marzo 2021 alle 03:20:06 UTC+1 Shai Almog ha scritto:
> A long press is triggered in the Codename One layer not in the native
> layer. We detect it when receiving a press and not receiving a release
> after a while.
>
> On Saturday, March 6, 2021 at 10:11:37 AM UTC+2 P5music wrote:
>
>> And what about the possibility that the long-press event not being fired
>> is a byproduct of the text-selection-interface
>> so this code
>> if(touchesArray != nil) {
>> [touchesArray removeAllObjects];
>> }
>> in
>> (void)updateCanvas:(BOOL)animated
>>
>> effectively remove the touches when the interface appears.
>>
>> So the bug would be:
>> why the text-selection-interface appears also when the iFrames are set
>> not to process pointer events?
>>
>> Fixing this, the text-selection-interface would not be triggered and
>> long-press events would be fired again and go through the event bubble
>> chain.
>> Regards
>> Il giorno sabato 6 marzo 2021 alle 05:50:55 UTC+1 Shai Almog ha scritto:
>>
>>> 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/47006cdb-bbb0-4528-a70b-ccc973f73dc6n%40googlegroups.com.
