Known Issues

A few known issues have longer articles:

If applicable, the OS X version number will be printed before the bug title, such as the following, "[10.11]", which means this bug should only appear in OS X 10.11 "El Capitan". "[10.9.3+]" would indicate any version of macOS since 10.9.3 Mavericks.

[10.11.2] Crashing on Project Load (Full Screen)

Symptoms

Projects attempting to make use of Mac OS X's Full Screen mode upon load can cause Scrivener to crash. Projects on the same machine that were not in Full Screen mode the last time they were closed will open normally.

Crash logs for this type of bug can be identified by searching for the following text:

Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN: [nan nan]'

If in the following numbered sequence of lines you see references to NSFullScreenTransitionOverlayWindow or startEnterFullScreenAnimationWithDuration, then your project is subject to this bug.

Cause

The bug appears to be entirely confined within Mac OS X's internal code for animating a window to its a dedicated Full Screen "Space". Why this happens for only some programs and not others, and why it hasn't impacted all 10.11.2 computers is unknown. If you have any information on configuration options or installed software that makes a difference in the reproduction of this bug, we would be delighted to hear it. To date we have not been able to trigger this bug in-house.

Work-around

Opening a project that is stuck in Full Screen mode

Since the problem is with opening a window in Full Screen mode, the solution is to make it so that the project you are trying to open does not request this mode. Scrivener stores this setting inside the project itself. There are three ways to fix this problem:

  1. The easiest option will be to try opening the project on another Mac, especially any Mac not running OS X 10.11.2. Once the project is open, remove the project from Full Screen mode, close it, and copy the updated version of the project to your main Mac. It should now open in a regular window and not crash.

  2. Reset the project's settings by removing the settings file from the project:

    1. Right-click on the project in Finder and select Show Package Contents from the contextual menu. This will open a window to the project's internal files.
    2. Drill down into the "Settings" sub-folder.
    3. Drag and drop the ui.plist file to your Desktop.
    4. Close the project package window and try loading the project again.

      Important: your project display settings will be reset. If you use this method you will need to set up options such as whether labels tint icons, outliner columns, index card sizes, split views and other settings. If you would prefer a less "scorched earth" fix than this, then read on.

  3. Remove the setting from the file:

    1. Follow the instructions for method (2) above, up to but not including step 2-3. Instead, drag a copy of this file to your desktop as a backup.
    2. Open the ui.plist file in the Settings folder using a plain-text editor such as TextEdit.
    3. Search for the phrase, MainWindowIsFullScreen. You should encounter two lines:

      <key>MainWindowIsFullScreen</key>
      <true/>

    4. Remove the above lines from the file, save it and close it.

    5. Close the project package window and try loading the project again. Depending on your settings, you may need to toggle the visibility of the Binder and Inspector as desired, as default settings may hide these panels while in Full Screen mode.

Avoiding the problem in the future

Since the problem is in triggering Full Screen mode upon project load, making sure to always leave the project in standard mode before closing or quitting the software will ensure you never run into the problem. One can either do this before closing, or just avoid using Full Screen mode entirely until the bug is fixed.

[10.8+] Crashing When Closing a Project

Symptoms

If you get a crash report upon loading Scrivener and don't remember any crashes, or if you've noticed that Scrivener crashes when closing a project, then you might have experienced this minor bug that can in most cases be simply ignored.

Cause

The crash itself involves general low-level macOS code, the sort of stuff that Scrivener depends upon to run. We can't really say for sure what has crashed, but given the nature and timing of it, we are certain it does not crash while the project is still open. More likely it is after the window has been removed from your screen and the Mac is running what maintenance it needs to, after such an event occurs.

The important thing to know is that this is a relatively benign crash, as crashes go. Since the project is closed when the crash occurs, there is very little risk to the project itself.

Work-around

There is no known work-around that will reliably avoid this problem. Some people have noticed that it seems to happen more frequently when clicking on the red "X" button to close the project window, as opposed to using the menu command or Cmd-W. Whether that holds true for everyone isn't known, but given the quantity of independent reports suggesting that correlation, adjusting your habits in how you close projects may help.

Status

Given the nature of the bug being in macOS itself, we know of no way to fix this. It is possible that once Scrivener is upgraded to a 64-bit architecture that it will cease to be a problem.

[10.11] Audio Playback Impacted by Cursor Navigation in Opposite Split

Symptoms

When viewing any multimedia document (such as an audio file or movie) in one split, while typing in a second split, attempts to use certain keyboard shortcuts that would adjust audio playback (such as Cmd-LeftArrow and RightArrow) will be stolen by the playback view, instead of moving the cursor in the active text editor (Cmd-Arrows would move to the beginning or ending of a line, normally).

Cause

The flaw is in the QuickTime player component itself, and there is nothing Scrivener can do to fix the problem.

Work-around

There are no known work-arounds at this time, short of somehow removing the conditions (such as viewing something else in the split) that cause various shortcuts to be "stolen" by the player.

[10.10+] Composition Mode does not fade other monitors

Symptoms

When using multiple monitors, the option to blank out secondary screens when using Composition Mode does not work properly, causing a flicker and then resumption of normal display on secondary monitors, or no change at all.

Status

The source of the problem has been identified and will be fixed in a future version of Scrivener (though given the scope of the changes, potentially to the 2.x line).

[10.6.8] PDFs in Mac OS X 10.6 (Snow Leopard) do not display properly

Symptoms

The PDF view will only display one page or part of one page, and attempting to scroll will have no effect (though the scrollbar may move), or in some cases the act of scrolling will produce visual garbage in the main viewer area.

Cause

The modern PDF display engine provided by Apple, and used in Scrivener 2.6 and newer, is not compatible with 10.6, and there is no way for us to create a version that has the incompatible PDF viewer replaced. This problem is entirely outside of our control, it is as best we can tell, and oversight in Apple's development tools not taking into account the considerations of older operating systems. Given the age of 10.6 at this point in time, we do not expect this problem to ever be fixed.

Workarounds

  • If the ability to reference PDF files in the editor is of critical importance to your usage of Scrivener, then the legacy version of Scrivener, version 2.5, can still be downloaded from our site.
  • If you never use PDFs in your projects, then the newer versions should be just fine for regular usage. Plus, if you don't necessarily need to see the PDF in Scrivener but use the project system to store and organise them, you can still open the PDF out of Scrivener using the Documents/Open/in External Editor (Ctrl-Opt-O) menu command.

Typing Lag in Main Editor

Symptoms

Typing speed in the main editor will lag behind actual key presses by a noticeable degree, such that if one types rapidly enough, the display of what they have written will take some seconds to catch up. The severity of the problem may vary from machine to machine. The software will be fine when it is first launched, but during the course of using it, something will happen to cause the lag to appear, once it does it will seemingly stay that way until restarting the software.

It is important to note that there are a few things that can cause typing speed to slow down in Scrivener, so if what you are experiencing does not precisely match the above symptoms then please contact us via support so we can help you with your individual case.

Cause

The bug is caused by a glitch in the Mac text engine and its subsidiary font panel. The bug has been reported to Apple, and we'll be using another method to scan for the font panel's presence that will avoid the most common bug triggers, but you may encounter a few that we cannot fix.

Workaround

To trigger this bug you will need three ingredients:

  • In the System Preferences: General pane, scroll bars need to be set to always shown.
  • The font panel itself must be resized from its original stock position on the screen, and the font preview feature needs to be enabled (you can hide the preview using the gear menu in the font panel itself).
  • One may need to right-click, at any point, into a text editor (there may be other triggers as well, but right-clicking polls the system for the font panel's position in order to set its menu labels, this is the part that will be fixed in Scrivener).

Thus if you can avoid any of those conditions, you should avoid the lag entirely. For most poeple, disabling the font preview feature in the font panel will be the best thing to do without.

Changing Editor Zoom Disrupts Ruler Markers

Description

When altering the zoom level of a text document in the main editors with the indent and tab ruler visible, the markers on the ruler may visually drift by small amounts. The key word is visually; the actual formatting will not be changed, and the visual problem can be fixed by simply toggling the ruler off and back on.

Cause

This bug originates within the Mac text engine's standard ruler supplied to third-party developers like ourselves. At this time we can do nothing to fix it and must wait for Apple to do so.

Work-Around

Simply toggle the visibility of the ruler off and back on to reset the markers to their correct positions. This can be done with the Cmd-R shortcut, or with the Format/Hide Ruler and Show Ruler menu commands.

[10.9+] PDF view acquires white rectangles

Description

When using the "Continuous" PDF display mode (where you can scroll through the entire PDF with the scrollbar or mousewheel), adjusting the view settings (such as zooming), and then using PgUp or PgDn a number of times can cause white rectangles to appear along the top or bottom of the view. This condition will be persistent once it appears, even after restarting Scrivener.

Cause

This problem originates from the PDF viewing engine itself (PDF Kit 32bit), which is being provided by Mac OS X. At this time we can do nothing to fix it and must wait for Apple to do so. We plan to update Scrivener to 64bit in the future, which will dodge the problem.

Work-around

Avoiding the use of "Continuous" mode, and selecting View/Media/PDF Display/Page Breaks so that only one page (or set of pages) is shown at once will avoid the problem entirely. If you are using 10.9, and find your PDF display "corrupting" with usage, you should consider using this alternate method of viewing PDFs.

Scratch Pad Undo Fails to Work

Description

While typing in the Scratch Pad editor, Undo (Cmd-Z) will stop working after pausing for a moment from typing.

Cause

Scratch Pad automatically loads changed files back off of the disk. It works this way so that synchronisation can be used to keep multiple computers using the same scratch pad notes. Unfortunately this check also detects changes made by the scratch pad itself, causing it to reload moments after you pause.

Loading a scratch pad document off of the disk resets the undo history.

Problems with Eastern Scripts in the Scrivener 2.0 Outliner

Description

When synopses are displayed in Scrivener 2.0's outliner, writing in the synopsis area using Eastern scripts such as Korean can sometimes be problematic.

Example

Using "2-Set Korean" and typing "d, k, f, x, p, d, j" should result in "알테어"; in the synopsis area of the outliner, this may sometimes turn out as "알ㅔ테어".

Cause

When synopses are displayed in the outliner, formatted text is used to display the title in bold and the synopsis in a smaller, coloured font. In order to ensure that no other formatting is allowed into the synopsis area - which is unsupported - Scrivener has to ensure the correct font is being used as text is entered. However, some fonts don't support all characters, and many fonts don't support all Eastern script characters. The way the OS X text system handles this is to substitute other fonts that do support the necessary characters, in order to display and enter the text correctly. Unfortunately, there is no mechanism for checking whether font substitution is in progress during typing, so when Scrivener fixes up the font to ensure that no extra formatting has crept in, it can mess up the font substitution, causing certain characters to get entered incorrectly.

Workaround

Given that the issue is caused by Scrivener temporarily swapping back in a font that doesn't support the necessary characters, the workaround is to choose a font for the outliner that fully supports the script you are using. To do this, go to the "'Appearance" pane of the preferences and set the Outliner Font. AppleGothic works well for many Eastern scripts, including the Korean example given above.

Status

We still hope to fix this bug in the future so that the workaround is not necessary, but we have yet to find a satisfactory solution.

Finding Text in an Annotation Can Reset Text Colour

Description

Under certain rare conditions, it is possible for the Find panel to reset the colour of the found phrase within an inline annotation, so that it is no longer a part of that annotation. This is similar in effect to selecting a word inside of an annotation and manually changing its colour to something else.

Reproduction

In order for this bug to appear, the underlying text must have its own colour applied to it, and that colour must be different from the colour of the inline annotation. In addition the entire annotation must be off-coloured this way. To you, the text will not appear coloured because inline annotations override local colour changes to the text. This can most often occur when using revision mode, which automatically colours text as you type it.

  1. In a test paragraph, create an inline annotation (assuming
    default red).
  2. Set revision level to 2.
  3. Right-click in the annotation and choose "Select Annotation".
    (Partial selections will not trigger the bug; manual full-selection is okay.)
  4. Use Format/Revision Mode/Mark Revised. (Whether you leave
    revision mode on, or turn it off at this point, does not matter
    for reproduction.)
  5. Place the cursor before the annotation to help search out.
  6. Cmd-F; type in a word that appears within the annotation.
  7. Hit Enter. (This is important; Cmd-G and clicking the
    button will not work.)

Workaround

If you experience the bug, used Edit/Undo to get rid of the initial problem. The bug is only triggered when the Enter key is used to confirm a search from the Find dialogue box. Using Cmd-G or Shift-Cmd-G to scroll through search hits, or clicking the "Next" and "Previous" buttons in the Find panel will not trigger the bug.

Status

This is unfortunately a bug in the underlying Apple text engine, and not something that can be easily worked around at the level that Scrivener works within.