We'll get to it when we do. You can debug it on Android using Android
Studio pretty easily.
On Monday, March 8, 2021 at 10:20:54 AM UTC+2 P5music wrote:
> Ok so it is something that is on iOS too probably, according to your
> analysis.
> Now I think it is importat to fix the filed issue
> because it is very simple, a matter of just looking at the code and
> understanding that wrong timing.
> Even if it is a non-enterprise issue, it's blocking of a very important
> component, crucial for modern app development in many cases.
> It is also completely blocking my app, so it is different from other
> non-blocking issues.
> It's just a matter of time that an enterprise customer stumbles upon it.
> Better it does not happen and they find the component correctly working in
> the first place.
>
> Regards
>
> Il giorno lunedì 8 marzo 2021 alle 03:36:18 UTC+1 Shai Almog ha scritto:
>
>> 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/ed6f6a72-e317-40ea-a7fb-1086c6d3761en%40googlegroups.com.
