Images not showing in preview
CompletedI can't get images to display in MMD Composer 5.0.0 (2022.03.19.18.00). Simplest case is ``, but full paths give the same result (and in each case Composer inserts the correct link via drag and drop). Works fine in Composer 4.
-
It works fine for me....
Did you give Composer permission to access other files when it asked?
0 -
I can't remember whether Composer asked for permission, but I have given it full disk access and images still don't display.
Just tested everything again this morning with the same result. Drag-and-drop inserts the correct image paths. But e.g. `` shows nothing, and `` shows only a placeholder. Changing theme or preview CSS makes no difference. In Composer 4 everything is as expected.
Composer 5.0.0 (2022.03.19.18.00). macOS 12.3.1 on an M1 mini.
0 -
And the file is saved to the local drive, correct? Obviously an unsaved file has no path from which to obtain permissions.
And what do you mean by "I have given it full disk access"?
I still can't replicate this.
0 -
This issue of images missing from the preview is real and repeatable for me for two Macs that are set up very similarly, both running Monterey, except that one is Apple silicon and the other is Intel.
On a third Intel Mac, this time with Catalina, everything works as expected.
In each case I’ve used Composer 5 version 2022.05.02.11.46. For the M1 Mac I did a thorough uninstall of Composer 4 and 5, followed by a restart, and currently have a clean install of just Composer 5, with all settings at their defaults and no custom CSS. That hasn’t fixed it.
Yes, all the files in question are saved locally, and I’ve granted Composer’s requests for file access whenever they appear. (By “I have given it full disk access” I meant that in “System Preferences > Security & Privacy > Privacy > Full Disk Access” I also added Composer 5 explicitly, with the aim of bypassing any permissions issues.)
Opening the same file in Composer 4 shows the image preview as expected. Pandoc works too, so for instance I can use Pandoc to create a Word file with the image embedded.
A couple of things I’m seeing might possibly be related. First, when I open an existing file in Composer 5, the preview pane is sometimes blank until I change the text, say by typing a space. Second, when I do see a preview, occasionally the font is vanilla Times Roman until I explicitly select a CSS, even when that same CSS is already checked. You might remember that I reported that issue previously for Composer 4, and it hasn’t gone away.
I’m quite prepared to believe that this is very unusual, and somehow relates to the settings or software on my two main Macs, which as I said are set up very similarly. But equally, it’s specific to Composer 5 as opposed to Composer 4.
0 -
Images hosted on the web display OK, so for instance `` is fine. The same file on my local machine doesn't work. I tried a full path (``), which creates a clickable link in the editor pane but still doesn't show in the preview pane.
Any clues there?
0 -
Charles Butcher - thanks for the details.
1. Gotcha on the full disk access. I have not tried that, because I *need* to make sure that any permissions issues show up, and it defeats the point of sandboxing. *I* know that nvUltra and Composer don't do anything nefarious, but I guess everyone else would just have to take my word for it.... I tried testing it, and I still seemed to require the normal permissions. Images would not appear if I did not grant the access, despite supposedly having full disk access. That seems strange.
2. You can check the preferences to see what in-app access has been granted - `defaults read com.multimarkdown.composer5 | grep bytes` (Having access to a folder includes access to everything inside of it.)
3. If you decline permission for an open document, Composer will not ask again while that document is open. It will ask again the next time that document is opened, if it still needs permission
4. Blank previews are not related to this. And are not related to Composer 4.
5. Re: Times New Roman -- is that the unrendered Markdown source? That is loaded first, and then the HTML is loaded (due to issues in macOS). For short documents it usually happens so quickly that you won't notice, other than a white background before a dark theme is loaded. For longer documents it may be noticeable, or if the CPU is busy.
6. Web images are completely different and don't require any special permissions related to the disk.
Have you tried using a new user account on your machine?
0 -
Thanks Fletcher Penney. You wrote:
6. Web images are completely different and don't require any special permissions related to the disk.
So, since my web images are OK, the working assumption is that this is a permissions issue?
Have you tried using a new user account on your machine?
I have now. Same result, unfortunately.
1. Gotcha on the full disk access... I tried testing it, and I still seemed to require the normal permissions.
That's my experience too. Of course I can't comment on how granting or not granting access affects image display, because I don't see any images, but I confirm that even with full disk access I'm still asked for permission to access individual folders. Which does seem odd.
The folder paths I'm asked to approve are mangled – this screenshot is from when I'd moved my test file to ~/Dropbox/tests/ (though the image reference was probably still to the Desktop):
Could that have anything to do with it? Clicking "Open" in this case added ~/Dropbox to the previous ~/Documents and ~/Desktop, as I confirmed with your terminal command. I assume it should have been ~/Dropbox/tests/, but on the other hand it still doesn't work when both the Markdown file and the image are in one of the "approved" folders, and the image path in the document is correct.
4. Blank previews are not related to this. And are not related to Composer 4.
OK, thanks. Not a huge issue in any case.
5. Re: Times New Roman -- is that the unrendered Markdown source? That is loaded first, and then the HTML is loaded (due to issues in macOS). For short documents it usually happens so quickly that you won't notice, other than a white background before a dark theme is loaded. For longer documents it may be noticeable, or if the CPU is busy.
No, it's the preview pane, and it's persistent – that's to say that waiting, or typing in the source pane, still leaves the preview showing Times. The fix is to select a new preview CSS, even (as I said) the one that's currently checked.
0 -
Yes -- I suspect permissions issue, not an actual "image" issue.
You'll be asked for permission, but Composer was not programmed with the idea that you would grant whole disk access. So that is expected behavior. But even when you decline to give it permission, the images still don't appear, which is not expected behavior.
When it asks for permission, try opening your user directory instead of the directory it suggests.Times New Roman -- yes - I'm talking about the preview.
0 -
Just noticed that the URL to the image you mentioned was in your desktop, but you mentioned Dropbox.
Can you give the full path to (one of) the MultiMarkdown documents in question, and (one of) the images in that document that doesn't work?
Thanks!
0 -
Sorry for any confusion. You're right about that mismatch. I subsequently changed the image reference to `` so that I could move both the test document and the image to various other folders. That abbreviated path should work for an image in the same directory as the MD document, shouldn't it?
I've just opened the document on my desktop and Composer asked for permission, even though `default read` says it already has access to Documents, Desktop and Dropbox. I granted permission again and it still didn't work.
'/Users/charles/Desktop/` and '/Users/charles/Documents/` (for both the image and the MD file) are examples of paths that don't work.
To answer your earlier point, I removed Composer from the full disk access list and restarted. On the Intel MacBook where I have the same problem, I never gave Composer full disk access in the first place.
0 -
Does the path show incorrectly in the permission dialog when Dropbox is not involved? The only time I have seen reports of that happening are when Dropbox is involved.
0 -
I've not seen an incorrect path requested apart from that Dropbox one, so this could well be right.
But notwithstanding my previous comment about being asked for permission even when my home folder was listed showing on the approved list, Composer is no longer asking for permission. Is it safe to use `defaults write` to clear the existing permissions?
0 -
The worst that can happen with defaults is that you lose your customizations and the list of previously opened folders in the navigator. So nothing irreplaceable.
For convenience, I usually save a list of the folders in my navigator, because I feel like the list will never be as good the next time.... :) Otherwise the defaults can be readily rebuilt by running through the preference pane.
0 -
Thanks. `defaults delete com.multimarkdown.composer5 "access folder - /Users/charles/Documents"` etc. worked, and left other settings intact. On opening an MD document in that directory I was prompted to grant access, the path was correct, and the directory reappeared in the settings list. But no preview image, unfortunately.
0 -
1. What happens if you right click in preview and "Reload", and then type something in the editor to trigger an update?
2. Can you create a small test folder with the single MD file and image (verify it doesn't work of course), and then in terminal do a `ls -al` in that directory and paste the contents here?
I am completely unable to replicate this (even in Dropbox). Are you sure you're not running any third party programs/"extensions" that change behavior? Any third party app icons in your menu bar?
The permissions work slightly differently than nvUltra, but the fundamental process is the same, and I'm not hearing of trouble there (and presumably many more testers for nvUltra over the last couple of years compared to Composer over the last few months.) So, I'm really hitting a dead end here.... The weird thing is that it is happening to separate machines for you. So seems to be something in common between the two machines.
0 -
1. Basically nothing. The placeholder for the missing image sometimes displays as a "?" and sometimes as the image title, if there is one, and I think the reload toggled between those states – but I guess that is probably not relevant here. See screenshots (with two different CSS):
2.
~/Desktop/test ᐅ ls -al
total 40
drwxr-xr-x@ 4 charles staff 128 17 May 15:45 .
drwx------@ 15 charles staff 480 17 May 15:45 ..
-rw-r--r--@ 1 charles staff 14931 12 May 19:03 composer4.png
-rw-r--r--@ 1 charles staff 152 17 May 15:45 test.md3. I do have many things in my menu bar, on both machines, though nothing I'd think of as dubious, and I've never noticed any problems related to access permissions before. I'll try safe mode.
0 -
I fully expected safe mode to fix it, but it didn't.
You won't be surprised that nvUltra has the same issue, though it doesn't ask for permissions.
I really appreciate your time, but perhaps we should give up now, at least until you get any more reports like this. I'm always happy to report back if you have any more bright ideas to check.
0 -
Hmmmm....
I always hate blaming a user's machine for a problem, and try to operate on the assumption that odd behavior is due to a bug on my end. That said, a few things I've noticed over 10+ years of troubleshooting bug reports after seemingly exhausting my ability to troubleshoot:
* Sometimes I need to just keep trying and have not properly replicated the issue (still possible here, but I'm about out of ideas.)
* Multithreading issues are a b#*& to track down - each computer has different timing patterns based on RAM, other running apps, CPU speed, OS version, etc. Multithreading/race conditions seem to happen repeatedly to users who experience it, and never to those who don't. I don't think that's the case here.
* Third party "extensions" can be a bear. One issue that was really problematic was tracking down a problem that turned out to be related to DefaultFolderX. So much so that the developer of that program gave me a chunk of code to allow me to disable DefaultFolderX before opening a file open dialog. Users rarely think to consider this, so I have to be specific in asking. I was hopeful about this, but presumably using a brand new user account (without those apps enabled) or safe mode should help here.
* Upgrading the OS "in place" over and over can be bad. Decades ago I learned that sometimes you have to wipe a drive and install the OS fresh and I try to just do that periodically before problems start up. Upgrading repeatedly seems to result in corruption that causes strange errors to happen, and they often seem to be happen in very specific conditions (e.g. only in one application) based on what files/libraries have been affected. On more than one occasion, users have reported consistent problems with nvUltra/Composer that went away after installing a fresh OS on their machine. I don't think I've asked about your upgrade habits, but beginning to wonder if that could be at play here. Obviously asking a user to wipe their drive and reinstall is a time commitment, so I don't take this one lightly. What I do personally is have several external drives that I will sometimes rotate with a fresh OS install and test that way, rather than wiping my current primary drive.
If the macOS upgrade explanation sounds plausible to you, and you have an external drive you can test, that may be a useful next step, but I am not confident enough to say that you *should* do that at this point.
Because this portion of the code is the same between nvUltra and Composer, I am not surprised. They handle permissions differently, but it doesn't sound like a permission issue any more.
You've mentioned custom CSS. I assume at some point you have tried this with completely fresh defaults without any customization of preferences? That may be worth a try just to make sure, but I have low confidence this is the issue.
Otherwise, I don't have a good next step. I'll keep trying to think of things and check back in periodically. But it is not very satisfying to leave it as "you just can't use images in the preview."
0 -
Separately, I figured out the strange path in the dialog box, and this is fixed in the release I just pushed. Might be worth trying, but I am not confident it will fix the particular issue you are having.
0 -
I figured out the strange path in the dialog box
Thanks. Working in the Dropbox folder, Composer now asks for access to my home folder, which I'm guessing is how it's meant to work – and perhaps is not the end of the story, since I gather Apple is about to make life harder for cloud services to integrate with the Finder?
But, as you guessed, no joy with the images.
Fascinating to hear your philosophy. You'll know much more about this than I do, but I agree some Macs are just odd. My first, a Quadra 800, would periodically paste a short phrase – I can't remember what it was, but totally unrelated to anything I'd ever typed – into any frontmost application that would accept text. This went on through the whole long life of the machine, surviving OS upgrades, zapping the PRAM, whatever.
This M1 mini is not my favourite. It needs a lot of restarts, and the display sometimes locks up when it wakes, despite trying several different cables and interfaces. 8 GB of RAM, so that probably doesn't help. The 2015 MBP, on the other hand, just keeps on chugging with a new Samsung SSD and a new battery.
I have seen a clean install sort out all kinds of niggling issues, but I can't see that's the issue here. The mini is just over a year old, and the MacBook had a clean install of Monterey in November because Monterey is picky about old firmware and third-party SSDs. Still, it wouldn't hurt to refresh the mini, so thanks for the hint.
I've now tried safe mode on the MacBook too, and again no joy. So it doesn't seem to be a rogue app or extension. I mentioned above that at one point I'd done a clean install of Composer, so although my custom CSS (which is OK in Composer 4 and Marked 2) is back in place, I don't think it's that. So how can the same rare issue strike two different machines? British electricity, perhaps.
0 -
Thanks. Working in the Dropbox folder, Composer now asks for access to my home folder, which I'm guessing is how it's meant to work – and perhaps is not the end of the story, since I gather Apple is about to make life harder for cloud services to integrate with the Finder?
It chooses the "nearest sufficient ancestor" -- it requests access to the smallest slice of your drive that includes everything referenced by the file (including images, transclusion, css file, etc.).
So how can the same rare issue strike two different machines? British electricity, perhaps.
That's the main thing that still has me scratching my head. My first thought would be that you "did the same thing" to both machine, but that would primarily be installing the same extension, etc. And it is possible that something is installed that is still allowed by safe mode (it looks like some kexts will still be loaded?).
Actually -- a reasonable thought would be some sort of Safari extension/content blocker -- if it affects WebKit at the OS level, it may affect nvUltra and Composer. Marked and Composer 4 use the old WebView, which is no longer supported, and will react to things differently than WKWebView. This may actually be a productive line of inquiry here.
If we can blame it on British electricity, that would be fantastic. ;) But that seems a bit unlikely...
0 -
KextViewr from Objective-See reckons I have nothing installed that isn't part of macOS.
Safari extensions sound very plausible. Any advice on testing those? For instance, would deactivating them be enough or should I uninstall them completely? Restart the Mac?
0 -
I haven’t used anything in safari for macOS. I used some content blockers in iOS but that is it.
If you have any installed I would first see if they can be easily turned off. I would think that should do it rather than having to remove them.
And this is just a guess. Not sure how likely an explanation it is without more information.
0 -
Any joy with the Safari Extension idea? It looks like you should just be able to turn them off in Safari's Preferences if you have any installed.
0 -
Turning off Safari extensions is easy, but unfortunately didn't solve this problem. Thinking about it, I'd hope that extensions couldn't affect anything outside Safari (I'm assuming WebKit is essentially independent of Safari). But in the event that a badly-behaved extension can cause problems for WebKit, might it not need removing completely instead of disabling in the browser?
I'm gearing up for a clean install.
0 -
You’re probably right. This was an attempt to come up with a possible solution after so many failed attempts that didn’t involve you reinstalling on your devices…..
0 -
Well, your patience and careful troubleshooting are much appreciated. But a clean install has fixed it on the M1 Mac. As I reinstall everything I’ll keep an eye on Composer, and in the unlikely event that images stop working I’ll try to find out why. But realistically it’s probably just one of those things. With luck this will fix other small irritations too.
0 -
I admittedly have mixed feelings about this. I'm sorry that you had to go through the hassle of a clean install. But I'm glad that the issue is fixed for you, and that I didn't prematurely blame a bug on your machine for a coding error on my part.
Hope this is the last issue you have!!
0 -
Thanks for all your excellent support. Pleasant surprise number one after the reinstall is that when I wake the machine I can now sign in with Touch ID (which previously worked for other things, but not login). And there will be other improvements, so this was not a waste of time.
Now, onwards to refine the already excellent Composer 5 so that you can start charging some money for it!
0
Please sign in to leave a comment.
Comments
29 comments