Home → Beta Testing →

Unexpected Keyboard and Screen Display/Behavior/Black Rectangle 6 Plus

• Edit

Howard

25 Aug, 2018 05:58 PM

Unexpected Keyboard and Screen Display/Behavior with regard to Document Options on iPhone 6 Plus

MMD Composer Build 51 and iOS 11.4.1

My Document Options are as follows:

• Editing Options
  • None selected
• Document Appearance
  • Editor Theme is Default
  • Preview CSS is Github
• Assistants
  • All Assistants enabled except Document Preview

1. Phone is in a Vertical Position
   
2. Keyboard is deployed as though composing. Seeing this in both Compose Mode as well as Preview Screen
   

3. Tap Document Options on the toolbar

4. The behavior I am referring to, Black Band instead of the Keyboard seems to, in my experience, occur in one-of-two ways:

   • Toggle Document Preview to tbe On position and return to your document or preview

     — or —-

   • Make any or no adjustments and return to the document and/or preview

5. Black Bar where one might expect to find a keyboard

A few thoughts on this:
- Trying to move the secret decoder black keyboard down does not remove the black bar - As that is the manner in which the keyboard is dismissed - one might think that would clear it up - Pressing on the compose window as though you were to begin typing/editing dismisses the Black Rectangle and generates the Keyboard

Somewhat Unrelated but Also Unexpected Behavior

• Changing the Default Font Size and pressing Done seems to freeze MMD Composer

  • The remedy appears to be to exit the App by pressing _Touch-ID_in order to then tap the MMD Composer App icon and relaunch
    • File size depending - the Application does seem to recover
    • If I recall correctly, a larger file will make MMD Composer unrecoverable withoit dismissing/ killing the app
    • Uncertain how this is treated or remediated without Touch-ID

• If the user has Show Preview turned Off in Document Options and Settings —> _Preview ...should the user be able to generalize a Preview pane?

Obviously Document Preview is an excellent tool. Especially as one gets closer to export. Yet sometimes, when writing or proofing a section, I liket to see the words. And I find myself inadvertently triggering the Document Preview.

• 95028601-691C-48E9-9CB0-C7CE7DAB541A.png 194 KB

1. Support Staff 1 Posted by Fletcher on 05 Sep, 2018 01:07 AM

   

   Sorry for the delay -- "real life" has intruded on my development time lately.

   1. By watching vary carefully, you'll notice that the keyboard starts to descend when you tap the preferences button. Before the keyboard is completely offscreen, the new window slides upward, obscuring the editor view. I think that what is happening is that when the editor is hidden behind another window, it stops receiving commands to adjust its size? The keyboard continues sliding off screen, but the editor is no longer notified of the changes. That "black band" isn't actually "there". What you're seeing is that the editor frame no longer extends to the bottom of the screen because it wasn't informed that the keyboard continued to move. The only way to notify it to change is to cause the keyboard to change again, which means to begin editing the document. It's amazing that this many years after the iPhone was created that there is not a built-in solution to iOS to handle adjusting the visible "window" based on whether the keyboard is visible or not. I'll keep working to improve it.

   2. How long of a document are you testing this on (changing default font size)? It works fine for me, but there is a delay that goes from imperceptible to longer as Composer reapplies formatting to the entire document since you changed file size. For example, on my iPhone 6S, a 107k character document takes 4 seconds or so to reapply highlighting. That is longer than it takes for me to open the same document, so perhaps it is applying the formatting twice? But it still opens for me.

   3. I'm not sure I follow you -- Settings refers to whether a preview should be displayed when a new document is opened. The document options refers to whether a preview should be visible right now. In either case, you can always manually toggle the preview on or off by sliding the appropriate direction. Under what circumstances do you inadvertently trigger a preview?

   Fletcher

   • Edit

2. 2 Posted by Focus on 10 Sep, 2018 10:51 AM

   
   
   

   
   On Sep 4, 2018, at 9:07 PM, Fletcher <[email blocked]> wrote:
   
   

   pre { width: 92%; margin: 10px 2%; padding: 5px 2%; background: #efefef; border: 1px solid #d6d6d6 } blockquote { margin-left: 0; padding-left: 1em; border-left: 5px solid #ccc; }

   Fletcher,  Sorry for the delay as well. Had hoped to respond over the weekend.   1. I thought about your response regarding the keyboard. I examined other apps I typically use in order to gauge their handling of the keyboard with regard to the black band ‘visual’.  My assessment is that it is amazing that in 10 years there is not a more elegant solution to deal with the issue.  - Drafts-4: it appears to me that any effort to change a setting or gain access to any action automatically clears the keyboard  - Ulysses: any attempt to access settings from within a sheet or any attempt to export from within a sheet automatically retracts the keyboard.  There does appear to be one app in my repertoire that does appear to be be able to handle retaining both - although I’m not certain I’m comparing apples-to-apples.  Within **Editorial**, while working on a document you can press a wrench to access your workflows. Although any attempt to edit a workflow or reach the setting page does indeed retract the keyboard.  2.  Unfortunately, I am unable to answer this question with certainty. Also, as the  TestFlight has expired I am unable to recreate. My memory is usually accurate. That said, I’m going to say it was virtually any document — perhaps no bigger than the bug reports I had posted.  With regard to outright being unrecoverable - where the remedy was to kill the app and restart. This may have been a more complex file - perhaps roughly 300kb file.   3.  If both options for ‘Preview’ are set in the ‘off’ position my expectation would be that under no circumstances would the user be able to trigger a ‘preview’. The user would be stuck perpetually in ‘composer’ mode. My intent was to not generate a ‘preview’. Both options were in the ‘off’ position. Nevertheless, I was still receiving a ‘preview’.  Please let me know if I can provide additional details or clarification of any kind. If you do not have access to the above apps I can forward or upload videos of their keyboard actions.  Thank you.  ================================================== From: Fletcher (Support staff) Sorry for the delay -- "real life" has intruded on my development time lately. By watching vary carefully, you'll notice that the keyboard starts to descend when you tap the preferences button. Before the keyboard is completely offscreen, the new window slides upward, obscuring the editor view. I think that what is happening is that when the editor is hidden behind another window, it stops receiving commands to adjust its size? The keyboard continues sliding off screen, but the editor is no longer notified of the changes. That "black band" isn't actually "there". What you're seeing is that the editor frame no longer extends to the bottom of the screen because it wasn't informed that the keyboard continued to move. The only way to notify it to change is to cause the keyboard to change again, which means to begin editing the document. It's amazing that this many years after the iPhone was created that there is not a built-in solution to iOS to handle adjusting the visible "window" based on whether the keyboard is visible or not. I'll keep working to improve it. How long of a document are you testing this on (changing default font size)? It works fine for me, but there is a delay that goes from imperceptible to longer as Composer reapplies formatting to the entire document since you changed file size. For example, on my iPhone 6S, a 107k character document takes 4 seconds or so to reapply highlighting. That is longer than it takes for me to open the same document, so perhaps it is applying the formatting twice? But it still opens for me. I'm not sure I follow you -- Settings refers to whether a preview should be displayed when a new document is opened. The document options refers to whether a preview should be visible right now. In either case, you can always manually toggle the preview on or off by sliding the appropriate direction. Under what circumstances do you inadvertently trigger a preview? Fletcher On Sat, Aug 25 at 10:58 AM PDT, Howard wrote: Unexpected Keyboard and Screen Display/Behavior with regard to Document Options on iPhone 6 Plus MMD Composer Build 51 and iOS 11.4.1 My Document Options are as follows: Editing Options None selected Document Appearance Editor Theme is Default Preview CSS is Github Assistants All Assistants enabled except Document Preview Phone is in a Vertical Position Keyboard is deployed as though composing. Seeing this in both Compose Mode as well as Preview Screen Tap Document Options on the toolbar The behavior I am referring to, Black Band instead of the Keyboard seems to, in my experience, occur in one-of-two ways: Toggle Document Preview to tbe On position and return to your document or preview — or —- Make any or no adjustments and return to the document and/or preview Black Bar where one might expect to find a keyboard A few thoughts on this: - Trying to move the secret decoder black keyboard down does not remove the black bar - As that is the manner in which the keyboard is dismissed - one might think that would clear it up - Pressing on the compose window as though you were to begin typing/editing dismisses the Black Rectangle and generates the Keyboard Somewhat Unrelated but Also Unexpected Behavior Changing the Default Font Size and pressing Done seems to freeze MMD Composer The remedy appears to be to exit the App by pressing _Touch-ID_in order to then tap the MMD Composer App icon and relaunch File size depending - the Application does seem to recover If I recall correctly, a larger file will make MMD Composer unrecoverable withoit dismissing/ killing the app Uncertain how this is treated or remediated without Touch-ID If the user has Show Preview turned Off in Document Options and Settings —> _Preview ...should the user be able to generalize a Preview&n (truncated)

   • Edit

3. Support Staff 3 Posted by Fletcher on 10 Sep, 2018 11:40 PM

   

   Testflight was updated. You should be able to use it.

   I'll keep testing with long documents to see what I can find.

   As for preview -- the settings refer to whether the preview is shown by default, and the document options allow you to toggle visibility if you can't remember (or didn't know about) the ability to swipe. Neither of them prevents you from using the preview. It will always be a possibility should you want it.

   My question is what causes you to accidentally trigger the preview to happen? Is there a certain set of circumstances that occur?

   • Edit