Bug 187937 - REGRESSION (r231456): MarsEdit's rich editor fails to locate its internal frame
Summary: REGRESSION (r231456): MarsEdit's rich editor fails to locate its internal frame
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar, Regression
Depends on:
Blocks:
 
Reported: 2018-07-23 18:30 PDT by Daniel Jalkut
Modified: 2018-07-24 17:22 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Jalkut 2018-07-23 18:30:46 PDT
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.
Comment 1 mitz 2018-07-23 18:36:03 PDT
Not clear why this needs to be app-specific rather than linked-before-the-change-based.
Comment 2 Daniel Jalkut 2018-07-23 19:32:56 PDT
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?
Comment 3 Radar WebKit Bug Importer 2018-07-24 08:30:40 PDT
<rdar://problem/42542254>
Comment 4 Chris Dumez 2018-07-24 16:51:35 PDT
Closing based on internal radar. Doing a linked-on-after check at this point would be too risky. Should be fixed on app-side.
Comment 5 Daniel Jalkut 2018-07-24 17:22:51 PDT
Thanks for considering it anyway!