FWD » Core Development » User Interface

Please test the web client from the Safari browser. Report any found issues here. Resolve those issues. Anything risky can be posted here as a diff. If the changes are not risky, they can be directly checked into 1811t.

For testing, please run through the standalone GUI testcases list (the same ones we use for regression testing GUI). All testing should be done on branch 1811t.

Committed revision 11044(3084a) substitutes "const" statements to "var"s. Encountered new issue that self-signed certificates aren't supported by Web Socket Client API implemented by Safari (OS X El Capitan 10.11 on the Mac mini)

[Error] WebSocket network error: OSStatus Error -9807: Invalid certificate chain 
[Error] Connection closed with the returned code 1006
    error (p2j.screen.js:2943)
    onclose (p2j.socket.js:2561)

19/05/16 19:39:29,940 com.apple.WebKit.WebContent[965]: CFNetwork SSLHandshake failed (-9807)
19/05/16 19:39:29,995 com.apple.WebKit.WebContent[965]: NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9813)
19/05/16 19:39:29,997 com.apple.WebKit.WebContent[965]: [19:39:29.997] HTTPRequest figHttpRequestDidFailCallback: Network error: domain=kCFErrorDomainCFNetwork, code=-1202, Error Domain=kCFErrorDomainCFNetwork Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be �192.168.1.35� which could put your confidential information at risk." UserInfo={NSErrorFailingURLStringKey=https://192.168.1.35:7449/common/beep.wav, NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFNetworkCFStreamSSLErrorOriginalValue=-9813, kCFStreamPropertySSLPeerCertificates=(
    "<SecCertificate 0x7fa4c1eae380 [0x7fff77d64440]>",
    "<SecCertificate 0x7fa4c1eab510 [0x7fff77d64440]>" 
), _kCFStreamPropertySSLClientCertificateState=0, kCFStreamPropertySSLPeerTrust=<SecTrust 0x7fa4c1eb2a30 [0x7fff77d64440]>, NSLocalizedDescription=The certificate for this server is invalid. You might be connecting to a server that is pretending to be �192.168.1.35� which could put your confidential information at risk., _kCFStreamErrorDomainKey=3, NSErrorFailingURLKey=https://192.168.1.35:7449/common/beep.wav, _kCFStreamErrorCodeKey=-9813} for https://192.168.1.35:7449/common/beep.wav
19/05/16 19:39:30,000 com.apple.WebKit.WebContent[965]: [19:39:29.999] FigDCP_GetCacheFileVersion signalled err=-12540 (kFigDiskCacheProviderError_InvalidCacheFile) (unsupported file version) at /Library/Caches/com.apple.xbs/Sources/CoreMedia/CoreMedia-1731.15.204/Prototypes/FigByteStreamPrototypes/FigLimitedDiskCacheProvider.c line 384

The P2J standard server certificate must be set as a trusted one at the first access to the login page. If it isn't done, then it needs to remove its identity from the Safari cache with help of Keychain Access.app. If the identity is removed, then accessing to the login page invokes the Safari to open the certificate warning dialog. I will provide images with instructions to follow later.

Committed revision 11045 fixed drawings of images. It seems that Chrome and Safari browsers have the same drawing issues due to they are WebKit-based browsers. Now I am using
https://www.nomachine.com/ to manage the parkland of devices. It can be installed on each computer in the local network (for Windows, Mac Os X, Linux, ...) and can be managed from the box without complicated settings.

For Safari CTRL + LETTER keystrokes raises keypress event with charCode that is calculated by ctrlCode = keyDownCode & 0xffbf.
Thus pressing CTRL+C invokes keypress with charCode=keyCode=which=3 and keypress can't be suppressed for CTRL+C, CTRL+V, CTRL+X, but it can be suppressed for CTRL+B as an example.
The copy, cut and paste actions are invoked by pressing COMMAND+C, COMMAND+X and COMMAND+V respectively, where the COMMAND key corresponds to the left window or to the right window key on Windows keyboards. The COMMAND key is detected by the metaKey event flag.
keyDownCode('C') & 0xffbf = 67 & 0xffbf = 0000 0000 0100 0011 & 0xffbf=0000 0000 0000 00011
Google Chrome and IE11 don't raise a keypress event for CTRL+C and Firefox yields keypress with charCode=99, otherwise Safari produces a keypress event with charCode=keyCode=which=3.

I didn't find special Progress 4GL rules to map COMMAND + key, where COMMAND is a LEFT_WINDOW key or a RIGHT_WINDOW key. These keys have the same code as '[' and ']' keys respectively. Thus we can map COMMAND+C, COMMAND+X and COMMAND+V to CTRL+C, CTRL+X and CTRL+V Progress 4GL keys codes, otherwise produce separate 4GL codes for pressing a COMMAND key and an any other key except 'C', 'X' and 'V'.
Constantin, what do you think it is a correct solution?

The other question is that should we map the others useful keyboard shortcuts to 4GL codes with the same meaning to be friendly with Mac OS users.
Please look at these shortcuts:
https://support.apple.com/en-us/HT201236
For an example, should we map COMMAND + LEFT_ARROW to HOME 4GL Progress code?

Greg, what do you think it is necessarily to map MAC OS shortcuts with new modifier key COMMAND to 4GL codes with the same meaning? For an example, to go to the end of a line we need to press COMMAND + RIGHT_ARROW, but for Windows and Linux we press END key.

The most different behavior of Safari can be observed if we press and hold some key. The Safari produces these codes if keydown events are suppressed

keydown  keyCode=83  (S)   which=83  (S)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keyup    keyCode=83  (S)   which=83  (S)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
textInput data=ß
ß

keydown  keyCode=65  (A)   which=65  (A)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keypress keyCode=97  (a)   which=97  (a)   charCode=97  (a)  
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
textInput data=a
akeydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keyup    keyCode=65  (A)   which=65  (A)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
textInput data=ā
ā

The repeat keys behavior of Safari can be observed if we access a physical keyboard of the target device. In the case of NoMachine GUI client pressing and holding one key produces fake keys up events.

The described in notes 12 and 13 Safari behavior is related to the different input sources. For my environment English and Russian are installed.

It looks like a system bug because switching input sources and removing additional ones can produce correct browser events without the select char dialog if keydown events are suppressed

keydown  keyCode=67  (C)   which=67  (C)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keyup    keyCode=67  (C)   which=67  (C)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=67  (C)   which=67  (C)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keyup    keyCode=67  (C)   which=67  (C)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keydown  keyCode=67  (C)   which=67  (C)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keyup    keyCode=67  (C)   which=67  (C)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined

keydown  keyCode=67  (C)   which=67  (C)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keypress keyCode=99  (c)   which=99  (c)   charCode=99  (c)  
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
textInput data=c
ckeydown  keyCode=229       which=229       charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
keyup    keyCode=67  (C)   which=67  (C)   charCode=0        
         shiftKey=false ctrlKey=false altKey=false metaKey=false
         key=undefined char=undefined location=0 repeat=undefined
textInput data=ç
ç

There are graphical keyboards settings: Key Repeat and Delay Until Repeat, but the keyboard type is selected with the help of the wizard by listening the user's input on the target requested keys. At the moment I don't know how to deal with char select dialog, but the other differences can be overcome.

Planning to rebase 3084a.

I didn't find special Progress 4GL rules to map COMMAND + key, where COMMAND is a LEFT_WINDOW key or a RIGHT_WINDOW key. These keys have the same code as '[' and ']' keys respectively. Thus we can map COMMAND+C, COMMAND+X and COMMAND+V to CTRL+C, CTRL+X and CTRL+V Progress 4GL keys codes, otherwise produce separate 4GL codes for pressing a COMMAND key and an any other key except 'C', 'X' and 'V'.

The 4GL has never been available on MacOS. Thus, it doesn't have any matching values that we can test and implement. For this reason, we want to make a direct and simple (at least as simple as possible) mapping between what is possible on the Mac keyboard to what is needed in the 4GL.

For example, can we map COMMAND to the CTRL key (for everything, not just for cut/copy/paste)? If this is possible, then it can be an easy thing for a user to understand and use.

Yes, planning to map COMMAND to CTRL by processing COMMAND + keystrokes as it is CTRL+keystrokes.
3084a is rebased to revision 11061 from trunc 11040.

Yes, planning to map COMMAND to CTRL by processing COMMAND + keystrokes as it is CTRL+keystrokes.

OK, good. After doing this, we must not re-use COMMAND as some other replacement (e.g. COMMAND + RIGHT_ARROW = END) since CTRL + RIGHT_ARROW will have an expected set of key events that may be generated.

What is the list of keys on the standard PC keyboard that cannot be represented using the Mac keyboard?

Yes, planning to map COMMAND to CTRL by processing COMMAND + keystrokes as it is CTRL+keystrokes.

OK, good. After doing this, we must not re-use COMMAND as some other replacement (e.g. COMMAND + RIGHT_ARROW = END) since CTRL + RIGHT_ARROW will have an expected set of key events that may be generated.

What is the list of keys on the standard PC keyboard that cannot be represented using the Mac keyboard?

Do you mean that if we replace COMMAND by CTRL, then COMMAND+RIGHT_ARROW action becomes CTRL+RIGHT_ARROW and can't represent its MAC OS X action to move the insertion point to the end of the current line. There are many such keys if we follow this document https://support.apple.com/en-us/HT201236, but there are common actions such that CTRL+F, CTRL+C, CTRL+X, CTRL+V.

Do you mean that if we replace COMMAND by CTRL, then COMMAND+RIGHT_ARROW action becomes CTRL+RIGHT_ARROW and can't represent its MAC OS X action to move the insertion point to the end of the current line.

Yes, I mean exactly this.

The 4GL has some important CTRL + combinations that must be supported. Individual apps can and do assign their own key events that depend on the CTRL key. We can't arbitrarily map COMMAND + to other Mac-specific events because this can "hide" 4GL or application events.

There are many such keys if we follow this document https://support.apple.com/en-us/HT201236, but there are common actions such that CTRL+F, CTRL+C, CTRL+X, CTRL+V.

We don't need to support the common Mac key combinations. I am only worried about supporting the 4GL processing that is needed.

I guess OPTION needs to be used for ALT?

How does one do F1 - F12? How to do HOME, END, INSERT, DELETE, BACKSPACE, PAGE-UP, PAGE-DOWN...? These are things that the 4GL will depend on, since the 4GL was designed for PC keyboards. Don't worry about doing things "the Mac way". We only need to worry about how a user can properly use the converted 4GL app.

I guess OPTION needs to be used for ALT?

Yes.

How does one do F1 - F12? How to do HOME, END, INSERT, DELETE, BACKSPACE, PAGE-UP, PAGE-DOWN...? These are things that the 4GL will depend on, since the 4GL was designed for PC keyboards. Don't worry about doing things "the Mac way". We only need to worry about how a user can properly use the converted 4GL app.

Safari generates the same codes as Firefox for keys from F1 to F12, the default actions on these keys can be prevented on keydown events. Pressing these keys ALT, HOME, END, DELETE, BACKSPACE, PAGE-UP, PAGE-DOWN produce keydown and keyup events, but these keys BREAK, Scroll Lock and Print Screen keys don't generate any event for Safari and can't be detected. Pressing Insert generates only keyup event. LEFT, UP, RIGHT, DOWN arrows, ESC, ENTER can be detected. Caps Lock throws only one event depending on its state. In my environment I encountered the following autorepeat problem that sometimes pressing and holding the typed key produces incorrect sequence (note 15). It looks like a keyboard driver bug or incorrect software configuration. I think the required keys and their combinations can be correctly detected.

These commands document.execCommand("copy|cut|paste") are not supported by Safari, thus we must prompt a user to use keyboard shortcuts: COMMAND+C, COMMAND+X, COMMAND+V.

It seems that Safari sends keyDown events with 229 key code for autorepeats. http://stackoverflow.com/questions/25043934/is-it-ok-to-ignore-keydown-events-with-keycode-229

It seems that this document demystifies the root of the 229 code https://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0182/keyCode-spec.html

Now working on the note 29 to detect the font height correctly using offscreen canvas. The tests to detect the first and the last valuable (white) pixel on the offscreen canvas are not passed.

Found an interesting Safari feature to draw vertical line '\u2502' on the offscreen canvas for the '12px monospace' font and the default line style it uses alpha channels only. Thus
the offscreen canvas image data contains these types [0,0,0,*] of pixels. Prepared simple algorithm that takes into account the mean and variance of horizontal pixels distribution in order to calculate the font height correctly.

Greg, please review the committed revision 11068 (3084a). This task is ready.

Code Review Task Branch 3080a Revision 11068

Wow! That is a lot of work. Good job.

1. In p2j.screen.js, the fontMetrics constructor function uses

      fontCanvas.height = height;
      fontCanvas.width  = width;

instead of the previous approach:

         fontCanvas.setAttribute('height', height);
         fontCanvas.setAttribute('width', width);

What do we lose or gain by this change?

2. Did you create the new font metrics approach from scratch? It is an interesting approach.

3. The old font metrics approach had a manual adjustment for windows platforms, which has been removed. Is that intentional?

4. For what platform + browser combinations have you tested the new font metrics approach?

5. In SystemAction, please split the class definition (public class SystemAction extends MouseWidgetAction) into 2 lines.

6. HandleCommon and HandleOps are each missing a history entry.

7. Please add javadoc to focusHiddenInputField() in p2j.clipboard.js.

8. Please cleanup the debug code and unnecessary commented code in p2j.screen.js.

1. In p2j.screen.js, the fontMetrics constructor function uses
instead of the previous approach:
What do we lose or gain by this change?

It is shorter and CanvasRenderer.prototype.resize already uses this short form. It works with IE, Firefox, Chrome and Safari.

2. Did you create the new font metrics approach from scratch? It is an interesting approach.

I use mean and variance approach because antialiasing transforms pixels so that they become colored in gray colors and to detect a char height it needs to take into account only valuable pixels. As an example, the vertical char '\u2502' has only 10 valuable pixels for '12px monospace' in Safari but the other pixels are faded. Otherwise, in Firefox '\u2502' has 13 valuable pixels.

3. The old font metrics approach had a manual adjustment for windows platforms, which has been removed. Is that intentional?

Yes.

4. For what platform + browser combinations have you tested the new font metrics approach?

I tested these changes with IE, Firefox, Chrome and Safari. Planning to rebase 3084a and to fix 5, 6, 7, 8.

I uses mean and variance approach because antialiasing transforms pixels so that they become colored in gray colors and to detect a char height it needs to take into account only valuable pixels. As an example, the vertical char '\u2502' has only 10 valuable pixels but the other pixels are faded.

Please add this information as a comment in the fontMetrics object. It really helps one understand why the approach was taken.

Sergey, one question about 3084a: in p2j.js createKeyEvent, you have a finally block which uses an event object which may have been created in a catch block:

            catch (ex2)
            {
                event = document.createEvent("UIEvents");
            }

I used here the code from YUI library https://github.com/yui/yui3/blob/master/src/event-simulate/js/event-simulate.js . It seems that it is a Safari use case.

Committed revision 11070 (3084a) fixed 5-8 and added comments to fontMetrics. 11069 revision is a rebase from the 11041 trunc revision. I tested these combinations:
IE11 and Window7 32-bit, Chrome, Firefox and Ubuntu 15.10, Safari and Mac OS X El Capitan 10.11.5.

Zooming 4 times this picture helps to observe that a vertical char consists from 3 parallels and the middle line is lighter than its neighbors. Thus its height must be smaller than used char height to draw cells. It needs to investigate thoroughly.

Code Review Task Branch 3084a Revision 11070

The changes are good.

Constantin Asofiei wrote:

Sergey, one question about 3084a: in p2j.js createKeyEvent, you have a finally block which uses an event object which may have been created in a catch block:
[...]
This assumes that the UIEvents event will always be created, and never fai: why is this valid? Which browser does the catch target? If document.createEvent("UIEvents"); fails, won't event be undefined in the finally block?

I agree that this code should be written to be more explicitly safe. Even if it works reliably now, we are depending on certain browsers to always return something in the catch case, which may break over time as the browser support changes.

If the browser API is changed, then this function is failed now. It can be changed to return null object without throwing any exception. In any case we are failed with repeats keys in that case, because this function is used now for the Safari use case only.

If the browser API is changed, then this function is failed now. It can be changed to return null object without throwing any exception. In any case we are failed with repeats keys in that case, because this function is used now for the Safari use case only.

Agreed. Please go ahead with protection code in the finally to not throw an exception but to "fail gracefully". It will still fail, but readers of the code will understand that we have planned accordingly AND it will be easier to see the reason.

Sergey Ivanovskiy wrote:

I detected the same problem that appears using Safari on Google Chrome ver. 50.0.2661.102 and Win7 32-bit image. The issue is char '\u2502' is uniformly faded so it can be detected by the mean and variance rough method. It requires a more sensitive approach. Please look at the picture.

The last Chrome issue is related to that the cell width is not whole number and it causes these artifacts due to the different Canvas API implementations. I think it is not succeeded if we continue to draw chars to display boundaries.

We use dx = ctx.measureText('\u2500').width; to calculate the cell's width.

For the Chrome on Win7 - 32 bit the horizontal char '\u2500' width is 6.59765625 for the "12px monospace" font and horizontal chars are displayed on the canvas with gaps. The gaps also appear if we round this value to the closest integer 7. But for the Safari the horizontal char '\u2500' width has 7.201171875 pixels rounded to 7. And it gives the vertical gaps only (fixed by drawing two vertical chars), but without rounding we can observe horizontal and vertical gaps. The Chrome on Ubuntu 15.10 gives 7.224609375 and only the Firefox on Ubuntu 15.10 and IE11 on Win7-32bit both give the whole number 7. We can try to rework this approach if we add an attribute to each cell that describes a target cell is a boundary or not. It gives a possibility to use graphics instead of chars drawings.

Greg, would you prefer that this task should be done in the separate task or it should be done here?

would you prefer that this task should be done in the separate task or it should be done here?

Please create a new task. Please include zoomed screen-shots of each issue.

Committed revision 11071. It needs to rebase to 11042 trunc and to check menu functionalities.

Code Review Task Branch 3084a Revision 11072

The changes are good.

Task branch 3084a was merged to trunk as revision 11045 and that revision contains the changes that resolve this task.