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/f9c5f075-e229-45c2-9fe2-5cbc99b7ad64n%40googlegroups.com.
