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 ?

How to repeat the issue:

1. Activate Clipboard history in windows settings (win 10)


2. Copy a random number to your clipboard (my testnumber "-2,375")


3. Create a new document and place a rectangle (or random object) on your page


4. Select the object and click (focus) in the field for the y-coordinates


5. hit "windows+V" to open your clipboard history (must be activated in the settings)


6. Click on your previous copied number.

6-Bug. The number has been pasted two times in the y-coordinates field.

Test system:
- Win 10 pro (1809)
- current Indesign CC version (how to check the actual version?)

By the way, if you try the clipboard history in a text field in inDesign, it works totally fine.

Thanks for your help.

Using CC2019 on a Mac running High Sierra

Steps to reproduce:
1) Create a document with a few hyperlinks in it.
2) Whilst this document is open, open a 2nd document, and copy/paste the links from one document to the other.
3) Save both and close.
4) Trash source document

Expected result: hyper links should work in Target document as expected.

Actual result: hyperlinks all appear broken in document. Whilst an exported PDF appears to still work, ID reports all those links as broken.

Other details:
If you retrieve the source document from the trash, it the links in the target document suddenly start working again, meaning your not actually pasting the hyperlink, but theres some sort of link that exists between the source and target document.

Saving target file as a new file, saving as idml, has no effect – those links are still tied to the source document.

This in an absolute tragedy if you are working on large documents with lots of links, and needs fixing ASAP

The Prevent Manual Positioning creates a Locked Object, but unlocking the widget doesn't remove the Prevent manual override.

When you check to "Prevent Manual Override" an anchored object receives a lock adornment. An object Style can be created from this object. If that lock is unlocked the Object style shows as override, but the "Prevent Manual Override" is still checked.

If the object style is redefined. The lock adornment is still unlocked, and the "Prevent Manual Positioning" is still checked. Reapplying the style locks the object.

There should be more consistent behaviour of "Prevent Manual Positioning" and the "Lock". Even though they are similar they are not the same. If checking "Prevent Manual Positioning" activates the Lock. Unlocking should also uncheck "Prevent Manual Positioning".

I am using InDesign CC 2019 14.01 x64.

Once a stroke weight has been added, if you then change the stroke weight back to zero, then when you export to pdf the pdf will have a stroke weight added to the text, even though the indesign document looks correct. It may not have the original amount of weight that was added, but it will definitely have what looks to be around a .2 weight added.

However, if you were to start a new document, then add stroke weight, then click edit - undo stroke weight, then it would export to pdf just fine. However if you saved the document with the stroke weight added, and then re-opened and changed the weight to zero, then when you export to pdf it will have a stroke weight still added (around .2, same as above).

So once you have saved a document with the stroke weight added, then no matter what you do the document will not print without the added weight.

If ANYBODY has any idea how to fix this then PLEASE let me know :) I was on chat for 4 hours but no luck. I'm really not trying to redo this 600 page book.

Indesign CC 2019 (Version 14.0.1)
Mac OS Mojave on Mac mini (Late 2014)

Hello, I have a document ready to import XML data, with existing XML structure and tagged elements in page.
Afterwards I import XML data into XML structure and then duplicate (copy and paste) text frame that contains a table with an image placed into a cell table.
If I try to delete resulting duplicated XML tag, application crashes.
Same result if I duplicate (copy and paste) XML tag directly.

These are the steps:

1) Open document with prepared XML structure and tagged elements in page.
2) Import XML file into XML element.
3) Duplicate text frame that contains table (copy and paste)
4) Delete duplicated "Table" tag

The problem seems to be in copying XML element (or text frame) and them paste it: resulting XML structure of the element is incomplete for the cell that contains the image.

Nothing happens if I import XML into new document without structured and tagged XML.

Expected result: delete XML duplicated tag
Actual result: application crash