fix: report the web view and CSS failures that were never surfaced - #84
Merged
Conversation
`RichTextError.webViewConfigurationFailed` and `.cssGenerationFailed` are public API, documented in the README, and nothing in the package ever constructed them. Give them the real failure modes they were missing. `webViewConfigurationFailed` now fires on macOS when `drawsBackground` cannot be set. That call reaches WKWebView through KVC on a key that is not public API, and `setValue(_:forKey:)` raises NSUnknownKeyException if the key ever goes away - an Objective-C exception Swift cannot catch, so it would take the host app down. The setter is probed first and the failure is reported instead. `cssGenerationFailed` now fires when `fontColor` or `linkColor` holds an invalid hex value. Nothing rejected those: they reached the stylesheet as `color: #whatever`, the browser dropped the declaration, and the colour silently fell back to the default with no way to trace it. That second hook also puts `ColorSet.isValid` to work, which until now was public API referenced only by its own tests. Its length rule was wrong while it was unused: `#RGB` and `#RGBA` are valid CSS but were reported invalid, and it disagreed with `BackgroundColor.isHexColorLiteral`, which already accepted all four lengths. Both now accept 3, 4, 6 and 8, and the check no longer builds an NSPredicate per call.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
RichTextError.webViewConfigurationFailedand.cssGenerationFailedare public API, are described byerrorDescription, and the README tells callers to handle them - but nothing in the package ever constructed them. The only errors that could actually reach an.onErrorhandler werehtmlLoadingFailedandmediaHandlingFailed.Deleting two cases the documentation actively teaches would break every consumer that switches over
RichTextErrorexhaustively. Giving them the real failure modes they were missing is better.Changes
webViewConfigurationFailednow fires on macOS whendrawsBackgroundcannot be set:That reaches WKWebView through KVC on a key that is not public API.
setValue(_:forKey:)raisesNSUnknownKeyExceptionif the key ever goes away, and that is an Objective-C exception Swift cannot catch, so it would take the host app down. The setter is probed withresponds(to:)first and the failure is reported instead of trapping.cssGenerationFailednow fires whenfontColororlinkColorholds an invalid hex value. Nothing rejected those: they reached the stylesheet ascolor: #whatever, the browser dropped the declaration along with the rest of the rule, and the colour silently fell back to the default with no way to trace it from the outside.ColorSet.isValidwas the natural hook for that check - and it was itself dead, public API referenced only by its own tests. Its length rule was wrong while nobody used it:#RGBand#RGBAare valid CSS but were reported invalidBackgroundColor.isHexColorLiteral, which already accepted all four lengthsBoth now accept 3, 4, 6 and 8, and the check no longer builds an
NSPredicateper call.Compatibility
No public API removed. Existing
.onErrorhandlers keep compiling and simply start receiving two error cases that previously could not occur.Checked for false positives: the four default colours are 6-digit hex, the
UIColor/NSColorinitialisers always produce 6 or 8 digits via.hex, and the sample app uses 6-digit values, so nothing in the default configuration trips the new validation.