Re: [codenameone-discussions] Re: BrowserComponent: mouse events handled differently in Android device than simulator
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())
{
touchStartEventString="mousedown";
touchEndEventString="mouseup";
}
else
{
touchStartEventString="touchstart";
touchEndEventString="touchend";
}
That special events are always correctly fired also on Android device.
For the IDE simulator the normal events are the only ones possible, because
it is not a real touch device.
It is also necessary to have this:
user-select: none;-webkit-user-select: none;
added to the style attribute of the BODY tag in the HTML so that the text
is forced not to be selectable everywhere.
This workaround should be right on iOS too, even if the issue is not
present there.
Of course it is not applicable to the general case where the issue is
present but it I enough for my needs.
Regards
Il giorno giovedì 11 marzo 2021 alle 07:59:23 UTC+1 P5music ha scritto:
> "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 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 iFrame inside.
>>> The iFrame does not respond to mouse events, the DIV does.
>>> Simple click works and the two events are fired and the callbacks get
>>> called.
>>> Long press also works on the simulator, I just handle the different
>>> timing.
>>>
>>> But on Android it happens as I described, not working: I can select text
>>> on the iFrame but its style settings should not allow
>>> (pointerEvents='none') so it's not OK.
>>> It causes or is related to the DIV not respoding to long press, while it
>>> still responds to simple click.
>>>
>>> I do not mind whether I have to handle it with JS or with the
>>> longPressListener, it is enough that it works, just tell me what is the
>>> right way.
>>> I was said that JS is the right way. Ok, my source code is handling that
>>> way, it is ready, no modification is needed.
>>>
>>> Please ask for other details if necessary.
>>>
>>> Il giorno martedì 9 marzo 2021 alle 15:50:31 UTC+1 shannah ha scritto:
>>>
> 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.
That is not a simple case. You're mixing event models between web and
CN1. It's incredibly complex.
I recommend you isolate your Javascript web portion so that you can
test it on each platform you target without CN1.
On Tue, Mar 9, 2021 at 6:34 AM 'P5music' via CodenameOne Discussions <
codenameone...@googlegroups.com> wrote:
> 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 iOS device myself but it cannot be done today because I must
> create
> certificates yet.
> 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.
> Regards
>
> Il giorno martedì 9 marzo 2021 alle 14:44:23 UTC+1 shannah ha scritto:
>
>> 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 One. You should use Safari's debugging tools to debug the
>> webview
>> on device. You should use the Chrome debugging tools to debug the
>> webview
>> in
Re: [codenameone-discussions] Re: BrowserComponent: mouse events handled differently in Android device than simulator
"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 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 iFrame inside. >> The iFrame does not respond to mouse events, the DIV does. >> Simple click works and the two events are fired and the callbacks get >> called. >> Long press also works on the simulator, I just handle the different >> timing. >> >> But on Android it happens as I described, not working: I can select text >> on the iFrame but its style settings should not allow >> (pointerEvents='none') so it's not OK. >> It causes or is related to the DIV not respoding to long press, while it >> still responds to simple click. >> >> I do not mind whether I have to handle it with JS or with the >> longPressListener, it is enough that it works, just tell me what is the >> right way. >> I was said that JS is the right way. Ok, my source code is handling that >> way, it is ready, no modification is needed. >> >> Please ask for other details if necessary. >> >> Il giorno martedì 9 marzo 2021 alle 15:50:31 UTC+1 shannah ha scritto: >> >>> > 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. >>> >>> That is not a simple case. You're mixing event models between web and >>> CN1. It's incredibly complex. >>> >>> I recommend you isolate your Javascript web portion so that you can test >>> it on each platform you target without CN1. >>> >>> On Tue, Mar 9, 2021 at 6:34 AM 'P5music' via CodenameOne Discussions < >>> codenameone...@googlegroups.com> wrote: >>> 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 iOS device myself but it cannot be done today because I must create certificates yet. 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. Regards Il giorno martedì 9 marzo 2021 alle 14:44:23 UTC+1 shannah ha scritto: > 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 One. You should use Safari's debugging tools to debug the > webview > on device. You should use the Chrome debugging tools to debug the > webview > in the simulator and on Android device. > 3. Most important: When developing complex JS your life will be > easier if you can structure it so that you can test it independently from > the Codename One app. Create your HTML and javascript, host it on a > server > (even localhost - but not file:///), and test it in the web browsers of > the > platforms you want to support. In your case you're looking for specific > behaviour related to events (whether text should be selected in response > to > a mouse event, etc..), so it may take a little tweaking to get it perfect > in an HTML only sandbox. Once you have it working, then you can plug in > the CodenameOne piece. > An intermediate step before fully integrating your JS with your > Codename One app, is to *just* load the HTML page in a Browser component > without any communication between Java and Javascript. See if any > functionality that works in the platform browser app breaks when run > inside > a BrowserComponent. > After that is working perfectly, you're ready to add the java <-> > javascript communication piece. > > Steve
Re: [codenameone-discussions] Re: BrowserComponent: mouse events handled differently in Android device than simulator
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 iFrame inside. > The iFrame does not respond to mouse events, the DIV does. > Simple click works and the two events are fired and the callbacks get > called. > Long press also works on the simulator, I just handle the different timing. > > But on Android it happens as I described, not working: I can select text > on the iFrame but its style settings should not allow > (pointerEvents='none') so it's not OK. > It causes or is related to the DIV not respoding to long press, while it > still responds to simple click. > > I do not mind whether I have to handle it with JS or with the > longPressListener, it is enough that it works, just tell me what is the > right way. > I was said that JS is the right way. Ok, my source code is handling that > way, it is ready, no modification is needed. > > Please ask for other details if necessary. > > Il giorno martedì 9 marzo 2021 alle 15:50:31 UTC+1 shannah ha scritto: > >> > 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. >> >> That is not a simple case. You're mixing event models between web and >> CN1. It's incredibly complex. >> >> I recommend you isolate your Javascript web portion so that you can test >> it on each platform you target without CN1. >> >> On Tue, Mar 9, 2021 at 6:34 AM 'P5music' via CodenameOne Discussions < >> codenameone...@googlegroups.com> wrote: >> >>> 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 iOS device myself but it cannot be done today because I must create >>> certificates yet. >>> 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. >>> Regards >>> >>> Il giorno martedì 9 marzo 2021 alle 14:44:23 UTC+1 shannah ha scritto: >>> 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 One. You should use Safari's debugging tools to debug the webview on device. You should use the Chrome debugging tools to debug the webview in the simulator and on Android device. 3. Most important: When developing complex JS your life will be easier if you can structure it so that you can test it independently from the Codename One app. Create your HTML and javascript, host it on a server (even localhost - but not file:///), and test it in the web browsers of the platforms you want to support. In your case you're looking for specific behaviour related to events (whether text should be selected in response to a mouse event, etc..), so it may take a little tweaking to get it perfect in an HTML only sandbox. Once you have it working, then you can plug in the CodenameOne piece. An intermediate step before fully integrating your JS with your Codename One app, is to *just* load the HTML page in a Browser component without any communication between Java and Javascript. See if any functionality that works in the platform browser app breaks when run inside a BrowserComponent. After that is working perfectly, you're ready to add the java <-> javascript communication piece. Steve On Thursday, February 25, 2021 at 2:50:14 AM UTC-8 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
Re: [codenameone-discussions] Re: BrowserComponent: mouse events handled differently in Android device than simulator
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 iFrame inside. The iFrame does not respond to mouse events, the DIV does. Simple click works and the two events are fired and the callbacks get called. Long press also works on the simulator, I just handle the different timing. But on Android it happens as I described, not working: I can select text on the iFrame but its style settings should not allow (pointerEvents='none') so it's not OK. It causes or is related to the DIV not respoding to long press, while it still responds to simple click. I do not mind whether I have to handle it with JS or with the longPressListener, it is enough that it works, just tell me what is the right way. I was said that JS is the right way. Ok, my source code is handling that way, it is ready, no modification is needed. Please ask for other details if necessary. Il giorno martedì 9 marzo 2021 alle 15:50:31 UTC+1 shannah ha scritto: > > 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. > > That is not a simple case. You're mixing event models between web and > CN1. It's incredibly complex. > > I recommend you isolate your Javascript web portion so that you can test > it on each platform you target without CN1. > > On Tue, Mar 9, 2021 at 6:34 AM 'P5music' via CodenameOne Discussions < > codenameone...@googlegroups.com> wrote: > >> 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 iOS device myself but it cannot be done today because I must create >> certificates yet. >> 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. >> Regards >> >> Il giorno martedì 9 marzo 2021 alle 14:44:23 UTC+1 shannah ha scritto: >> >>> 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 One. You should use Safari's debugging tools to debug the webview >>> on device. You should use the Chrome debugging tools to debug the webview >>> in the simulator and on Android device. >>> 3. Most important: When developing complex JS your life will be easier >>> if you can structure it so that you can test it independently from the >>> Codename One app. Create your HTML and javascript, host it on a server >>> (even localhost - but not file:///), and test it in the web browsers of the >>> platforms you want to support. In your case you're looking for specific >>> behaviour related to events (whether text should be selected in response to >>> a mouse event, etc..), so it may take a little tweaking to get it perfect >>> in an HTML only sandbox. Once you have it working, then you can plug in >>> the CodenameOne piece. >>> An intermediate step before fully integrating your JS with your Codename >>> One app, is to *just* load the HTML page in a Browser component without any >>> communication between Java and Javascript. See if any functionality that >>> works in the platform browser app breaks when run inside a BrowserComponent. >>> After that is working perfectly, you're ready to add the java <-> >>> javascript communication piece. >>> >>> Steve >>> >>> >>> >>> On Thursday, February 25, 2021 at 2:50:14 AM UTC-8 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
Re: [codenameone-discussions] Re: BrowserComponent: mouse events handled differently in Android device than simulator
> 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.
That is not a simple case. You're mixing event models between web and
CN1. It's incredibly complex.
I recommend you isolate your Javascript web portion so that you can test it
on each platform you target without CN1.
On Tue, Mar 9, 2021 at 6:34 AM 'P5music' via CodenameOne Discussions <
codenameone-discussions@googlegroups.com> wrote:
> 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
> iOS device myself but it cannot be done today because I must create
> certificates yet.
> 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.
> Regards
>
> Il giorno martedì 9 marzo 2021 alle 14:44:23 UTC+1 shannah ha scritto:
>
>> 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 One. You should use Safari's debugging tools to debug the webview
>> on device. You should use the Chrome debugging tools to debug the webview
>> in the simulator and on Android device.
>> 3. Most important: When developing complex JS your life will be easier
>> if you can structure it so that you can test it independently from the
>> Codename One app. Create your HTML and javascript, host it on a server
>> (even localhost - but not file:///), and test it in the web browsers of the
>> platforms you want to support. In your case you're looking for specific
>> behaviour related to events (whether text should be selected in response to
>> a mouse event, etc..), so it may take a little tweaking to get it perfect
>> in an HTML only sandbox. Once you have it working, then you can plug in
>> the CodenameOne piece.
>> An intermediate step before fully integrating your JS with your Codename
>> One app, is to *just* load the HTML page in a Browser component without any
>> communication between Java and Javascript. See if any functionality that
>> works in the platform browser app breaks when run inside a BrowserComponent.
>> After that is working perfectly, you're ready to add the java <->
>> javascript communication piece.
>>
>> Steve
>>
>>
>>
>> On Thursday, February 25, 2021 at 2:50:14 AM UTC-8 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"));
>>>
