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/d9d07d10-82c5-45d1-8996-9be9fc40f6d1n%40googlegroups.com.
