REGRESSION (r231456): MarsEdit's rich editor fails to locate its internal frame

• Component: Frames
• Status: RESOLVED WONTFIX

[Daniel Jalkut]

Similarly to https://bugs.webkit.org/show_bug.cgi?id=186197, the change in behavior for findFrameNamed: has introduced a variety of bugs to MarsEdit, all based in the fact that its internal method for locating a frame in its rich text editor are now failing.

There are a variety of issues here but one easy to demonstrate problem is that a customized background color on the rich editor is not conveyed as it should be:

1. Download MarsEdit 4.1.2 from https://red-sweater.com/marsedit/
2. Launch, and cancel creating a new blog.
3. Create a new post document (Cmd-N). Select "Edit Plain Text" if prompted.
4. Open Preferences -> Editor, and set the background editor color to something non-white.
5. Observe the background color changed in the plain text editor.
6. Select Post -> Edit Rich Text

The background color should be changed in the rich editor, but it is not because the internal mechanism to locate the rich editor IFRAME has failed. The IFRAME is identified as "RSHTMLContent_ifr" on macOS 10.13 and earlier, but on current versions of WebKit including those shipping in macOS Mojave, the frame gets the generic "<!--frame1-->" name.

I plan to work around this. It's a little trickier than is should be because the IFRAME in question is created by TinyMCE internally to its creation of the rich editor. I don't know what the criteria are for special-casing apps along the lines Colloquy was special-case (_needsFrameNameFallbackToIdQuirk), but it would be nice to spare users of older versions of MarsEdit the failures that this regression causes.

In case it can MarsEdit can be special-cased, it would ideally cover 3 bundle identifiers:

com.red-sweater.marsedit (MarsEdit 3)
com.red-sweater.marsedit.macappstore (MarsEdit 3 MAS)
com.red-sweater.marsedit4

All current versions up to and including MarsEdit 4.1.2 are affected by this regression.

Not clear why this needs to be app-specific rather than linked-before-the-change-based.

[Daniel Jalkut]

Doing it by pure linked-on-or-after seems like an easier solution, and would cover other incompatibilities that haven't been discovered yet. It seems likely that there are at least some more out there!

Is it useful for me to file a separate Radar about this issue?

[Radar WebKit Bug Importer]

<rdar://problem/42542254>

[Chris Dumez]

Closing based on internal radar. Doing a linked-on-after check at this point would be too risky. Should be fixed on app-side.

[Daniel Jalkut]

Thanks for considering it anyway!