-
Notifications
You must be signed in to change notification settings - Fork 2
iOS Notes
A few challenges arise when attempting to put control system screens on an iPhone (iOS):
Bug Tracker: https://bugs.webkit.org/show_bug.cgi?id=80362
We want a simple login requirement to ensure only lab staff are viewing the control system screens.
The work around is to use a session to store an authentication token instead of relying on the HTTP Authorization header. This is a pain in the neck if you just want to use simple HTTP Basic auth in the first place. Form authentication with a session becomes more complicated - and leads to other bugs like these using Apache:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56098
https://bz.apache.org/bugzilla/show_bug.cgi?id=61161
https://bz.apache.org/bugzilla/show_bug.cgi?id=54280
Bug Tracker: https://bugs.webkit.org/show_bug.cgi?id=153887
Note that this isn't a problem with Android or other touch environments.
The work around is to ensure that elements in the DOM that should allow click events have css rule "cursor: pointer" applied. This is odd since a style dictates behavior and on a mobile touch device there isn't even a cursor visible. We are attempting to mimic EDM, which never shows a pointer (hand) cursor so on devices in which a cursor does appear we would prefer that the cursor is the default. Detecting iOS is not straight forward as the User Agent header is notoriously spoofed (IE 11 claims to be an iPhone). A generally better approach is to detect features, such as touch events. However, there is not a good way to detect whether the device supports mouse events too, and it is possible to have a PC that supports both touch and mouse. Pick your poison. Currently WEDM simply detects whether the device supports touch and if so adds the cursor rule. If not iOS, but Android or some other touch device the rule should do no harm as generally touch devices don't show cursors. If on a PC with both touch and mouse support then I guess you'll see a pointer cursor. Oh well.
3. Safari in iOS navigation bars dynamically show and hide in challenging ways + scroll changes viewport + reported viewport height incorrect
If you want to have a full screen app without scrolling on iOS Safari good luck.
https://bugs.webkit.org/show_bug.cgi?id=170595
https://bugs.webkit.org/show_bug.cgi?id=141832
https://www.eventbrite.com/engineering/mobile-safari-why/
https://stackoverflow.com/questions/24889100/ios-8-removed-minimal-ui-viewport-property-are-there-other-soft-fullscreen
https://github.com/hashchange/jquery.documentsize#what-does-it-do-that-jquery-doesnt
https://github.com/alvarotrigo/fullPage.js/issues/2414
This is a problem with mobile in general in that there is a lot of connecting and disconnecting going on. However, there seems to be a large delay cleaning up old connection which prevents a new connection from being created. More investigation needed, but it seems you sometimes find yourself reloading the page to try to get the websocket to connect.