Merges 71 commits from main. Headline content: the Tests/Manual
integration test suite revived and reorganized after long disuse
(renames, new applications, updated cibs), restoring a large
integration validation surface. Functional fixes include replacing
unload-based termination with pagehide (back/forward cache
compatibility) and hardening CPTextField's input-element handling.
Conflict resolutions (local versions retained):
- AppKit/CPTextField.j: main's input-element logic carried, with this
branch's preprocessor-removal sweep re-applied on top. Main's
conditionals are re-expressed as runtime CPDOMAvailable guards; the
_inputElement method-definition gate is retained.
- AppKit/Platform/CPPlatform.j: the DOM platform implementation stays
inlined under the PLATFORM(DOM) gate. The split layout breaks the
legacy build: the include fragment is compiled standalone by the
source walk and cannot resolve its superclass. Main's pagehide
termination fix is ported into the inlined section; the restored
AppKit/Platform/DOM/CPPlatform.j fragment is deleted.
Verified: legacy build green through Foundation, AppKit and Tools;
Tests/Manual suite passing.
Cappuccino previously supported three platform contexts behind the
PLATFORM() preprocessor macro: Browser, CommonJS/Node, and a NativeHost
target. NativeHost is no longer supported; this removes it and
consolidates on Browser (for the app) and CommonJS/Node (still needed
by the toolchain itself, for theme compilation and testing).
PLATFORM(DOM) conditionals throughout AppKit governed both distinctions
at once - Browser vs NativeHost, and separately, DOM-dependent code vs
the CommonJS/Node build. Each conditional was reviewed individually:
NativeHost-only branches were removed, while branches needed for
CommonJS/Node were kept intact rather than collapsed to Browser-only.
Also included, found in the course of this work:
- Fixed two pre-existing duplicate instance-variable declarations
(_ephemeralSubviews in CPView, _scrollingTimer in CPTextView)
- Added a missing @import for CPTextContainer.j in CPTextView.j so
it resolves when compiled outside the full framework bundle
- Merged two Platform/DOM/*.j files into their parents to resolve a
build-tool basename collision, preserving the CommonJS fallback path
As part of the ongoing technical debt cleanup, this commit modernizes
CPPlatformPasteboard.j by removing its reliance on the C-preprocessor
and stripping obsolete Internet Explorer compatibility code.
Key changes:
- Inlined the `SUPPRESS_CAPPUCCINO_CUT_FOR_EVENT` and `SUPPRESS_CAPPUCCINO_PASTE_FOR_EVENT`
macros directly to standard property assignments.
- Removed the IE `srcElement` fallback in `hasEditableTarget`.
- Removed the IE `attachEvent`/`detachEvent` branch in `createDOMElements`,
keeping only the standard `addEventListener` path.
- Replaced `var` with `const` and `let` for proper block scoping and immutability.
- Retained the `#if PLATFORM(DOM)` guards to protect the Node.js CI during
the phased modernization effort.
All changes are annotated with `// MODIFICATION:` comments for clear
review tracking.
Method _mayRequireDOMPasteboardElementHack:flags had return type of void, despite returning a BOOL value, and also being annotated with a doc comment stating that it should return a BOOL value
Also some methods had return type "boolean", should possibly be BOOL
Previously when making a paste with a right click caused a crash because the location of the fake event was set to null.
This crash occurs only if the user didn't hit the keyboard yet.
Now, the location of the fake event takes the location of the last event of the app, who is the right click.
When the Edit menu is used to cut or to paste, Cappuccino needs to do all the work of making it happen. But the current code relied on the browser doing part of the work.
This fix adds new state so CPTextField can know if it should expect the browser to do some of the work or not.
Refs #1964.
This change brings nearly all copy and paste related into a single, self-contained class. This new class is still somewhat coupled to CPPlatformWindow+DOM.j in the sense that it's highly specific and meant to be called in a very specialised way. Despite this, it's still a significant decoupling and the new code is more readable and easier to follow.
David Richardson
daboe01
daniel
Alexandre Wilhelm
Alexander Ljungberg