This article lists bugs which you and I have encountered in macOS Mojave 10.14.5 itself, rather than issues in specific third-party applications and other software.
Safari – webloc files with malformed data forks
Although easy to reproduce, this bug is both serious and weird, and affects 10.14.4 and 10.14.5.
In Safari, press Option-Command-B to open the Bookmarks. If you already have a folder within them, drag that to the Desktop. If you don’t have a folder, create a new folder and drag it within the existing bookmarks, then Option-drag some bookmarks into it. When you’ve got a few there, drag that folder to the Desktop.
The .webloc files within that folder now can’t be copied or moved, nor can you open their data forks in an app such as BBEdit: they simply do nothing, or cause the app to hang. In the case of the Finder, you may be able to cancel the operation if you’re quick. The solution is to quit Safari, which then releases those weblocs for use.
Full details are shown here.
Many thanks to Dimitris for discovering this seriously weird bug.
System Information – Legacy Software misleading
The information given about ‘legacy software’ in System Information remains incomplete and misleading. Fuller details are here. Use 32-bitCheck (from Downloads above) instead.
macOS seems to be building this list as and when macOS warns the user that each specific 32-bit app needs to be replaced. Those warnings now occur more frequently, but are still far from complete or comprehensive. Until their list is complete, users will find 32-bitCheck and ArchiChect far more reliable for informing them which apps and other software are 32-bit.
Disk Utility – can’t resize APFS disk images
This bug appears to have been present since the release of APFS in High Sierra, and persists in 10.14.5. Using the Resize… command in the Images menu on a disk image in APFS format invariably fails immediately, with an error message.
The only way to resize an APFS disk image is using
hdiutil at the command line. Further details including an account of the workaround are given here.
(Thanks to Dimitris for reporting this, and to klanomath for the workaround.)
LaunchServices – apps may not undergo proper signature checking when they should
In Mojave, at least, LaunchServices initiates a formal signature check using Apple Mobile File Integrity (amfid) when asked to launch any app from a path with which it isn’t already familiar. If the signature is found to be defective, amfid escalates this and the app is crashed with that signature error.
Although uncommon, circumstances can arise in which LaunchServices incorrectly calls for this check using lsd rather than amfid; the result is that errors are ignored, and the app is allowed to launch.
If the conditions required to reproduce this can be discovered, this would constitute a vulnerability, which could be exploited by malware. Full details and log excerpts are here.
Sandbox – quarantine flags written to documents promiscuously
For several years, sandboxed apps have written quarantine flags to most if not all documents they open, even when they don’t save them. These put all those documents in quarantine, even when a document has never been near the Internet and only created and edited locally. This even happens when a ‘real’ quarantine flag has already been attached to a document; in overwriting that, the sandbox strips its link to the quarantine database, preventing further information on that quarantine event from being retrieved.
This adversely interacts with a protective mechanism which prevents easy opening of documents which have been set to be opened using an app other than the default for that type, using the OpenWith extended attribute. The end result makes it unnecessarily difficult to open such documents.
There is no way for the user to inspect or change the quarantine flag, and no way to permanently change the quarantine status of a document. The next time that it is opened by a sandboxed app, a fresh flag will be written putting that document back into quarantine.
Full details are given here.
QuickLook – can’t handle malformed documents
When asked to provide a thumbnail or preview of some malformed documents, QuickLook hangs displaying the busy ‘spinner’ in place of the thumbnail or content of the preview.
To demonstrate this, take a copy of a text file, and replace its extension with ‘.jpg’. Select that file, and its thumbnail will be shown as the busy spinner. Press the Space bar and its preview will also be the same busy spinner. QuickLook appears unable to return an error to IconServices, or the preview window. This appears to affect mainly malformed image files, including JPEG, TIFF and PNG. It doesn’t appear to affect QuickTime movies, though, suggesting that the bug is in the qlgenerator for still image formats, which is part of macOS.
Although this doesn’t result in high CPU load, and doesn’t hang the Finder or anything else, it is a fundamental flaw which should never have appeared in release software.
Keyboard pane – App Shortcuts almost unusable
Open the Keyboard pane, select the Shortcuts tab, then the App Shortcuts item at the left. If you only have the single default shortcut, add some others. After adding two or more, they will be displayed with the ellipsis character … instead of their menu title, and attempts to edit that title are frustrated because the edit area is the size of the ellipsis, not the title. There is no apparent way in which this can be corrected by the user.
There are odd inconsistencies here too: the single default item Show Help menu has a checkbox at the left, but items added by the user don’t. However, as that first item cannot be edited or removed, that checkbox is the only way to disable it.
This tab is almost unusable as a result, making it impossible to set or maintain app shortcuts. macOS 10.14.4 altered this, in showing one additional letter each side of the ellipsis, but still doesn’t handle this properly in 10.14.5.
(Thanks to John for pointing this out to me.)
Bluetooth keyboard – sporadic repetition of letters
When typing normally, even with the delay to key repeat adjusted carefully, there are occasional repetitions of letters entered via an Apple Bluetooth keyboard. This is an old problem, going back to Sierra at least, and affects multiple models (including iMac and iMac Pro). Although adjusting the threshold can reduce its frequency, the occasional letter duplication (e.g. ‘paath’ for ‘path’) still breaks through. Disappointingly, this persists in 10.14.5.
Dictionary – text incorrectly displayed in Dark Mode
Although most, if not all, dictionaries accessible to the Dictionary app seem to have worked in Dark Mode in 10.14.4, in 10.14.5 some have stopped displaying their text in colours which are readable. One example is the bundled Terminology dictionary shown below; another is a German thesaurus. It’s unclear why this has broken again, as third-party dictionaries tweaked to work properly in Dark Mode appear unaffected.
(Thanks to Stephan for reporting this.)
Calculator – defective printing of Paper Tape
There are two obvious bugs: when running in Dark Mode, if you try printing the Paper Tape in Calculator, it remains fixed in Dark Mode, printing a rectangle of dark grey with white text. The other is that it isn’t possible to change the size of the Paper Tape; it remains stubbornly fixed even if you change the paper size to A3 in landscape mode.
The only workaround for the first bug is to switch to Light Mode before printing; there is no workaround to the second, other than copying and pasting the Paper Tape output to another app for printing.
It’s perhaps worth noting here (and in the bug below) that Apple has started rejecting third-party apps from the App Store when they don’t print correctly in Dark Mode. Maybe it should put macOS in order before behaving like this to developers?
Activity Monitor – almost blank pages when printing in Dark Mode
Printing from Activity Monitor when in Dark Mode results in almost completely blank pages, which contain just a few icons.
The only workaround is to switch to Light Mode to print.
Preview – selection highlighting dysfunctional
Correct app behaviour when the user changes the selection Highlight colour in the General pane, either directly or by changing Accent colour, is to change existing selections when the app window is brought to the front or otherwise updated. Preview doesn’t do this: select some text in a PDF document, for example, then change the Highlight colour in the General pane. The selected text will remain in its existing colour highlight.
In addition, the Graphite highlight colour doesn’t work at all in Dark Mode, and may not work reliably in Light Mode either.
Apps which are built on AppKit do behave correctly, though: to see how this should work, try it with, for example, my DelightEd.
(Thanks to Dimitris for explaining this to me so patiently.)
Messages – some new messages contain old text
Some users are seeing text fragments from old messages in new (empty) messages, which have to be cut before they can enter a new message. This doesn’t appear to affect all users, though.
(Thanks to Hunter for reporting this, and for others who confirmed it.)
App Store – search returns weird hits
When you enter some search terms into the App Store app, completely unrelated apps appear in the results. In some cases, these are additional to genuine hits, in others they just appear weird and unrelated. For example, searching on the word
consommé (a type of soup) consistently returns an app which has nothing whatsoever to do with the word, nor does it appear in the info provided about the app.
clover returns three genuine hits, and three spurious apps which are completely unrelated. This looks like the store’s metadata are corrupted with random terms.
If anything, this has grown worse in macOS 10.14.4 and 10.14.5, with even more spurious hits.
TextEdit – colours displayed differently with Dark Background
Colours used to display text are changed when Dark Background is enabled. If you save or copy Rich Text in that display mode, the colours saved or copied are very likely to differ from those shown. To avoid this, don’t use Dark Background when you’re using colour.
This and other problems are discussed in detail here.
Multiple displays – external displays may not activate at login
Some users are experiencing an old problem from High Sierra, in which external displays aren’t activating properly at login, as if they weren’t connected. One workaround is to put the internal display to sleep, then wake it, which should activate all connected displays properly.
(Thanks to mcgroarty for reporting this.)
Dark Mode – QuickLook and other bugs
If you use an editor such as my DelightEd which is designed to produce RTF which ‘works’ in Dark as well as Light Mode, then QuickLook thumbnails and previews switch contained text to white in Dark Mode, but retain a white background. This renders the thumbnail/preview useless in Dark Mode.
A similar problem with Dark Mode exists when you use Control-Command-D to show the definition of a selected word: the popover window is semi-transparent, which makes text in custom dictionaries visible only when viewed over a window with a white background. If the underlying window is dark grey, then that text is almost invisible.
These are described in more detail here. There don’t appear to be any workarounds for these, other than switching back to Light Mode.
Thanks to Artyom for drawing my attention to the second of these.
Safari – errors opening local Home page, and others
If you set Safari 12.1.1 to open a local file as its Home page, this may cause an error when Safari first opens, and that error may in turn result in another error reporting that the error page can’t be found. Others also report Safari’s inability to search until a remote page has been loaded, and other potentially related issues. These are detailed here (see the comments there in particular).
Once Safari has started up and connected to a remote page, these problems usually vanish, so can be safely ignored. They also appear to occur most commonly when the Develop menu is enabled; turning that off may make them disappear, but you then lose the additional features of that menu. This bug was present in 12.0 and persists in 12.1 and 12.1.1.
(Thanks to Manoli for pointing this out.)
System Preferences – General pane Accent colour confusion
Switch between non-grey and grey Accent colours repeatedly, and the colours shown in the pane quickly become confused, and show the wrong colours relative to those selected. These may also be out of sync with the colours actually set. To restore normal colours, select only non-grey colours. Full details are here.
This seems to be more deep-seated, in that the Finder can lose track of Accent and Highlight settings, and display a third colour which isn’t either of those selected. This is detailed and shown here.
(Thanks to Ryan for pointing this out.)
Appearance – grey/gray accent turns ‘traffic lights’ grey too
In the General pane, set the Accent colour to grey. Whether in Light or Dark mode, the ‘traffic lights’ at the top left of every window then show just three grey lights instead. Now which end was red?!
The only workaround is not to use the grey accent.
It has been argued (see comments) that this is a feature and not a bug, as it recalls the earlier grey appearance. Mojave doesn’t have grey appearance: it has Light Mode and Dark Mode as its two appearances. Within those, the colour options are ‘accents’ which change the colour of a small number of controls. Grey accent is the only accent which removes all colour from the ‘traffic lights’ and is therefore inconsistent at best. I’d call it misguided at least.
(Thanks to simweb for reporting this previously.)
Finder – copy progress icons frozen
Sometimes, the circular progress icon displayed in column and list views during file copying becomes frozen. It then shows early progress at the start of copying, and remains fixed despite those files being successfully and completely copied. Presence of the icon misinforms the user that the copy hasn’t been completed when it has. In previous versions of Mojave, these were not uncommon, and could persist indefinitely until the Finder was restarted. They appear more transient and less frequently in 10.14.5, but are confusing when they do appear.
Finder – incorrect column width
This can occur when using Finder windows which are set to column view. When switching folder in the view, the rightmost column being displayed has excessive width, filling the Finder window, its divider being placed incorrectly at the right edge of that window.
This long-standing but intermittent bug dates back to Mavericks if not earlier, and I have whinged about it here and here. It was also present in every version of El Capitan, Sierra and High Sierra. The only workaround is to select a different folder, then to select the correct folder again.
Bugs believed to have been fixed from 10.14.4
macOS 10.14.5 fixes a bug in Terminal, in which Command-D to split a pane made an unusable mess of the window. Splitting a window now works. (Thanks to Hans-Peter for reporting this in 10.14.4.)
It is also reported to fix a bug mounting encrypted USB hard drives, and possibly SSDs too. (Thanks to mcgroarty for reporting this.)
(Updated 2205 UTC 17 May 2019.)