Mobile Mode Issues

[trent]

Hi Bruce,

I'm getting quite a few issues in mobile mode when testing on an actual mobile phone - I'm using an iPhone 4S:

1) On a simple login form if the user presses the 'Login' field to type in their username it automatically takes them to the 'Password' field instead.
2) Same login form, the user presses a drop list and the 'Password' field is selected instead with the keyboard showing.
3) Same login form, the user first enters the 'Login', then the 'Password', then selects the drop value, the drop does not select the value correctly and the user has to select it twice to get it to work.

All of these issues can be replicated in the app attached to this post. Please use a mobile phone when testing.

Instructions for item 1:

1) Start the webserver.
2) On a mobile phone, navigate to the website.
3) Press the 'Login' menu item.
4) Press the 'Login' field, it should go straight to the 'Password' field instead. If it does not, please refresh/reload the page then press the 'Login' field.

Instructions for item 2 - assuming you have done steps 1 to 3 above:

1) Reload the page so it has no values.
2) Press the drop list. The 'Password' field is selected instead.

Instructions for item 3:

1) Reload the page so it has no values.
2) Enter the 'Login'.
3) Enter the 'Password'.
4) Press the drop list and select a value. Notice the value is not saved and you have to repeat the selection.

Please let me know if you need more information.

Regards,
Trent

[attachment deleted by admin]

[Bruce]

Hi Trent,

I'm testing on an iPhone 4S, with iOS 7, using the Safari browser with NetTalk build 8.57.

Item 1:
Sorry - unable to duplicate. It stays on Login if I tap on the Login field. The keyboard appears when I tap on the field. I've refreshed the field a few times, but this doesn't change.

Item 2:
again, not seeing a problem - seems to work ok.

Items 3:
This one I can duplicate, and the reason for it is understandable.
In the GenerateForm routine you are populating a local queue. But local queues do not work because they do not persist across threads, and the user interface is multi-threaded.
Think of the form as a giant event handler - where every event happens on a separate thread. GenerateForm is called when the form is generated, but it's not called when the fields are validated. So while it's _possible_ to use the Queue as a source you would need to populate it in a better place - and frankly for just 2 entries it's not worth the hassle.

For the LOC:MaleFemale field you should not populate on the "Lookup Settings" tab. Rather populate it on the "Drop Settings" tab. (Just enter the Male and Female options there.)

[aside: you get bonus points for putting Female first, as you did in your Queue.]

the only other anomaly I can see is that you set the prompt of the hidden "loc:hash" field to be a ':'. This seems unnecessary and makes the form look a bit weird.

Cheers
Bruce


 

[trent]

Hi Bruce,

Item 3 - the queue was just for demonstrating purposes. We are actually using a MS SQL table in the live app and this issue is occurring with the MS SQL table drop. In the live app the drop is hidden until the user enters their Username and Password, then hits 'Login', the form goes through 'ValidateUpdate > End', if the user needs to select something from the drop then the form is set to retry, a SSV is set and the drop is unhidden. Could you shed some light on why this would be happening on a MS SQL table drop?

Forget about the prompt for the hidden 'loc:hash' field - this is exactly what was set in example number 3 'BasicWithLogin'. Maybe the example needs updating

Items 1 and 2: I really need you to replicate this. I get it straight away when testing on an iPhone 4S with iOS 8.1.3 using Safari. My colleagues get this on their iPhones too. Demo'ing to customers and having this happen on multiple devices is not acceptible. I can definitely replicate this issue on the demo app and also my live app. Would you like a video?

Regards,
Trent

[Bruce]

>> the queue was just for demonstrating purposes.

ok, I've updated the example to use the drop settings, and it seems fine.

>>  In the live app the drop is hidden until the user enters their Username and Password, then hits 'Login', the form goes through 'ValidateUpdate > End', if the user needs to select something from the drop then the form is set to retry, a SSV is set and the drop is unhidden.

So this sounds like a very different sequence to the example. Perhaps the best option is to set up the example to follow the same pattern?

>> Could you shed some light on why this would be happening on a MS SQL table drop?

I suspect it's unrelated to SQL, and more likely to be related to your sequence of retries and unhides and so on. (My gut feel is that your process for unhiding or hiding this field sounds over-complicated.)

>> Items 1 and 2:  I can definitely replicate this issue on the demo app and also my live app. Would you like a video?

A video would "prove" it's happening, but would not assist with solving the problem. Given that I _believe_ it is happening (clearly you're not just making this up), we need to progress to where I can duplicate the problem, and hence have something to recommend or fix.

Clearly if you are getting it, and I am not, then more data needs to be accumulated. Key to this is determining that you still get the effect using the _example_ program. Once you're getting the effect in the example you can then narrow down the scope of the example to better understand what might be causing it.

Often it's illuminating to know where the problem does _not_ occur, as well as where it does. From my text, my phone is currently on iOS 7. Do you get the same problem on iOS7 devices? Do you get it on android devices? Do you get it in desktop browsers? What Nt build are you on? If we can figure out the differences then there's more chance of me duplicating it.

So the best way forward is not a video, but rather a narrowing of the scope of the problem.

Cheers
Bruce

[trent]

Hi Bruce,

I've updated the app to demonstrate how the drop field is hidden and unhidden. The results are the same and I am still able to replicate all 3 issues. New app attached.

Using NT8.57.

Don't have any iOS 7 or below devices to test with.

Only item 3 is happening in both desktop and mobile mode on Windows 7, 8.1, Mac OSX and iOS 8, using IE, Firefox, Safari and Mobile Safari. Does not happen on Chrome for Android (don't have Chrome on my desktop).

Items 1 and 2 are only happening in mobile mode on an iPhone. Don't have any Android phones to test with, or Windows phones but my Android tablet using Chrome for Android does not have these problems.

Item 1 is very easy to replicate. Just go to the login screen in mobile mode on a phone, and press the 'Login' field. You may need to refresh the page first to see the issue.

Item 3 happens every single login for me.

Regards,
Trent

[attachment deleted by admin]

[Bruce]

Hi Trent,

Let's knock off one thing at a time. Item 3 is the one which happens in desktop browsers (for you), so let's deal with that one first.
I'm on windows 7 here, and I've got all the browsers - but Firefox is the easiest to debug in, so let's concentrate on that.

What I did was this,
Run Exe.
In Firefox go to http://127.0.0.1:88/
click login button
login screen opens - demo / demo populated. I click Remember Me to yes.
Then Login button.

the page refreshes, login and password are still there, Site field has appeared. It's a drop-down with Sydney and Melbourne. I select Melbourne.

In Firebug Console (firefox extension) I see a request is made to the server, and a reply comes back. The reply includes the <select > box, and also the 3 options, the Melbourne one is marked as "selected".

I then click Login again and I'm logged in.

Perhaps try it on your side, in a new clean folder, and see if you get the same, or if you diverge from the path I've explained above. Clearly there is a difference in what you are doing and seeing to what I am, and identifying that difference is very important to understanding why you are having problems.

As an aside, I performed the same path on the phone, and got the same results - so I don't think this item is a desktop / mobile thing.

As another aside, I'm going to discuss this example in the webinar today (_if_ I remember <g>). I know it's a horrible time of day for you, but maybe grab the recording. I think perhaps the work-flow of this screen could be improved a lot and I'd like to show how that works. Needing to press the login button twice is a very ugly approach from a UI point of view, and I want to demonstrate how you might tweak it to work better.

cheers
Bruce

[trent]

Have you tested on an iOS 8 device?

[trent]

Here is a video of item 3 in action. Change the file extension to mp4.

EDIT - this is actually item 2.

[attachment deleted by admin]

[trent]

Video for item 1 is attached. Change the extension to mp4 to view.

[attachment deleted by admin]

[Bruce]

Hi Trent,

We're gonna have to start a new thread - this one is about to max out and it becomes a real pain to work with.

I haven't tested on ios 8 yet, because I'd like to resolve item 3 first. Resolving items often has a cascading effect, so fixing the ones that are wildly duplicateable often has the knock-on effect of fixing other things as well. You indicated item 3 was easier to reproduce, so I've started with that.

Alas your mp4 files (even after renaming the extension) are not playable. I suspect a file size limit on these forums - maybe post a link on drop box or something. Of course a video serves no actual purpose, a video showing it not working on your machine is as useless to me as a video of it working on my machine would be to you.

I have a suspicion that the problems you are encountering are a side effect of the way you are using retry. So the best fix is simply to remove that approach. It's a bad approach anyway from a UI point of view, so I'll be suggesting a different approach in the webinar.

Cheers
Bruce