Main navigation

Known bugs in macOS Mojave 10.14.5: an incomplete summary

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. Note: This article refers to 10.14.5 and is no longer being maintained. To see the list of bugs in 10.14.6, which is being maintained, please go to this article.

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.

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.

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 third-party 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.

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.)

Related

112Comments

Hello Howard.
Today I found out a weird lag.
Here’s the story of it.
Open a window in Finder. Change the view option as Columns. Click on a file.
Ok. Now, open another one window in Finder (or open a browser window). It doesn’t matter in what view. Lets say in List view.
We have two different windows now, the first in foreground and the second in background. The one above the other.
Click on the window with the files in List view.
Then, try to click on the second window with the files in Column view, but this time into the preview area of the selected file.
The window comes in front but with latency.
Sometimes you have to click 2 times. It doesn’t work immediately by clicking just once.
It works perfect if you click on the toolbar or on the Sidebar, etc.
I not sure if I described it quite clear, so, I will attach a video.https://www.icloud.com/iclouddrive/0SXN1pp9CZ8YHWjOMiVXPt3fA#Screen_Recording_2019-05-15_at_14.17
Dimitris

Thanks for the immediate answer.
I have an iMac 27″ Late 2012, 3,2 GHz Intel Core i5, with 24 GB 1600 MHz DDR3.
I do not think so that this is a Hardware problem, because the lag appear only when I click into Preview area of the window.
Why the problem doesn’t come up when I click on the window itself? It is a question or a riddle.
Something is wrong here but I don’t know what.
On the other hand maybe Apple wants to force me to buy a newer model of iMac. Hahaha…
Dimitris.

No – I don’t think it’s a hardware problem, but possibly something which is optimised for newer Macs with i7 and better processors and faster GPUs. It’s probably due to handling the responder chain, which handles where the click is. When clicks hit window frames etc. macOS only has to work out which window to bring to the front. When it’s a view within that window, it has to work out which window owns that view first. Maybe that hasn’t been properly optimised for older systems, and leads to the pause.
One way to tell is to look in the log, of course.
Howard.

Thanks.
Unfortunately, Console will only give you a glimpse of messages as they flash past, and isn’t a good way to study this. Having said that, the WindowServer entries there are being generated in response to your clicks.
I’d look at a test run using Consolation, where you can study with ease the whole event from start to finish. But it does take time to browse through – even simple events like these tend to generate lots of entries.
Howard.

fixing the quicklook thing would require not being solely reliant on the last part of a filename to determine type.

That used to not be a problem. Now it is, and I don’t see that ever changing, even though it could. I’m honestly surprised we’ve not seen malware taking advantage of how reliant your computing life is on filename extensions.

Thanks.
Whatever system you use for typing of documents, there will always be mistakes. The bug here is not in that, but how the QuickLook generator handles that situation.
It’s simple to write a JPEG (or other) thumbnail builder which recognises when it’s not actually handling a JPEG, but something else, and then to substitute a generic icon instead of a thumbnail which it can’t build from the data. Currently, the JPEG and other generators don’t cope with that – they simply fail to return anything, leaving the Finder spinning the ‘progress’ wheel forever. It didn’t used to, at least on some file types, and I think it still behaves properly when handling movies which prove not to have movie content.
To me, that’s either a bug (if it was intended to work), or bad engineering (if it wasn’t).
Howard.

There will always be mistakes, but right now, the only way it works at all is if the extension happens to be correct. I just tested changing the extensions on a .mp4 and a .pdf file. As soon as it doesn’t match, you either get a generic extension type icon, (.pdf -> .mov or .mp4) or you get a spinning wheel of “I don’t know what to do” (.mp4 -> .jpg)

There is a way to fix this and it would require a minor change to how UTIs are currently handled: allow UTIs to be set by an application instead of only being derived from the filename extension. That way, you have two OS-approved ways to derive file types: extension and UTI. If one doesn’t work, the other can. Makes it harder to fail completely.

It won’t happen, they’ve been able to fix this for how long, but decided long ago that a bit of file metadata should be the sole way to set a file type. As long as that’s the case, then things like this are inevitable. It also means your idea can’t work because there’s no way to tell what kind of file it “really” is. What you’re seeing is actually correct, albeit frustratingly stupid behavior. Extension says it is a jpeg, then treat it as a jpeg no matter what. If the filename extension is incorrect, there’s no way for the OS to handle that well with the current typing system.

You have identified the bug perfectly in your first para: some QLgenerators do behave well, and substitute a generic icon when they can’t parse the type they were expecting. That’s what should happen in every case. The bug is in those which don’t handle that properly, and don’t return anything, so leave the progress spinner spinning.
I don’t expect any QLgenerator to be able to tell the type of file beyond that – that’s not their job. But simply not returning any sort of thumbnail or icon is shoddy. Those QLgenerators are incomplete, just as an app would be if it didn’t handle errors too, but went into an infinite loop.
Howard.

So what does it do? use the incorrect generic icon that happens to agree with the filename extension? That’s bad, it’s saying a movie file is really a jpeg. Lying to the user is bad, I’d hope we can agree on that.

So that behavior is suboptimal to the point where anything beyond a generic “this is a file” icon is a bug.

if the filename extension, metadata, says “this is a jpeg” and the actual file has nothing to do with being a jpeg, who wins? What’s the reality of the situation? According to how the OS seems to work, the finder should try for some x amount of time to quicklook the file by the extension, then maybe say “I can’t quicklook this” or whatever in a dialog.

The problem is, because of this singular reliance on filename extensions, there’s no way to answer this problem correctly, by which I mean, not lying to the human. Windows’ history has literally shown us the danger of overreliance on filename extensions, and yet no one seems to want to learn from that. Neither response is correct. Slapping a generic JPEG icon on a PDF file is literally no better behavior than the spinning wheel, and I would argue the latter is actually preferred, because it is not lying to the user, whereas the incorrect icon is.

“I have no idea what to do here” is better than letting someone think their file data is somehow wrong or corrupt when it really isn’t, it’s just that a trivially modified bit of metadata is wrong.

When you prioritize the filename over the file data, you have gone way off into the weeds.

The short answer is that macOS should display an icon appropriate to the situation. If the chosen QLgenerator can’t generate a thumbnail, it should return an icon which conveys that result to the user. The progress spinner can mean so many different things that it doesn’t tell the user whether there’s a problem with the document, or with the engineer who wrote the QLgenerator in the first place.
But allow me to wax more lyrical on this issue on Saturday morning, please, in an article here, as we’re in danger of losing touch with the whole purpose of icons and thumbnails.
Howard.

Thanks.
I haven’t seen that problem in Messages. Has anyone else here noticed it please?
The Preview behaviour I have described in my article about PDF annotations. I’m not sure whether it’s a feature or a bug, but yes, it was present in 10.14.4 too.
Howard.

In response to Hunter, I also frequently see a portion of previously sent text in the new text field in Messages.

In addition, I continue to be unable to Disable fonts in Font Book (non-system fonts, located in /Library/Fonts.) The option to Disable them is present, but when selected, a message appears, stating the font is “Protected” and can not be disabled. I have yet to uncover what makes a font “protected” (if I knew that, perhaps I could fix the problem!).

Dimitris,
Had a couple of looks at this. One thing which puzzles me with your Finder windows is why the search box isn’t at the far right, but you don’t seem to have a Space or Flexible Space to the right of it.
In my Finder windows, the Search box is flush at the right edge. I don’t understand why yours isn’t, and that seems to be throwing the toolbar layout.
Howard.

Dimitris,
Why is your Search box immediately to the right of the other items in the toolbar?
In my Finder windows, the Search box is pinned to the right edge of the window. That leaves plenty of space between the left edge of the Search box and the other tools, in which Flexible Space elements fit fine.
I don’t know of any way to change the position of the Search box, without putting Space or Flexible Space to the right of it, which doesn’t seem to be the case in your Finder window.
Howard.

Thanks, Dimitris.
I think I understand what’s happening here, although in fairness it seems largely cosmetic and not too restrictive in terms of function. Compared to self-emptying Trash, this is minor!
I’ll see if I can add something to the list in the next day or two which covers this.
Howard.

OK, what I can see here is that the Flexible Space element sometimes doesn’t appear. Sometimes it’s just a vertical line, but that can make sense when there’s no space for it to fill. But sometimes the space appears, but not with its box. I think that may be the cause of the problem.
Howard.

Did anyone have ever notice that sometimes -not always- when we move a file or folder to Trash.app, macOS deleted it immediately instead of leaving it in Trash folder, so to be able to be recoverable until the user decide to permanently erase it?
Even I have tried all known workarounds, it insists and it’s very annoying.
It seems that it acts in the same way just like when you select a file or folder and then pressing ⌥⌘← combination, but without any warning.
I had the first meet with that problem since the beginning of Mohave (10.14) and as I can surely say still exists in 10.14.5.
Thanks.
Dimitris.

Dimitris,
Thank you.
I note that the item that you put in the Trash came from a folder named Torrents, which appears different to ordinary folders. Are those files held locally (in their entirety), or are they wholly or partly stored off your Mac?
Does this happen with other files from regular folders in Documents which are stored locally too?
Howard.

This is a folder with custom icon. I have given this name as well. I use it to download not only torrents but anything I need from the Internet. This folder is on an external disk.
But, all the above have nothing to do with the problem I described.
It doesn’t matter from which folder you move something to Trash. Maybe you’ll try to move something from the Documents folder or even the Desktop. In other words a file or folder locally stored.
I did try so many times with numerous screen recordings. It is extremely difficult to catch it.
I’ll keep recording so to catch it when it happens from Desktop or other folder from my internal disk.
Dimitris.

OK, thanks, Dimitris.
I can’t see how this is being done by macOS. To the best of my knowledge there is no option or hidden setting to delete items instead of putting them in the Trash folder, which is what your little movie shows.
The only thing that I can think of which could do that would be a kernel extension, or possibly a daemon, which patches what happens when you put something in the Trash. I think some of the cleaning/housekeeping apps have done this in the past, although it’s a stupid thing to do.
The only way to work out what is happening is to look at the log for the moment that an item is trashed – when instead of appearing in the Trash folder for even a moment, it just vanishes.
By a strange coincidence, I have a new version of Consolation just about ready.
Howard.

10.14.5 addressed the regression in 10.14.4 wherein encrypted USB hard drives failed to mount automatically. This primarily affected users who use an encrypted USB hard drive for Time Machine backups. A large number of users confirmed the fix in the Apple support forums. It was fixed for me as well.

10.14.5 reintroduced an old High Sierra bug. On my iMac Pro, neither of the two Dell external displays (a P2415Q and a P2715Q) are active at login. My mouse is constrained to the main desktop as if no other displays were present, and the external displays remain in power saving mode. It’s necessary to force-sleep the iMac Pro internal display and wake it again (Ctrl+Shift+Eject, wait a moment, then tap any key) in order to activate the two external displays. I haven’t yet found others reporting this, but it reproduced on 5 out of 5 times as I reboot or power cycle, then log in again.

Quicktime Player bug – start an MP4 video file playing, and then use the two finger swipe left or right to scrub through it. On some videos it will reset to 0:00 – the beginning – which is infuriating because you lose your play position. On some MP4 videos the scrub just doesn’t work via gestures. I’ve no idea of the rhyme and reason here. Both these two things seem random but are probably related to characteristics of the MP4 files.

I do that frequently, Dimitris. On a 27 inch display, screenshots can get very very long indeed!
When preparing screenshots for publication, I can’t use Cmd-Shift-4 window shots, but have to create Cmd-Shift-3 full screenshots every time. Even dropping the display resolution, those files are usually around 5-6 MB. They do look lovely in print, though.
Howard.

Thanks: yes, that’s clear. I think it’s because notifications aren’t windows in their own right, and you get the Notifications bar appear from nowhere as their parent ‘window’.
I’ll take a closer look at this tomorrow.
Howard.

Good morning Howard.
I think I found what is going on.
I don’t know I you know the ScreenToLayers.app.
Today I took a Grab Screen using this app by pressing ⌘5. It takes the entire screen just like pressing ⇧⌘3.
After that, I opened it up in Photoshop.
In Layers window you can see all the layers of that shot.
Here it is. The layer with the name Notification Ce (Center) includes the banner and the Notification Center’s window.
At first, when you press ⇧⌘4-Space and you come close to the banner it marks only the banner. But after the mouse click the result is completely different.
What a mess! Unacceptable!
Dimitris.

Dimitris,
That confirms what’s going on. It’s an architectural issue in an undocumented ‘feature’.
You see the same issue when you take a screenshot of a window with a drop-down overlay, such as an alert, dialog, file save, etc. – a ‘segue’ view.
When you take a screenshot using ScreenToLayers, all it’s doing is writing each window to a separate layer, as they are accessible structures in the view hierarchy.
Views belong in a window. The system can distinguish between windows, but not (outside an app) between views within a window. When you take a screenshot of just a window, you get all the views currently visible within it, superimposed in the same layer. For example, the window in my SystHist contains three main views. You can’t take a screenshot of just one of those views, nor separate them into layers, at a system level.
When a small notification appears, it isn’t actually a whole window. Like the drop-down segues, it’s only a view. So trying to take a shot of that using the window option you get the window – which is normally kept invisible – which is the whole Notifications window, within which the individual notification is just a small view.
So it is actually working as specified, and not a bug. It may be inconvenient for screenshots of notifications, but it’s part of their architecture, and not I suspect something that Apple would want to change, if it could.
Howard.

I have found a weird thing in Notes (I know you don’t use it but please check it if you have time).
If one wants to print the content of a Note he would think that simply pressing Cmd-P would be enough… alas, if the content would occupy more than one single page all the rest is not considered. The printing window gives a 1 out of 1 pages and even exporting to PDF doesn’t solve it, still only 1 pages gets exported…
I have no idea how old this bug is but it is for sure annoying because I need to export this to print it … seriously time to look for something new …

Michele,
I have tested that here in 10.14.5, using both iCloud notes and local ones, and can’t reproduce any problems with printing: multi-page notes are correctly printed as PDF with all their pages.
Has anyone else had this problem, please?
Howard.

I found the problem: when you hit Cmd-P and, for any reason, “Rewrap contents to fit page” is unchecked, this “bug?” occurs.
Once in the printing window, if I check the option (and even if then I re-uncheck it) the printing works well.

Simply, if the option is unchecked when you launch the printing function, then it occurs.
Really strange…

No, don’t apologise – it’s clearly a behaviour which Apple seems to think that some users might want, otherwise there’s no point in offering such weird and unhelpful behaviour. Maybe some people want to turn it off – but it seems to have been designed in there, to the extent of making it a Print option. Crazy, but obviously I don’t understand its real value!
Howard.

Thank you. I’m not sure that’s a general issue. Have you tried trashing its preferences file and restarting?
The prefs file should be at ~/Library/Containers/com.apple.Preview/Data/Library/Preferences/com.apple.Preview.plist in case you couldn’t guess (!).
Howard.

Apple does not provide the Terminology dictionary, which helps explain why it is not Dark Mode ready. The Terminology dictionary has to be downloaded and manually added to the ~/Library/Dictionaries/ folder.

Thank you – yes, you’re correct. Although I remain puzzled as to why these have changed in 10.14.5, when they seemed to work fine before.
When I get a chance, I will look in more depth to find out what is going wrong now.
Howard.

1) Not a bug, but a lagging functionality: macOS is Google’s WebP image format illiterate. Nothing Apple provides has a clue what to do with WebP images, let alone Safari. I’ve been pestering them via AppleSeed to catch up, without success. The code to add WebP functionality is open source and available online to anyone.

2) Safari in recent months has not been capable of reliably rendering many web video players, the most popular of which is YouTube’s. The result is annoyance for Safari users, having to play around with these messed up interfaces in hopes of getting it to somehow work. Examples of errors are:
– Persistent interface buttons on the screen when they should be off.
– Unavailable interface buttons when they should be on.
– Inconsistent behavior of YouTube’s ‘AUTOPLAY’ switch.

3) Grammar checking errors in the macOS spell checking system. An example annoying blunder is the system’s inability to understand correct use of the word ‘their’ in a sentence.

4) Safari 12 added a Return character after filling in an ID and Password for a website. I’ve asked Apple to go back to its previous method where no Return character is added. The Return character messes up all websites that use CAPTCHA in an effort to avoid bot activity. The result is a total failure to automatically log in. Users are forced to look up their ID and Password or use a Password collection application to fill in the data. Unfortunately, many of these websites use CAPTCHA in a popup box with no access to browser extension functionality, making access to a Password program difficult and also annoying.

5) Web URLs that link an app information page to the Mac App Store are not handled correctly. The consistently result in a page opening in the App Store app with a warning: “You must own this item to write a Customer Review”. This is entirely incoherent. A test example is the “Doo” application. Visit the app’s Mac App Store Review page and click on ‘View in Mac App Store’. Here’s the link:https://itunes.apple.com/us/app/doo-get-things-done/id1107759193

Over the last three years, as an AppleSeed beta tester I’ve become quite cynical about Apple’s interest in macOS. It’s an afterthought, if ever a thought at all regarding persistent bugs.

Thank you.
Safari changes are very hard to track, as both the app and pages keep changing, and it’s very hard to know where each problem rests. Have you tried Jeff Johnson’s Stop The Madness extension from the App Store? That can tweak many of these annoyances.
The issue with their and there is long-standing and extends beyond macOS, I fear – it often gets miscorrected.
Howard.

I agree that I’d like to be able to have ‘graphite’ accents with colored traffic lights.

It seems, though, that Apple is using that particular accent color selection for more than just setting the accent color.

See [Apple’s Human Interface Guidelines][https://developer.apple.com/design/human-interface-guidelines/macos/visual-design/dark-mode/]: “Desktop Tinting: Apps running in Dark Mode benefit from Desktop Tinting. When active, Desktop Tinting causes window backgrounds to pick up color from the user’s desktop picture. The result is a subtle tinting effect that helps windows blend more harmoniously with their surrounding content. **Users who prefer not to have the additional tinting, perhaps because they work with color-sensitive content, can disable this effect by choosing the graphite accent color in System Preferences.**”

Updated this morning. In safari, when right clicking (or two-finger tap/clicking) on images, the cursor is defaulting to the “confirm your file download location” prompt window, instead of the small cursor for “open in new tab/window, etc.” – any ideas on how to fix this? This has happened to me in the past, but it went away after a few restarts. Isn’t doing the trick this time. Even when I open ‘safari preferences’ and click regularly, not right clicking, on the ‘general’ tab within the window – it prompts a “confirm your file download location” as if I right clicked on the general settings image within safari preferences!

Although this could just be Safari preference settings which have broken, it’s important to ensure that the update was applied correctly. I’d download the standalone update (the smaller delta version should be fine) and install that, to see if that can’t fix it.
I wish you success,
Howard.

I have two Samsung T5 SSD’s and both of them stoped working after the update.
The SamsungportableSSD software keep telling me that the drives are disconnected, while they are connected. I have followed the trouble shooting guide from Samsung but it doesn’t help.

I recommend that you try uninstalling the Samsung software and restarting. Alternatively, there may (if not now, soon) be an update to the Samsung software for compatibility. But your drives shouldn’t need that software to work well.
Howard.

I’m experiencing the same behavior with T5 drives. Hopefully Samsung/Apple can figure this out before too long. I have two 2TB drives and its causing a workflow problem to only use them on Windows 10 at the moment.

Thank you.
I don’t think that it is as threatening as it looks, and I don’t see any demonstration of double-click opening of (for example) a regular unsigned app on such a share.
When a user opens an app in the Finder, if that app hasn’t previously been run from that path, regardless of the presence of a quarantine flag, a full signature check is run by AMFI. If the app is unsigned or has a broken signature, that is detected at that point. If there is a quarantine flag which hasn’t been cleared, then whether the app is on a local or shared volume, XProtect checks the app as well as AMFI obtaining a full signature check. It isn’t clear to me that what he describes somehow manages to bypass either of those paths, or how he might have bypassed them.
There are also some other curious errors in his blog account of this which arouse my suspicions.
There is a very easy bypass which addresses the XProtect scan: strip the quarantine flag. However that doesn’t affect the AMFI signature check provided that this is an app which is being opened in the Finder (something which many claims omit to consider).
Howard.

I have written an article examining this in more detail, which should publish here at 0700 UTC on 27 May (Monday).
I hope that it answers some questions.
I also note that the screenshot used in the covering article is from High Sierra, and has now been superseded by the more limited options in Mojave, although that’s not actually relevant to this issue.
Howard.

Mac OS 10.14.5 update/ iTunes SUPPORT Update not only turned off my wifi network, but when I tried to reconnect I got an error requiring a different type of password for my router (I think it was something like WPN but I don’t exactly remember). Fortunately I use an external HD with Time Machine and it was necessary to reinstall the previous configuration. I will not install this update and I turned off my auto update feature.

As to the above message: the update affected my computer, not my router. The router still functioned normally with my iOS devices still connected, but my computer could not get back on the internet with my password.

I’m sorry to hear that.
I’d be inclined to start up in Recovery mode, run Disk Utility there, and run its First Aid to ensure your boot disk is in perfect condition. After restarting back in normal mode, I’d step through the Network pane settings for Wi-Fi to ensure that they’re still good. I’d then download and install the standalone version of the 10.14.5 update, possibly even the Combo version.
I wish you success.
Howard.

Here’s something that’s been bugging me for a while in macOS’ Preview.app: it just won’t read some PDFs that Adobe’s Acrobat reads like charm. That is, the pages in such PDFs show nicely, but are unsearchable. Consider for instance the dissertation available at . It shows nicely within Safari’s PDF-viewer, and the downloaded file opens nicely in Preview, but is unsearchable, even on second and third re-opening. (Sometimes, but not here, re-opening a PDF solves the in-searchability.) Yet, Adobe’s Acrobat Reader opens and searches through it with ease, as it should.

Interestingly, when viewing the above dissertation in Preview, and start searching by entering one letter (say, “t”), the side-bar instantly becomes populated with 120 pages with the letter “t” found. Entering the second letter (say “h,” spelling now “th”), the number of found pages in the side-bar reduces to 6… which is low, but not impossible… Adding the final “e” (to now spell “the”) results in no pages found.

Admittedly, this particular dissertation has the first 27 pages in Polish, which may be somehow differently encoded… Nevertheless, the fact that Preview can search the file while Acrobat Reader has not the slightest problem in searching it bugs me to no end. FWiW, I use Mojave (10.14.5) on a mid-2015 MBP, but have run into this bug before many moons, and some snows.

Thank you.
Have you tried opening them in Podofyllin, my free PDF viewer and debugger? That will tell you quite a lot about the document, and may solve the puzzle. It’s available from Downloads above, as well as its own product page here.
Howard.

I’m afraid, I’m none the wiser: Podofyllin does open it, and also finds “th” on six pages only, and “the” nowhere. The right-hand side (“text”) pane is mostly blank with plenty of gibberish. The “Open PDF” shows, predictably, the 200 PDF pages nicely; the “Open Source” shows oodles of lines of code (e.g., “/Length 11 0 R /Type /XObject /Subtype /Image /Width 74 /Height 84 /ImageMask”), a bit more monotonous than in some other (searchable) PDFs that I tried… then again, I don’t know what I’m supposed to be looking for.

Thank you very much for the offer, but the particular file is not that relevant for me. I believe that the particular 200-page PDF was probably produced in a LaTeX-to-DVI-to-PS-to-PDF (decades old) “legacy” workflow, rather than by the (just as widely available) “latextopdf” compilation, and I can see how this layer-cake of post-processing hides the text content. Alas, this workflow (and its dreadfully rendered PDFs) is still in use, and someone who’s work relies on researching dozens and even hundreds of PDFs in each project continually re-formatting PDFs is impractical. This seems to indicate a (meeenuscule) need for a “searchablizer” app…

At least Universities should do this routinely with the theses and dissertations they publish; I’ll look into this at my own “home U.,” but won’t hold my breath… (I have not encountered this problem with PDFs produced by “major” publishers.) In turn, and perhaps too naïvely, I’d have thought that Apple, Inc. would invest the requisite resources to bake the requisite “black magic” into its macOS-wide search engines that underpin “Preview” and “Spotlight.” Incidentally, “Preview” has other layers-related problems, but that should be a separate thread.

Evidently, I do not know how to insert a link, nor do I know how to go back and edit. At the end of my 3rd sentence, ending with “…available at,” I inserted the link: https(colon) // arxiv(dot)org/ pdf/ 0712.2173(dot)pdf. (Hopefully, this won’t get erased in posting.)

Thank you for your persistence: sorry, WordPress can be a pain like this. It’s intended to block comment spam, so it prevents proper comments but the spam still contains links!
I will take a look at that shortly.
Howard.

That’s been a thing for a long time. Acrobat will read PDFs that many other things won’t, it’s what it does.

Question though, how are the PDFs in question generated? (I ask because I have seen different PDF generators do silly things. In one case, Facebook was using one to create invoices that killed printers.)

Legally, that makes sense: Adobe’s “Acrobat Reader” _reads_, while macOS’s “Preview”… well, (merely) _previews_. I am curious though, why can macOS’s “Preview” incorporate the same …”black magic” — at least so as to render the PDF’s searchable? Or, is this supposed to be a sign of an official policy, so folks who rely on searching PDFs should forsake “Preview”? (If so, that implies the same woeful incompleteness for disk-wide searches by “Spotlight”…)

Actually I’ve been looking at that PDF with Podofyllin and Acrobat Pro. It was written with pre-release Ghostscript from LateX and even Acrobat pre-flight has problems with almost every one of its nearly 50,000 objects. I’ve saved a copy here as one of the worst PDF documents I have ever come across. It might just comply with the standard but is truly dreadful.
Howard

I don’t think it’s a legal issue as much as Adobe cares more about PDF than literally anyone else. Preview has won points on convenience and UI, but in terms of fully supporting PDF versions, it has issues. For the most part…oh, 90%-95% of use cases, Preview is just fine. But there are things it simply doesn’t handle well. Like Javascript in PDF.

I installed the update of macOS Mojave 10.14.5 and the application Mail no longer works. I am no longer able to create an account and connect with my server. Has anyone had this problem? Thank you for your attention.

There are two potential issues here: is it just outgoing mail which you can’t configure? Can you still read incoming mail from existing accounts?
If Mail is totally broken, then the update hasn’t installed properly. I recommend that you download and install the latest (10.14.5) Combo updater, which should restore normal function.
If it’s only outgoing SMTP mail, that’s a longstanding sporadic problem with the SMTP server list in Mail. This article explains how to deal with it.
I wish you success,
Howard.

Another annoying macOS/Preview.app issue stems from the fact that some of its functionality seems to have become orphaned — or at least, it behaves so for me (macOS v10.14.5). For example: open a PDF document, select a word, highlight it (use the highlighting pen tool from the toolbar or the Tools/Annotate/Highlight Text, i.e., ⌃⌘H), and then open the Inspector pane (Tools/Show Inspector, ⌘I); the highlighting will be listed in the inspector pane. Now, click on the highlighting entry in this pane, and enter some text in the lower 1/4 part of the pane — this used to be the method to comment on the graphical annotations. Alas, after entering and clicking anywhere outside this Inspector pane, the entered text vanishes from the pane, and as best as I can tell, it vanishes altogether. Of course, there also exists the “Highlights and Notes” side-bar, which also contains the highlighting entry, but where the entry itself cannot be annotated. Yes, of course, one can also add a Note (Tools/Annotate/Note, i.e., ⌘N) — which then acquires a “Popup” entry in the Inspector Pane, but which does not display the text of the Note, and the Note is in no obvious way linked to the highlighting.

Also, clicking on an annotation entry in the Inspector pane used to make the PDF jump to the location… not any more. (I’m not sure when exactly all this functionality got lost, but it definitely happened many moons, perhaps even some snows ago.)

It would seem that Apple, Inc. has deprecated the Inspector pane, and relegated the functionality to the “Highlights and Notes” side-bar, but forgot to expunge the now crippled Inspector Pane.

While this may seem like superficial kvetching on my part, let me add that PDF documents that had been annotated using the Inspector pane, while it was still fully functioning, lost all the notes associated with the graphical annotations. (Think of a 500-page book, with many hundreds of galley proofs… most of which consisted of highlighting some text to be corrected with the correcting instructions in the associated Notes, but the correcting instructions now gone. BTW, I’ve re-created those for all PDFs I needed, but this gives you an idea of the volume of extra work and annoyance involved.)

This may well be related to the variety annotation mechanisms that other, 3rd party PDF-editors use. FWiW, I also use iOS/iAnnotate.app, and those annotations do not always turn up in macOS/Preview.app. So, it would seem, one is best served by using Adobe’s Acrobat Reader, which indeed does not seem to miss anything, although I personally do not like its UI. Oh, well.

There are better options for macOS than Acrobat Reader, which was designed for Martians, I believe. Have you looked at PDF Expert and PDFPen (and Pro)?
I wrote an article here about the problems of annotations: much of it is the result of the PDF standards, I fear, although Apple’s rewriting of PDFKit and Preview has only made matters worse.
Howard.

Comparing Reader to paid apps is a bit odd. Reader is pretty clear about what it does. It’s not supposed to compete with PDF Expert and PDFPen(Pro). But it does handle a wide range of really bad PDFs reasonably well. The Acrobat team was, for a long time, really painful to deal with from the Mac side (SO MANY STORIES. I wrote an entire script to convert HTML email to PDF just to prove them wrong about one point), but over the last few years, they’ve made real improvements.

I’ve used a lot of other apps, but Acrobat keeps handling the edge cases i’ve gotten over the years better than anything else. If you never get those, then it’s probably a non-issue. But when I need it, ye gods, do I ever need it.

Their UI stuff will always be odd. It’s always been odd. I would dearly love to see how they do UI design and testing, because I bet that’s fascinating.

Not as fascinating as their scripting dictionary, but I bet it’s close.

Thank you. I’m afraid that I’m unable to test that, but several regular readers here do have multiple displays and hopefully will be able to test that.
It’s a pretty gross programming error if it is reproducible.
Howard.

I’m encountering a bug since I upgrade to Mojave (straight from 10.12), similar to the one you listed (Multiple displays – external displays may not activate at login) : I use a mid-2014 MacBook Pro along with a CalDigit Thunderbolt Station 2 that connects to external monitor, keyboard & mouse, Ethernet etc. When waking up the Mac, most of the times (4 out of 5 I’d say) both the internal and external screens remain off while the internal keyboard backlighting turns on (external keyboard may or may not be active). I need to unplug the Thunderbolt cable to instantly wake up the internal screen, wait a few moments until the Mac gets ready, then plug the TB cable back. This works most of the time, but can randomly lead to internal screen being active with the external one remaining off (while external keyboard, mouse and Ethernet being active). In that case unplugging the TB cable and plugging it back to the second TB port on the Mac fixes the issue… Not a big deal but really poisoning !

I was wondering how can one “put the internal display to sleep, then wake it” back on ?

Thanks for your continuing work for the Mac users community, your site is a gold mine !

Thank you. I’m sorry that you’re having these problems.
One trick for putting a display to sleep at will is to enable it using the Hot Corners button in the Screen Saver tab of the Desktop & Screen Saver pane. That might just provide the nudge to the system to sort your displays out properly, perhaps.
Howard.

Unfortunately, it doesn’t help, ctrl+shift+power doesn’t bring any screen back to sleep (keyboard backlighting remains active). So I need to dig this further, and eventually bother CalDigit about this.
Thanks anyway 🙂

There is another bug. Disk Utility, when formatting a drive with a mounted volume, it almost always fails the first time, and not the second time, because it does not wait long enough from unmounting till it starts creating a new partition table. This has been persistent for MANY os versions, I am amazed they do not fix it.

New for me in Mojave 10.14.5 – I’ve never seen this exact Finder glitch before: when I open any window in Finder which is set to auto-sort by Name, the icons are closer together than I have set them (in my case, maximum spacing). If I navigate into an enclosed folder, and then click the Back button, Finder now shows the correct, desired spacing.

I’m not sure that’s a bug in macOS, but it sounds like a problem on your Mac. How long has this been a problem? Since upgrading to Mojave, or just with this latest update? If the latter, I’d be inclined to download and install the 10.14.5 Combo updater from Apple.
Howard.

smbd(8) is completely messed up, some thread will take a pthread_rwlock and hold it indefinitely, until threads pile up and the process hits the dispatch soft limit. Killing the process just restarts it, definitely a code-level issue. It’s interesting that smbdiagnose doesn’t collect a sample by default, it assumes network involvement.

Option-Drag on a large folder (a virtual machine directory for instance) visually indicates that the directory has been copied to the new location, however it happens without the progress bar or any time. Clearly this is a fake copy and not a real copy. Copied files are now unreliable. Seems new in 14.5.

Has anyone else seen this please?
I’m presuming that you’re copying between different volumes so that APFS isn’t ‘cheating ‘, although it normally doesn’t with whole folders. What happens when you try to open the copied folder?
Howard

Wow! 10.14.6 here – just stumbled into a frustrating bug, dunno if it’s been there from past versions…
I’ve got some documents (actually folders/packages/bundles) which were renamed recently, after having been copied from another machine.
Now these documents in a “find” window (and in the “recents” window) show their old name, but if you select them and go “get info” (and also if you ls that directory in terminal) they do show their new name. Also in any finder window except “recents” and “find”, they show their new name. I can try renaming them to anything else (via either the “get info” or by clicking on their name on a regular finder window), they do rename, but still the old (first) name remains “stuck” in the “find” and “recents” window..!! (btw, clicking on their old mistaken name on one of those windows, does not work at all…)
Doing an mdimport -f on the folder containing one of those documents, does not solve it either.

not that there are not easy solutions (works: duplicating and keeping the copy, remove “copy” from name ; also works: sending to trash and back ; does not work: moving to other folders). But the damn thing about the bug is you don’t know how many more of these are lurking in your recently migrated mac…