Skip to content

Remove remaining IE/MSHTML drag-drop, HTML Help, and legacy IE web-client baggage

Summary

The old IE-hosted MiniMule and its browser-host helper are gone, and the current native MiniMule is eMuleBB-owned. A smaller set of IE-era baggage still remains:

  • native MSHTML parsing in DropTarget.cpp for HTML drag/drop and clipboard paste
  • the old HTML Help entry path in app startup and the main dialog
  • explicit Internet Explorer browser checks in frozen web-interface templates
  • one lingering _ATL_NO_DOCHOSTUIHANDLER define in Stdafx.h

None of this is core transfer functionality. The remaining native IE/MSHTML surface now exists mainly to support rich-HTML link intake and old help/browser compatibility behavior.

Current State (revalidated 2026-04-19)

Native MSHTML dependency

DropTarget.cpp / DropTarget.h still use MSHTML COM types such as:

  • IHTMLDocument2
  • IHTMLElementCollection
  • IHTMLAnchorElement
  • CLSID_HTMLDocument

Current purpose:

  • parse dropped or pasted HTML fragments/documents
  • extract ed2k:// and magnet:? links
  • forward them to ProcessED2KLink(...)

This is the clearest remaining native IE/MSHTML dependency after the landed MiniMule removal.

HTML Help path

  • Emule.cpp still calls EnableHtmlHelp()
  • EmuleDlg.cpp still keeps the HtmlHelp(...) / AfxHtmlHelp(...) path

This is old HTML Help infrastructure, not a product-critical runtime feature.

Legacy IE client-side checks

The shipped web-interface templates still contain explicit navigator.appName == "Microsoft Internet Explorer" style branches:

  • srchybrid/webinterface/eMule.tmpl
  • srchybrid/webinterface/eMule Light.tmpl
  • StatisticsTree.cpp

These are not native-hosting dependencies. The templates themselves are now a frozen surface under FROZEN-SURFACES, so the preferred cleanup is template deletion or no-op compile preservation, not browser compatibility maintenance.

Other leftover marker

  • Stdafx.h still declares _ATL_NO_DOCHOSTUIHANDLER

After MiniMule removal, this looks like leftover browser-hosting baggage unless another active consumer is revalidated later.

  1. Do not spend support work on web template browser compatibility; delete the template surface if the cleanup reaches that area
  2. Revalidate whether DropTarget still needs HTML/MSHTML parsing or whether plain-text and URL-drop handling is sufficient
  3. Decide whether the HTML Help path should be retired entirely or kept as an intentional legacy support surface
  4. Remove _ATL_NO_DOCHOSTUIHANDLER if no active consumer remains

Acceptance Criteria

  • [ ] No native MSHTML COM parsing remains in DropTarget.*, or the item is explicitly re-scoped to keep that path
  • [ ] Legacy web templates are either removed or left explicitly frozen without functional support/test requirements
  • [ ] HTML Help is either removed from active runtime flow or the remaining scope is documented as intentional
  • [ ] Leftover browser-hosting baggage such as _ATL_NO_DOCHOSTUIHANDLER is removed if unused

Notes

  • This item is intentionally narrower than REF-025; it tracks the remaining IE-era leftovers after the landed MiniMule removal
  • WinINet usage elsewhere in the tree is older Windows internet API debt, but it is not the same thing as native IE/MSHTML hosting and is therefore out of scope here
  • Post-MSHTML removal, Debug builds exposed that the removed <afxdhtml.h> include had also been an accidental source of MFC private symbols. The app now makes that dependency explicit through Stdafx.h including <afxpriv.h>. This is not an IE/MSHTML dependency and should not be treated as a reason to reopen rich-HTML parsing. Future MFC cleanup can separately review current private-symbol users such as HID_BASE_PROMPT, WM_KICKIDLE, docking context fields, and floating dock-bar checks.