I found a workaround:
there are special events on touch devices that are not involved in the
issue.
I have to use those events instead of mousedown, mouseup, which still are
useful in the IDE simulator in fact.
String touchStartEventString;
String touchEndEventString;
if (Utils.isSimulator())
"We can only fix bugs in the interconnect"
Yes, please have a look at that.
Thanks
Il giorno mercoledì 10 marzo 2021 alle 04:37:31 UTC+1 Shai Almog ha scritto:
> We can't fix different behaviors of Androids webkit browser, if a specific
> div from the webkit implementation on Android doesn't
We can't fix different behaviors of Androids webkit browser, if a specific
div from the webkit implementation on Android doesn't send an event (or
does) for us the webkit is a black box.We can only fix bugs in the
interconnect.
On Tuesday, March 9, 2021 at 6:19:43 PM UTC+2 P5music wrote:
>
There is not any difficult case, because on the simulator it works very
well as expected.
I am not mixing anything, please read this issue to be fixed:
https://github.com/codenameone/CodenameOne/issues/3378
I just put a callback for mousedown and mouseup, and it gets called on a
DIV, with a
> Furthermore there is no such complex case as you seem to be thinking. The
issue is very simple:
> text is selectable where it should not be (pointerEvents='none' on
iFrame), and this leads to mouse events being captured by the system and
not the BC or the CN layer, or viceversa, I do not know.
Hi Steve,
thanks for chiming in,
as you can read in the github issue I filed, the correct behaviour is
already found on the simulator.
No need to further debug, because debug has been already done on Android
device too.
The issue is on Android and probably on iOS. I do not mind doing a test on
A couple of comments:
1. BrowserComponent is a heavyweight/native component and its
implementation will be different on different platforms.
2. Debugging hybrid apps (that use both Javascript/HTML and CN1 UI) is
necessarily more complex than debugging an app where all the UI is in
Codename
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
>
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
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
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
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
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
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,
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
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
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
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,
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
I am trying to create a test case to reproduce the issue.
I created a new project and it seems that the events are called correctly.
But
the BrowserComponent() seems to be different. Indeed in my original app I
can have the addLongPressListener method,
while in the test app that method is not
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
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
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
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
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
25 matches
Mail list logo
