Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-main
Author: Anastasia Soboleva <
Link:
Add internal APIs to add bullet list from the AnnotatedString builder
Expand for full commit details
Add internal APIs to add bullet list from the AnnotatedString builder
When we're past API freeze, make this APIs public.
Bug: 299662276, 139326648
Test: AnnotatedStringBuilderTest
Change-Id: I2212987ce813ff55cca3d2a4fa4aeb23dd86ec01
Files:
- M
compose/ui/ui-text/src/androidMain/kotlin/androidx/compose/ui/text/platform/AndroidParagraphHelper.android.kt
- M
compose/ui/ui-text/src/androidMain/kotlin/androidx/compose/ui/text/platform/extensions/SpannableExtensions.android.kt
- M
compose/ui/ui-text/src/androidMain/kotlin/androidx/compose/ui/text/platform/style/BulletSpan.android.kt
- M
compose/ui/ui-text/src/androidUnitTest/kotlin/androidx/compose/ui/text/AnnotatedStringBuilderTest.kt
- M
compose/ui/ui-text/src/commonMain/kotlin/androidx/compose/ui/text/AnnotatedString.kt
- M
compose/ui/ui-text/src/commonMain/kotlin/androidx/compose/ui/text/Bullet.kt
Hash: eb01d1a28091a1c7c7d370a0000d0a077f6c0d0c
Date: Tue Oct 15 19:21:49 2024
ap...@google.com <ap...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-main
Author: Anastasia Soboleva <
Link:
Add ul/li tags support to fromHtml
Expand for full commit details
Add ul/li tags support to fromHtml
Unlike TextView where indentation is added but bullet is always drawn at 0, in this implementation the bullet follows the start of text in the paragraph meaning that it's drawn with the indentation.
Test: new tests and updated demo
Bug: 299662276, 139326648
Relnote: "AnnotatedString.fromHtml now supports <ul>/<li> tags"
Change-Id: I7c2fe1717e72b66da4b2613efbeeb7b6f5ebb44e
Files:
- M
compose/ui/ui-text/samples/src/main/res/values/styled-string-for-sample.xml
- M
compose/ui/ui-text/src/androidInstrumentedTest/kotlin/androidx/compose/ui/text/AnnotatedStringFromHtmlTest.kt
- M
compose/ui/ui-text/src/androidInstrumentedTest/res/values/styled-string-for-test.xml
- M
compose/ui/ui-text/src/androidMain/kotlin/androidx/compose/ui/text/Html.android.kt
- M
compose/ui/ui-text/src/androidMain/kotlin/androidx/compose/ui/text/platform/AndroidParagraphHelper.android.kt
- M
compose/ui/ui-text/src/androidMain/kotlin/androidx/compose/ui/text/platform/extensions/SpannableExtensions.android.kt
- A
compose/ui/ui-text/src/androidMain/kotlin/androidx/compose/ui/text/platform/style/BulletSpan.android.kt
- M
compose/ui/ui-text/src/androidMain/kotlin/androidx/compose/ui/text/platform/style/DrawStyleSpan.android.kt
- M
compose/ui/ui-text/src/androidUnitTest/kotlin/androidx/compose/ui/text/AnnotatedStringBuilderTest.kt
- M
compose/ui/ui-text/src/commonMain/kotlin/androidx/compose/ui/text/AnnotatedString.kt
- A
compose/ui/ui-text/src/commonMain/kotlin/androidx/compose/ui/text/Bullet.kt
Hash: b6d4b40b1a0ffe65c9869ddcde3f133534a10a89
Date: Tue Oct 15 14:30:50 2024
na...@google.com <na...@google.com> #4
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.foundation:foundation:1.8.0-beta01
androidx.compose.foundation:foundation-android:1.8.0-beta01
androidx.compose.foundation:foundation-jvmstubs:1.8.0-beta01
androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-beta01
androidx.compose.ui:ui-android:1.8.0-beta01
androidx.compose.ui:ui-jvmstubs:1.8.0-beta01
androidx.compose.ui:ui-linuxx64stubs:1.8.0-beta01
Description
Some more details in b/388353336
Start of trace:
This happens because when we draw we use a shared ContentDrawScope implementation that we render all DrawModifierNodes in. We do this by mutating a property as we draw successive nodes. However, this means that if anyone captures a reference to this draw scope and tries to draw it later on, this will cause a NPE error as we don't know what the 'current node' that needs to be drawn in.
For the general case this is an error and scopes shouldn't be captured and stored outside the scope in this way, but for GraphicsLayer this is needed when recording drawContent to support some edge cases, such as when we need to draw a layer implementation that can't be drawn in software, within software rendering (such as drawing to a Bitmap). For this we just end up re-invoking the draw block we captured.
We considered some solutions where we would allocate a new draw scope instance per modifier, but this adds some overhead and 'storing' these draw scopes for future use is challenging. (we considered putting them on the node object, in a map on the node coordinator, or some other chain structure on the node coordinator, but none of these are really great)
Instead we can explicitly support the GraphicsLayer.record case by overriding the DrawScope#GraphicsLayer.record function and making it handle this case properly. This can still cause issues if using the non-DrawScope scoped record function, but developers should move to the DrawScope one instead.