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 codenameone-discussions+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/codenameone-discussions/f9c5f075-e229-45c2-9fe2-5cbc99b7ad64n%40googlegroups.com.
