[webkit-changes] [WebKit/WebKit] 47fb3d: [Mail Compose] Attachment goes missing after wrapp...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 47fb3d640ece77b046fe2d13a5f1a45823262346
      https://github.com/WebKit/WebKit/commit/47fb3d640ece77b046fe2d13a5f1a45823262346
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2022-09-20 (Tue, 20 Sep 2022)

  Changed paths:
    M Source/WebCore/html/HTMLAttachmentElement.cpp
    M Source/WebCore/html/HTMLAttachmentElement.h
    M Source/WebCore/html/HTMLImageElement.cpp
    M Source/WebCore/html/HTMLImageElement.h
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm

  Log Message:
  -----------
  [Mail Compose] Attachment goes missing after wrapping an image in a block quote
https://bugs.webkit.org/show_bug.cgi?id=245432
rdar://98012376

Reviewed by Ryosuke Niwa.

After duplicating an existing attachment-backed image element in the DOM using `cloneNode()` (or
similar DOM functions), `HTMLImageElement.attachmentIdentifier` returns the old attachment
identifier of the cloned attachment rather than the identifier of the clone. This breaks Mail's
bookkeepping around attachment data in Mail compose, and leads to the attachment being lost upon
sending or saving a draft.

This happens because:

1. `HTMLImageElement` has an internal mechanism for keeping track of the attachment ID of the
attachment-backed image it was cloned from, by storing the ID in `m_pendingClonedAttachmentID` and
returning it when asked for the `attachmentIdentifier`, even if the attachment element hasn't been
created yet. This is used to ensure that after cloning an attachment element, removing the original,
and inserting the clone, the cloned attachment-backed image will preserve the unique attachment ID
of the attachment-backed image it was cloned from.

2. `Document` has logic to maintain the invariant that no two attachment elements that are connected
to it ever have the same unique identifier; to do this, we automatically adjust the identifier of
an attachment element upon insertion into the DOM, if the ID collides with that of an existing
attachment in the DOM.

In this bug, (2) adjusts the unique ID of the attachment underneath the image, but the image still
has a `m_pendingClonedAttachmentID` that points to the old ID, creating an inconsistency. To fix
this, we add a mechanism to invalidate the pending cloned attachment ID when the ID of the
attachment under an attachment-backed image changes.

Test: WKAttachmentTests.DuplicateImageWithAttachment

* Source/WebCore/html/HTMLAttachmentElement.cpp:
(WebCore::HTMLAttachmentElement::setUniqueIdentifier):

Move the definition out of line into the implementation so that we can call into `HTMLImageElement`.

* Source/WebCore/html/HTMLAttachmentElement.h:
* Source/WebCore/html/HTMLImageElement.cpp:
(WebCore::HTMLImageElement::didUpdateAttachmentIdentifier):

Clear out the `m_pendingClonedAttachmentID`.

* Source/WebCore/html/HTMLImageElement.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:
(TestWebKitAPI::TEST):

Canonical link: https://commits.webkit.org/254696@main