I'm running InDesign 14.0.2 on a macOS High Sierra (10.13.6)

In a script i created I have a Dialog. It has a button that opens another dialog.

Before my last indesign-update (CC 14.0.2) the second dialog would open and when i closed it, i could use the previous dialog window again.

Now with the Update when I open the second dialog and close it again, i cant use (or close) the previous dialog and it blocks me from using InDesign. I can move the dialogwindow around but thats it so i have to restart indesign.

I tested this on two colleague's system with the same InDesign version (14.0.2) and had the same result.
I tested this on a colleague's system with 14.0.1 and it worked as intended. (Also it worked for me before the update)

Attached is a testscript with the dialogs and a short videodemonstration.

Pls fix this, as we use this function to change settings in configfiles for scripts we use.

Version: InDesign CC2019
Steps to reproduce: Apply a new Master page, with different margins, to a document page with text frame
Expected result: Text frame should resize to fit the new margins of the master page (as before with Layout Adjustment enabled)
Actual result: Page margins change but text frame stays the same. Useless! I have to manually adjust the text block to fit the new margins.

I work in book publishing. When laying out a book, it's often necessary to make changes to the margins of certain pages, either to accommodate the dropped opening of a chapter, or to set a spread a line long or short to avoid unsightly widows. I do this by applying a master page to adjust the margins accordingly. Up until now (assuming Layout Adjustment was enabled), the text frame margins would adjust to match the new master page margins. But in InDesign 2019, Enable Layout Adjustment is gone, and though the page margins change properly, the text frame doesn't change, and I have to manually drag it into shape. This is a big time-waste and a PITA. I've tried fiddling with all the new settings, and nothing restores the old behavior. Someone suggested that creating the document with "Primary Text Frame" enabled would make things work properly, but no luck.

There are multiple listings of the same font in the Find Font menu in CC2019. All information is the same, all applied characters are the same, but there is odd behavior.

--FileA_CC2019_WithDocumentsfontsfolder.png shows double listing of Trade Gothic LT Pro Roman.

--FileA_CC2019_WithoutDocumentfontsfolder.png (when I take away access to Document fonts folder, no other changes), one instance switches to "Regular" instead of "Roman"

--FileA_CC2017_WithDocumentfontsfolder.png shows what happens with I open this file in CC2017 (no double listing)

--FileA_CC2017_WithoutDocumentfontsfolder.png (Document fonts folder hidden) shows what happens with I open this file in CC2017 (no double listing)

I process large volumes of files; this is not an isolated incident nor a corrupted file. Packaging results in InDesign only grabbing the *single* correct font file, so that isn't broken. This behavior with Find Font is seemingly new to CC2019 (I'm working on 14.0.2). The multiple listing of same font, variation of font name when fonts enabled/disabled, and Find Font showing fonts missing that aren't because of what seems to be a name issue in Find Font. Has something changed in the way that InDesign reads fonts/accesses Document fonts folders?

We're facing below issues in the new feature, called 'Import PDF Comments':

(1) If text frames are overlapped and grouped, PDF comments are not embedding correctly, also updating in wrong places (please refer the attachment 1_Error1.png)
(2) PDF comments are not embedding correctly for the grouped frames (please refer the attachment 2_Error2.png)
(3) PDF comments are not embedding correctly for the sub-frames (please refer the attachment 3_Error3.png)
(4) PDF comments are not embedding correctly inside table cells (please refer the attachment 4_Error4.png)
(5) PDF comments are not embedding correctly when the fonts are missing (please refer the attachment 4_Error5.png)

Please check and fix quickly, also let me know, if you need any clarifications on the above reported feedbacks.

Steps to Reproduce:
1. Object->Make QR Code...
2. Input strings "問題は日本語を正常に扱えるかどうか。".
3. Result QR Code is incorrect.

Actual Result:
Sometimes, we got the wrong code in Japanese locale.

Any Workarounds:
Here is Japanese character strings "問題は日本語を正常に扱えるかどうか。".
This was coded into the InDesign try and get "image1.png".
Then, we try to decode it at ZXING decoder. Here is a decoded result (image2.png)

42 1e 59 58 fe 9a 18 ce 38 1a fe 69 7a 5e 69 ca
ce 8a a9 ee 38 29 2e 6a da 3e 5b 8b 8e 38 1a be
68 9b 1 8 0a ce 09 78 c2 17 9c 14 11 81 a7 38 24
63 02 5e 70 10 06 08 00 ec 11 ec 11 ec 11 ec 11

The top has been encoded in the beginning have you because of 8-bit byte mode from the head with a "0x4". Then, the character codes are used here is UTF-8. Until "... 正常に扱" it has been encoded successfully. But it can not be decoded completely normal the next "え"(12th character) or later.
In fact, this string is a mode change in a 35 byte. And, now, the used is "0x8" So KANJI Mode. Subsequent bytes will be the number of characters. "0xa" So 10 characters. And compressed into one character 13bit in this mode. Actual rest of the string is "えるかどうか。" 7 is the letter does not match the number of fundamental places because. The code itself will be inferred from the simple result of decoding.A byte sequence that has been obtained is decoded as SJIS but UTF-8 has over encoded as it is. The character code must perform the encoding by converting to SJIS from KANJI Mode. 7 is why this in a letter 21 bytes because it is each of the three-byte count of and 10 characters to compress the two-byte set to 13bit come out.
A decoder is handled by SJIS because of KANJI Mode. So characters are garbled.

KANJI Mode makes incorrect code words in InDesign and why mode change in a 35 byte?
In case of "問題は日本語を正常に扱えるかどうか。" all characters are non-Ascii code range and all characters in SJIS code range. It must be encoded KANJI Mode if using KANJI Mod.
However, I think it is better to encode 8bit byte mode with UTF-8 all characters.

Please reference below:

81 28 31 32 a0 29 ae 3a 7f da 3a 82 e0 bb 35 96
85 24 b6 a1 26 0b 48 4a 42 8e 12 40 94 80 08 00
ec 11

It is correct code words in KANJI Mode with "問題は日本語を正常に扱えるかどうか。"(image3.png/Made by QR Code Maker Pro in Adobe AddOns)
And below codes encoded in 8bit byte mode with UTF-8

43 6e 59 58 fe 9a 18 ce 38 1a fe 69 7a 5e 69 ca
ce 8a a9 ee 38 29 2e 6a da 3e 5b 8b 8e 38 1a be
68 9b 1e 38 18 8e 38 28 be 38 18 be 38 1a 9e 38
18 6e 38 18 be 38 08 20 ec 11 ec 11 ec 11 ec 11
ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11 ec 11

I recommend discarding KANJI MODE. I think all characters to be encoded 8bit byte mode with UTF-8 characters is the better way.

To Adobe, Please check ID-4170816.

The inclusion of ~F in a character class invalidates grep expressions in endnotes.

InDesign version: 14.0.2.324 (with the GREP fix installed)

Steps to reproduce:

1. Open the attached document. It contains a single page with text and an endnote.
2. In the GREP tab of the Find/What window, enter the following GREP expression:

\d[^.,;~F]+

And target the document. The expression matches from a digit up to the next period, comma, semicolon, or footnote marker.

Expected result: The expression should match some text in the main text and in the endnote.
Actual Result: The expression does not match anything in the endnote.

To show that it's ~F that's the problem, use this expression:

\d[^.,;]+

It matches in the main text and in the footnote, as expected.