Report your bugs here - if someone else has already mentioned the same bug, just add on to their post with as much info as possible to make the hunting easier.
I create links to Amazon for the albums in my database and since upgrading to macOS High Sierra (including the latest patch) these Amazon links have been misbehaving in the following ways:
Scrolling through the open links has the effect of the right side of the displayed URL to turn black.
In another instances displaying the URL will cause CDpedia to become unresponsive and the only way out is to force quit CDpedia.
NOTE:
My SSD has been automatically converted over to APFS.
The SSD is on a Macbook Pro 9,1.
My Amazon links are created by dragging the URL from the Safari address field and by dropping it on the album details in CDpedia.
To reproduce these issues:
To reproduce the scrolling display issue, create the following link in an album using the method described in the above note.
Thank you for all the exact details. I am booted into 10.12 right now, but will take a look as soon as I am back on 10.13. Although I skipped the APFS reformatting, I might have to take that into account.
Another way to reproduce this is to right-click on the album cover and selecting "Open Google Images".
Browse and click on an image then right-click on that image to make it the cover.
This also causes CDpedia to stop responding and where you have to force quit it.
Thank you for the additional steps. I was able to repeat the half black screen when browsing, I am hunting it down, I change in the way webkit is rendering the HTML. Still not the freeze, but this extra method of reproducing it should help..
I'm having the same exact issues in Bookpedia. Was happening in the prior version and the updated one I just installed today (5.6). For me, it was happening on macOS 10.12 (Sierra) also.
It's a regression bug in MacOS 10.13 (High Sierra). We are looking to work around it in the next version and will let you know when we have a beta ready for testing. Might take a little time as the work around requires a 10.12+ only version of the Pedias.
First of the betas is ready with a completely replaced details web view engine. Not only should it fix the bugs but should be faster as well. The betas are 10.12+ only and can be found at the usual links. The betas will self update to the latest betas as we go along (or that is the plan as an updated self updater is also included).
If you are already on the beta you must manually download this version the first time. Feel free to rename it without the beta version and use it as your regular version.
In CDpedia 5.9 Beta 86, the web page load times and when dragging and dropping a URL from Safari are definitely faster in the beta. No more lock ups.
Here are a few items that I have noted.
1. It would seem that the browse forward and backwards button no longer takes you to the next link if multiples ones were entered under Links.
2. Also noticed that PDF and graphic (JPG, PNG) files open in Preview rather than in the viewer area.
3. When I click on a link to a JPG file, the size of the viewing area changes. Note that Ppreview needs to already be launched in order to reproduce this bug. This does not happen with PNG files.
The self updater in CDpedia 5.9.1 Beta 87 works. When I launched the app, I was prompted that there was an update available. Also works for Bookpedia and DVDpedia.
PDFs and graphics now load in the viewer but I notice an odd behaviour with the back and forward buttons. Here are the steps to reproduce this.
1. Create these links in the following order:
- Web
- PDF
- Image
NOTE: I used drag and drop for all 3 links.
2. Click the web link first. Notice that the forward and backward buttons are disable.
3. Click Done.
4. Now click the image link. Note that the backwards button is enabled. At this point you can toggle backwards to the PDF and web link then forward to return to the image.
Thank you for the exact steps. It was something I was trying to decide how to handle. I did not want to overwrite the default back/forward behavior for web links, as it might be confusing. If you select the web link, you are likely to then follow a link on the page and would expect the back button to bring you back to the previous page and not the previous link.
I figured if you select something other then the web link, you are more likely to browse through the links and did not want to break the browsing when you hit a web link. If you started at the beginning and had:
Image
Web
Image
I would expect to keep going from the web to the image, so I did not break it when starting with a regular link, but left the browser behavior when starting directly with the web link.
I think this is the least confusing of all the options as the links behave the same after the view is extended to full window size and does not change behavior half way. But of course I might be wrong. I think only testing will tell you what users find more comfortable.
I was thinking about that when I was writing my last response. It's probably a wise decision to maybe not use the forward and backwards buttons to navigate the links but to instead only use these to navigate within the web links themselves (default function).
It would mean have to click each link individually rather than navigate between them using the buttons. Even have these buttons not appear at all when clicking other formats such as PDFs to images. I would be OK with that but other users might not be.
I do not know if this would be possible but maybe adding a Next and Previous buttons that be used strictly for the links themselves would be a solution. These would always be there and the arrow button would only appear with web pages only.
Your solution would be actually the least confusing of all, but I think the dual propose works for the most part (it's not often that a user uses more than one of those two versions when selecting a link), but I'll flag it in case it keeps coming up in support messages.
