I had the disappearing problem of the scrollbar in the pages panel still after they closed the previous bug? they said it's fixed in 13.1 but not in my version.
I work on mac and pc on the pc version I still had it BUT I read the solution from a mac user about deleting prefs and that helps me.
here is what I did.
close InDesign and search in the InDesign folder for Global Preference Panel cut this one and save it on your desktop. start InDesign and it will give you an error no panic just close it and place the GPP back on the place where you took it out. now start InDesign and voila the scrollbar is back ;) I think this is the same as deleting your prefs maybe a dummie way but it works. have fun

Code below works fine on Windows and CC 2018 on Mac. But CC 2019 Mac it hangs the app once clicking the OK button in window 2. I've tried three different Macs including Mojave and High Sierra. All the same result. Pretty sure it's not just me. This bug has broken a number of my scripts that present a secondary window for saving settings.

var w1 = new Window("dialog", "Window 1");
var btnOpenWindow2 = w1.add("button", undefined, "Open Window 2");
var btnOk1 = w1.add("button", undefined, "OK");
btnOpenWindow2.onClick = function () {
openWindow2();
};
btnOk1 = function () {
w1.close();
};
w1.show();


function openWindow2 () {
var w2 = new Window("dialog", "Window 2");
var btnOk2 = w2.add("button", undefined, "OK");
btnOk2.onClick = function () {
w2.close();
};
w2.show();
}

We are developping a plugin for inDesign and while testing a new feature on a Mac we noticed that sometimes InDesign was crashing. We managed to reproduce this bug in a very simple indesign script that make inDesign crash 100% of the time and I'm looking for a way to get around this inDesign bug.

The crash occurs when we programatically add an htmlItem to a pageItem then close the document too quicky, It's only on Mac, doing that on windows works perfectly. The crash error seems to be a memory usage problem on inDesign's side.

Here is the script code :

var document = app.activeDocument;
var sourcePageItem = document.allPageItems[0];

sourcePageItem.htmlItems.add(
document.activeLayer,
LocationOptions.AT_END,
sourcePageItem,
{
geometricBounds: sourcePageItem.geometricBounds,
htmlContent: '<b>Hello</b>',
}
);

document.close(SaveOptions.NO);

other observations :

-Doing a sourcePageItem.htmlItems[0].remove(); to remove the htmlItem after adding it doesn't change anything, so the problem comes from using the function htmlItems.add() and not having an htmlItem in the document.
-Delaying the close by using $.sleep(5000) before fix the crash, but we can't rely on it as the delay needed increase with the number of htmlItems added and it might be different from a computer to another due to performances.
-Saving the document or not doesn't change anything


I've added my clean document with just a rectangle frame, the script and the crash report on this url : https://we.tl/t-uFpX658s0o since we can't add an indeed file to the post

If there is no way to fix it, do you have an idea to get around this inDesign bug ?

We are developping a plugin for inDesign and while testing a new feature on a Mac we noticed that sometimes InDesign was crashing. We managed to reproduce this bug in a very simple indesign script that make inDesign crash 100% of the time and I'm looking for a way to get around this inDesign bug.

The crash occurs when we programatically add an htmlItem to a pageItem then close the document too quicky, It's only on Mac, doing that on windows works perfectly. The crash error seems to be a memory usage problem on inDesign's side.

Here is the script code :

var document = app.activeDocument;
var sourcePageItem = document.allPageItems[0];

sourcePageItem.htmlItems.add(
document.activeLayer,
LocationOptions.AT_END,
sourcePageItem,
{
geometricBounds: sourcePageItem.geometricBounds,
htmlContent: '<b>Hello</b>',
}
);

document.close(SaveOptions.NO);

other observations :

-Doing a sourcePageItem.htmlItems[0].remove(); to remove the htmlItem after adding it doesn't change anything, so the problem comes from using the function htmlItems.add() and not having an htmlItem in the document.
-Delaying the close by using $.sleep(5000) before fix the crash, but we can't rely on it as the delay needed increase with the number of htmlItems added and it might be different from a computer to another due to performances.
-Saving the document or not doesn't change anything


I've added the script and my clean document with just a rectangle frame with this post.

If there is no way to fix it, do you have an idea to get around this inDesign bug ?

Using version 14.0.2 x64 under Windows 10.

Working on a 356-page book. Three types of crashes occur consistently:

1 - When I export to PDF.
2 - When I add pages, usually in increments of 10.
3 - When I switch between single-page layout and 2-page spread layout.

After every crash, when I go to open the file, inDesign offers to auto recover the file. When I say yes, InDesign warns me that the file might be corrupt. I always open anyway. After 3 months working on this book, I can't afford to start over, so I hope for the best.

Three of the crashes have caused significant problems.

1 - The first 38 pages had been deleted. I had to completely redo them.
2 - The even-page master had been applied to all pages. I had to highlight all the odd pages and re-apply the odd-page master.
3 - Tonight's crash resulted in master pages designations and therefore page numbers on all 356 pages being deleted. I have to highlight all the odd pages, re-apply the odd-page master, highlight all the even pages, and re-apply the even-page master.

I have been using InDesign since the PageMaker days but my experience over these past three months is going to cause me to look elsewhere.... Word, Blurb, etc.

SITUATION
We migrated our old Active Directory "OldAD.ads" to a complete new one "NewAD.ads"
We use InDesign CC2019 (latest Version)

All out file-shares are mounted on client computers with Microsoft DFS-Links.
- Old DFS-Link: \\OldAD\DFS\OldShare - The DFS-Links points to a share on our old fileserver: \\OldFileServer.OldAD.ads\Share_OLD
All shares on the old fileserver are closed, so the DFS-Links have no destination but are still "available".

- New DFS-Link: \\NewAD\DFS\NewShare - The DFS-Links points to a share on our new fileserver: \\NewFileServer.NewAD.ads\Share_NEW

Both fileservers hold "their" (Active Directory based) DFS-structure.

Of course, all users open their files on the new fileserver, shares are mounted via the new DFS-structure.

THE REAL STRANGE ERROR
As long as the old fileserver and old Domaincontroller are up, InDesign acts as expected: We open an old document, the windows "missing links in document" comes up, we fix the broken links, the document opens, everything is fine.

BUT when I shut down the fileserver and the last domaincontroller, the following happens: We open an old document (containing links to documents, that were on shares mounted via the old DFS on our old fileserver), InDesign freezes and the mouse pointer circles. I waited up to 30 minutes, nothing happened. And now comes the really strange thing: When I unplug the network cable (no joke), the "missing links in document"-windows comes to front and I can fix the broken links after plugging in the cable again.
When I turn on the old fileserver and domaincontroller again, everything works fine again.

I can reproduce this error on all our 4 InDesign-workstations. The error only appears when the broken path contains a DFS-Link and the link is not available any more - no matter if the "real" share behind the link is available or not.
The InDesign option "Ignore missing links when opening a document" does not affect the error, it happens when the option is set or not.