feat: 🎉新增多窗口功能

[wxfengg]

🎉新增多窗口功能，可以让 Tab 独立新的窗口，也可以合并 Tab 窗口

[Copilot]

Pull request overview

This PR adds comprehensive multi-window functionality to the Markdown editor, allowing users to drag tabs out to create new windows and merge them back. The implementation spans main process window management, renderer process UI interactions, and IPC communication between processes.

Changes:

• Introduced windowManager.ts to centrally manage editor windows, tab drag-follow mechanics, and merge preview system
• Extended tab management with tear-off capabilities, cross-window file deduplication, and single-tab window dragging
• Refactored window state tracking from global variables to per-window maps for multi-window support

Reviewed changes

Copilot reviewed 11 out of 12 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
src/shared/types/tearoff.ts	New shared type definitions for cross-process tab data transfer
src/types/tab.ts	Added isMergePreview flag for temporary preview tabs
src/main/windowManager.ts	New window manager with tab tear-off, merge preview, and window tracking
src/main/ipcBridge.ts	Refactored IPC handlers for multi-window support with per-window state tracking
src/main/index.ts	Integrated window manager tracking for main window
src/renderer/hooks/useTab.ts	Added tear-off initialization, merge preview, and single-tab drag handlers
src/renderer/hooks/useFile.ts	Integrated cross-window file deduplication checks
src/renderer/components/workspace/TabBar.vue	Implemented drag detection, tear-off triggering, and visual feedback
src/renderer/global.d.ts	Added type definitions for new IPC methods
src/preload.ts	Exposed new IPC methods for tab operations
lang/index.json	Added test localization entry (appears to be temporary)
lang/index.js	Minor comment updates

Comments suppressed due to low confidence (5)

src/main/windowManager.ts:296

• The startWindowDrag function doesn't clear the global state variables windowDragSourceId and windowDragTabData before starting a new drag (line 294 only stops the interval). If startWindowDrag is called multiple times in rapid succession or if the previous drag didn't properly clean up, these variables may retain stale data. While stopWindowDrag() is called first, it doesn't reset the source ID and tab data. Consider resetting these in stopWindowDrag() or at the start of startWindowDrag().

  stopWindowDrag();
  windowDragSourceId = win.id;
  windowDragTabData = tabData;

src/renderer/hooks/useTab.ts:106

• There is a potential race condition in the tear-off initialization logic. The initFromTearOff function runs asynchronously (line 83) while the default tab is synchronously added (line 99). If the initialization completes quickly, it replaces tabs.value with a new array (line 61), which might conflict with the onOpenFileAtLaunch callback (line 102) that checks for and potentially removes the default tab. This could lead to unexpected behavior depending on timing. Consider adding synchronization logic or checking if tear-off data exists before creating the default tab.

// 立即发起初始化请求（不阻塞模块加载）
_tearOffInitPromise = initFromTearOff().then(() => {
  _tearOffInitPromise = null;
});

// 先同步创建默认 Tab（确保 UI 立即可用），tear-off 初始化成功后会替换它
const defaultTab: Tab = {
  id: defaultTabUUid,
  name: defaultName,
  filePath: null,
  content: "",
  originalContent: "",
  isModified: false,
  scrollRatio: 0,
  readOnly: false,
  isNewlyLoaded: true,
};
tabs.value.push(defaultTab);
activeTabId.value = defaultTab.id;
scheduleNewlyLoadedCleanup(defaultTabUUid);
window.electronAPI?.onOpenFileAtLaunch((_payload) => {
  if (tabs.value.length === 1 && tabs.value[0].id === defaultTabUUid && !tabs.value[0].isModified) {
    tabs.value = [];
  }
});

lang/index.json:3451

• The sample markdown content in the localization entry contains a spelling error: "Hello Word!" should be "Hello World!" (line 3451).

    "zh-cn": "\n<br />\n\n# MilkUp\n\n<br />\n\n> 这是一段测试文字\n\n<br />\n\n***\n\n<br />\n\n* item1\n* item2\n* item3\n\n代码：\n\n```JavaScript\nconst text = \"Hello Word!\"\nconsole.log(text)\n```\n\n<br />\n\n| 1  | 2  | 3  |\n| :- | :- | :- |\n| 1  | 2  | 3  |\n| 1  | 2  | 3  |\n\n\n",

src/renderer/components/workspace/TabBar.vue:179

• The promise chain at line 177 lacks error handling. If getWindowBounds() fails or rejects, the error will be silently swallowed. While tear-off detection will gracefully fail due to the null check at line 87, it would be better to add .catch() to handle and log any errors for debugging purposes.

  window.electronAPI.getWindowBounds().then((bounds) => {
    cachedBounds = bounds;
  });

src/renderer/hooks/useTab.ts:43

• The TearOffTabData type is used in the function initFromTearOff at line 43, but this type is not imported. While it's defined in global.d.ts as a global type alias, it would be better to explicitly import it for clarity and maintainability. Consider adding import type { TearOffTabData } from "@/shared/types/tearoff" at the top of the file.

    const tabData: TearOffTabData | null = await window.electronAPI?.getInitialTabData();

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The mergePreviewTargets map is not cleaned up when a window closes. If a window that is either a source or target of a merge preview is closed, stale entries will remain in this map, potentially causing memory leaks. Consider adding cleanup logic in the trackWindow function's 'closed' event handler to remove any entries where the closed window is involved (either as a key in the map or as a value).

[Copilot]

The createEditorWindow function does not handle potential errors from win.loadURL() or win.loadFile() in fastCreate mode (lines 196, 202). If the page fails to load, the window will be shown but empty/broken, and no error will be reported to the caller. Consider wrapping these calls in try-catch blocks and handling errors appropriately, or at minimum logging the failure.

[Copilot]

The offset calculation logic at lines 160-163 has a potential issue. The condition if (clientX && clientY) will be false when either value is 0, which is a valid screen coordinate (e.g., top-left corner of a monitor). This means that if the user starts dragging from exactly x=0 or y=0, the offsets won't be calculated, defaulting to 0. Consider changing the condition to check for undefined/null explicitly: if (clientX !== undefined && clientY !== undefined) or if (clientX != null && clientY != null).

Suggested change

	const clientX = event.originalEvent.clientX ?? event.originalEvent.touches?.[0]?.clientX ?? 0;
	const clientY = event.originalEvent.clientY ?? event.originalEvent.touches?.[0]?.clientY ?? 0;
	if (clientX && clientY) {
	const clientX = event.originalEvent.clientX ?? event.originalEvent.touches?.[0]?.clientX;
	const clientY = event.originalEvent.clientY ?? event.originalEvent.touches?.[0]?.clientY;
	if (clientX != null && clientY != null) {

[Copilot]

The new localization entry "gl01kl7e" (lines 3450-3457) contains test/sample content ("这是一段测试文字", "Hello Word!" with a typo) and only has Chinese translation. This appears to be temporary test data that should either be removed or properly completed with translations for all supported languages (ja, ko, ru, en, fr) before merging.

Suggested change

	},
	"gl01kl7e": {
	"zh-cn": "\n<br />\n\n# MilkUp\n\n<br />\n\n> 这是一段测试文字\n\n<br />\n\n***\n\n<br />\n\n* item1\n* item2\n* item3\n\n代码：\n\n```JavaScript\nconst text = \"Hello Word!\"\nconsole.log(text)\n```\n\n<br />\n\n| 1 | 2 | 3 |\n| :- | :- | :- |\n| 1 | 2 | 3 |\n| 1 | 2 | 3 |\n\n\n",
	"ja": "",
	"ko": "",
	"ru": "",
	"en": "",
	"fr": ""

[Copilot]

Event listeners are registered at module load time (lines 616, 731-733, 738) but are never cleaned up. In a single-page application, if this module is ever re-imported or if the component using it is destroyed and recreated, these listeners will accumulate, causing memory leaks and potentially triggering handlers multiple times. Consider implementing a cleanup mechanism or using a Vue lifecycle hook to remove these listeners when appropriate.

[Copilot]

The IPC handlers for tab tear-off operations (lines 480-533) lack input validation. Parameters like screenX, screenY, offsetX, offsetY should be validated to ensure they are finite numbers and within reasonable bounds. Additionally, tabData should be validated to ensure it contains required fields with correct types before being processed. This is especially important since these values come from the renderer process and could potentially be malicious or malformed.

[Copilot]

In the startDragFollow function, there's a race condition check at line 381 (if (!dragFollowReady) return), but dragFollowState is set at line 411-417 after this check. If cancelDragFollow is called between line 381 and 411, it will set dragFollowReady = null but dragFollowState will still be set afterwards, leading to an inconsistent state where the state exists but the promise doesn't. Consider checking dragFollowReady again before setting dragFollowState, or restructuring the logic to be more atomic.

[Copilot]

The file watcher logic at lines 773-816 has a potential issue: when a window closes, its files remain in watchedFiles and continue being watched. Over time, especially with multiple windows opening and closing, the watcher will accumulate files that are no longer open in any window. Consider tracking which files are open in which windows and only unwatching files when they're no longer open in any window. This could be done by integrating with the windowOpenFiles cleanup in windowManager.ts.

[Copilot]

There is significant code duplication between initFromTearOff (lines 48-59), handleTabMergeIn (lines 590-601), and handleTabMergePreview (lines 671-683). All three create a Tab object from TearOffTabData with identical logic. Consider extracting this into a shared helper function like createTabFromTearOffData(tabData: TearOffTabData): Tab to improve maintainability and reduce the risk of inconsistencies.

[Copilot]

The cleanupWindowState function is called after closing the window on line 102, but the cleanup happens after the window is already closed. If the window close event triggers additional IPC calls or operations, those might reference the already-destroyed window with a dangling ID in windowSaveState or windowClosingSet. Consider moving cleanupWindowState(winId) to be registered as a window 'closed' event listener in the window tracking system instead, similar to how it's done in windowManager.ts lines 103-108.

Suggested change

	targetWin.close();
	cleanupWindowState(winId);
	// 如果是最后一个窗口（非 macOS），退出应用
	const remaining = BrowserWindow.getAllWindows().filter((w) => !w.isDestroyed());
	if (remaining.length === 0 && process.platform !== "darwin") {
	app.quit();
	}
	targetWin.once("closed", () => {
	cleanupWindowState(winId);
	// 如果是最后一个窗口（非 macOS），退出应用
	const remaining = BrowserWindow.getAllWindows().filter((w) => !w.isDestroyed());
	if (remaining.length === 0 && process.platform !== "darwin") {
	app.quit();
	}
	});
	targetWin.close();