The long press isn'5 the problem. It's the press/release that aren't sent
since the browser component grabs them. That's the correct behavior.
On Sunday, March 7, 2021 at 10:38:45 AM UTC+2 P5music wrote:
> 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/98ba7914-92b2-4083-bd6f-8fa96bf8d86bn%40googlegroups.com.
