Status Update
Comments
so...@google.com <so...@google.com>
yi...@google.com <yi...@google.com> #2
This is a particularly hard device to come by - do you happen to have access to the device? If so could you provide us with the output of: adb shell dumpsys media.camera > info.txt
Thanks!
am...@twitter.com <am...@twitter.com> #3
Stacktrace:
Caused by: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes(SupportedSurfaceCombination.java:355)
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions(SupportedSurfaceCombination.java:197)
at androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions(Camera2DeviceSurfaceManager.java:198)
at androidx.camera.core.CameraX.calculateSuggestedResolutions(CameraX.java:943)
at androidx.camera.core.CameraX.bindToLifecycle(CameraX.java:293)
at androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle(ProcessCameraProvider.java:227)
Below are some findings based on our debugging
When Dex is connected
previewConfig.getMaxResolution() is returning "731x411" as maxSize.
Inside Preview.Builder.build() -> Default_MAX_resolution is set to "CameraX.getSurfaceManager().getPreviewSize()" which is 731x411
this is being picked as maxSize.
While rendering maxSize is 731x411 and minSize is 640x480 and below are available outputSizes
0 = {Size@11860} "4032x3024"
1 = {Size@11861} "3984x2988"
2 = {Size@11862} "4032x2268"
3 = {Size@11863} "3024x3024"
4 = {Size@11864} "2976x2976"
5 = {Size@11865} "3840x2160"
6 = {Size@11866} "3264x2448"
7 = {Size@11867} "4032x1960"
8 = {Size@11868} "2880x2160"
9 = {Size@11869} "3264x1836"
10 = {Size@11870} "2160x2160"
11 = {Size@11871} "2560x1440"
12 = {Size@11872} "2224x1080"
13 = {Size@11873} "2048x1152"
14 = {Size@11874} "1920x1080"
15 = {Size@11875} "1440x1080"
16 = {Size@11876} "1088x1088"
17 = {Size@11877} "1280x720"
18 = {Size@11878} "1024x768"
19 = {Size@11879} "1056x704"
20 = {Size@11880} "960x720"
21 = {Size@11881} "960x540"
22 = {Size@11882} "720x720"
23 = {Size@11883} "800x450"
24 = {Size@11884} "720x480"
25 = {Size@11885} "640x480"
26 = {Size@11886} "352x288"
27 = {Size@11887} "320x240"
28 = {Size@11888} "256x144"
29 = {Size@11889} "176x144"
and couldn't find any size in this range.
When Dex not connected
minsize = 640x480
maxsize = 1920x1080
0 = {Size@11836} "4032x3024"
1 = {Size@11837} "3984x2988"
2 = {Size@11838} "4032x2268"
3 = {Size@11839} "3024x3024"
4 = {Size@11840} "2976x2976"
5 = {Size@11841} "3840x2160"
6 = {Size@11842} "3264x2448"
7 = {Size@11843} "4032x1960"
8 = {Size@11844} "2880x2160"
9 = {Size@11845} "3264x1836"
10 = {Size@11846} "2160x2160"
11 = {Size@11847} "2560x1440"
12 = {Size@11848} "2224x1080"
13 = {Size@11849} "2048x1152"
14 = {Size@11850} "1920x1080"
15 = {Size@11851} "1440x1080"
16 = {Size@11852} "1088x1088"
17 = {Size@11853} "1280x720"
18 = {Size@11854} "1024x768"
19 = {Size@11855} "1056x704"
20 = {Size@11856} "960x720"
21 = {Size@11857} "960x540"
22 = {Size@11858} "720x720"
23 = {Size@11859} "800x450"
24 = {Size@11860} "720x480"
25 = {Size@11861} "640x480"
26 = {Size@11862} "352x288"
27 = {Size@11863} "320x240"
28 = {Size@11864} "256x144"
29 = {Size@11865} "176x144"
and we have 12 available sizes in this range
Camera2DeviceSurfaceManager.java:: getPreviewSize()
mCameraSupportedSurfaceCombinationMap.get(cameraId).getSurfaceDefinition().getPreviewSize() = "1920x1080"
cameraId=0
so...@google.com <so...@google.com> #4
The issue root cause is that CameraX will default filter out sizes smaller than 640x480. For Preview, the max size will be limited to under display size. I checked the HW spec info for the issue related devices. Display size of FUJITSU F-04J/F-05J is 360x640. That will result int that no size exists in the conditions that is larger or equal to 640x480 and smaller or equal to 360x640.
A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
For device FUJITSU arrowsM04, I checked its HW spec info and its display size I found is 1280x720. It seems that the problem should not exist in the device.
Could you confirm that the problem exist on arrowsM04 device? What will be the returned value when using Display#getRealSize to obtain the display size?
fa...@gmail.com <fa...@gmail.com> #5
> A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
OK. I will try it.
> Could you confirm that the problem exist on arrowsM04 device?
We receive the crash report (Crashlytics) that this crash has occurred on arrowsM04.
We don't have this device so we can't confirm that the problem really exist on arrowsM04.
> What will be the returned value when using Display#getRealSize to obtain the display size?
We can't investigate it for the same reason.
Thank you.
yi...@google.com <yi...@google.com> #6
This issue happened on devices that the display size is smaller than 640x480. In original auto-resolution mechanism, supported sizes smaller than 640x480 will be default filter out.
The auto-resolution mechanism encodes the guaranteed configurations tables in CameraDevice#createCaptureSession(SessionConfiguration). It defines that the PREVIEW size is the small one of the device display size and 1080p. The PREVIEW size will be the maximal size limitation for Preview use case. The reason it limits the size to display size and 1080p is the stream output in display size or 1080p has been able to provide good enough preview quality. Therefore, auto-resolution mechanism will limit the selected size to be smaller than the small one of the device display size and 1080p.
With above two conditions, in this issue, all sizes smaller than 640x480 have been filter out, therefore, there is no size smaller than the display size 320x240 can be selected to use. And cause the exception.
Solution:
When the display size is smaller than 640x480, auto-resolution mechanism won't filter out those small sizes smaller than 640x480. This makes those small size be left and can be selected for the Preview use case on small display devices.
The solution has been merged and will be included in next CameraX release.
fa...@gmail.com <fa...@gmail.com> #7
Hello.
This crash still occurs.
- CAMERAX VERSION: 1.0.0-beta4
- ANDROID OS BUILD NUMBER: Android 7.1.1
- DEVICE NAME: FUJITSU F-02H
We receive following crash report from FUJITSU F-02H. So far We have received this crash report only from F-02H.
java.lang.IllegalArgumentException
Can not get supported output size under supported maximum for the format: 34
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes (SupportedSurfaceCombination.java:349)
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions (SupportedSurfaceCombination.java:197)
androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions (Camera2DeviceSurfaceManager.java:198)
androidx.camera.core.CameraX.calculateSuggestedResolutions (CameraX.java:949)
androidx.camera.core.CameraX.bindToLifecycle (CameraX.java:351)
androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle (ProcessCameraProvider.java:230)
(our application's package name).CameraFragment.bindCameraUseCases (CameraFragment.java:174)
fa...@gmail.com <fa...@gmail.com> #8
Could you help to provide the following information to clarify the issue?
1. Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
2. Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
am...@twitter.com <am...@twitter.com> #9
- Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
Yes
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
Since we don't have this device, we'll try to collect this information in the next version of our app. The next version will be released later this month.
yi...@google.com <yi...@google.com> #10
Hello.
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
We have collected the output of the device where the crash occurs.
Device1
- Model : arrows Be F-05J
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Device2
- Model : Fujitsu arrows M04
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Additional Information
CameraX version : 1.0.0-beta04
We collect the supported output sizes by following code.
val errorString = buildString {
append("The supported output sizes of ImageFormat.PRIVATE: ")
(requireContext().getSystemService(Context.CAMERA_SERVICE) as CameraManager).apply {
cameraIdList.forEachIndexed { index, cameraId ->
val msg = if (VERSION.SDK_INT >= VERSION_CODES.M) {
val configurationMap =
getCameraCharacteristics(cameraId).get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP)
val sizes = configurationMap?.getOutputSizes(ImageFormat.PRIVATE)
"CameraId $index: ${sizes?.joinToString(" ,")}"
} else {
"CameraId $index: This device version is under M."
}
append(msg)
}
}
}
ae...@google.com <ae...@google.com> #11
pw...@google.com <pw...@google.com> #12
I tried to find the device specs and both 720x1280
size display. For the camera id 0 device, it is a different case that the display size is larger than 640x480
but the device only supports a 480x480
size. The case also caused the same IllegalArgumentException and was also fixed by 1.0.0-beta04
release. Before 480x480
size would be filtered out and then caused the IllegalArgumentException. After it was merged, the 640x480
size threshold was removed and then the 480x480
size would be kept and selected to use.
It looks like 1.0.0-beta04
release had been used to collect the supported sizes information. But the issue should have been fixed by 1.0.0-beta04
release. Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
CameraX's 1.0.0-beta04
version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01
version for your application. Thanks.
fa...@gmail.com <fa...@gmail.com> #13
Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
We collect informations only from the device on which IllegalArgumentException happened.
Our latest app uses CameraX version 1.0.0-beta10
and this issue still occurres.
However we don't receive crash report from Fujitsu arrows Be F-05J
or Fujitsu arrows M04
so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)
Instead, we receive crash report from
- Model : Fujitsu F-03K
- Android Version : 7.1.2
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
yi...@google.com <yi...@google.com> #14
I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.
yi...@google.com <yi...@google.com> #15
Branch: androidx-main
commit 69d15dff7bb857ee33a0f643ff42a0f8bc475ab2
Author: charcoalchen <charcoalchen@google.com>
Date: Fri Jan 08 18:30:03 2021
Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Do not filter out sizes smaller than 640x480 when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Relnote:"Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480."
Bug: 150506192
Test: SupportedSurfaceCombinationTest
Change-Id: I2a63ce8e2ad42a9cc060c8635ac3603bf440b1ec
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/SupportedSurfaceCombination.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java
he...@ataulm.com <he...@ataulm.com> #16
cb...@google.com <cb...@google.com> #17
Headings allow this somewhat, but only if there are no headings in the list.
Panes also allow jumping out of the list, with more flexibility, now that we have next-window actions.
The best option seems to be generalized containers with enter/exit actions & gestures.
> components like FABs and other app chrome like appbars by being able to mark them as chrome,
I like this idea, because it provides high-level information that gives talkback flexibility to apply various navigation policies. But it does not necessarily solve the infinite-list problems since chrome may not exist before/after the list.
> order by sortPriority then by ordering left-to-right, top-to-bottom.
This sounds functionally equivalent to traverse-before/after, though somewhat easier to use.
pb...@google.com <pb...@google.com> #18
Hey, so we are working on App Widgets, and one of the layout we are working with is this:
There are five locations for buttons, and iterating through them should probably be from more important to less important, meaning the center first, and then around in a circle, starting probably from top-left, although this might depend on whether the UI is LTR or RTL and on the exact application.
yi...@google.com <yi...@google.com>
pw...@google.com <pw...@google.com> #19
fa...@gmail.com <fa...@gmail.com> #20
Being able to influence the reading order by importance is really useful to offer a good user experience to blind user.
ro...@gmail.com <ro...@gmail.com> #21
lo...@gmail.com <lo...@gmail.com> #22
Blocked by a private issue 😪
da...@omadahealth.com <da...@omadahealth.com> #23
Building rich experience for vision impaired users aren't easy, but I think we should embrace that fact and give more tools and education for the devs, so when we are building complex things, we have all the tools in our disposal.
al...@dayforce.com <al...@dayforce.com> #24
Agree with #23. It would be ideal to have the tools and implement them on a case-by-case for some of our more complex components. I don't believe anyone wants to make inconsistent behaviour for end-users but getting to that consistent behaviour should be available to us if the default implementation can't reach it in this case. It's problematic for us when our expected traversal order in design (which may be set by accessibility analysts) doesn't meet our actual implementation and sometimes the design/implementation refactor costs are high.
While not on compose, there's been issues in the past with traversal where even with refactors we couldn't get an expected result leading to difficult decisions, which is not ideal for end-users.
Let us take responsibility for meeting the compliance, consistency, and accessibility of our own implementation.
ae...@google.com <ae...@google.com> #25
Thanks for the feedback. What I would find helpful to make progress here is to hear the concrete cases you're running into where the default order deviates from the one your a11y analysts recommend. Feel free to file those as separate bugs under the following component:
Then, case by case, we could: 1) suggest a technical workaround to make the order conform without redesigning your app, 2) fix our implementation so that the default order conforms to what you want, or 3) acknowledge that it is technically impossible right now and block those bugs on this feature request. If we wind up accumulating a critical mass of case 3), that would justify putting this on our roadmap, as well as making sure that it supports all the motivating use cases.
al...@gmail.com <al...@gmail.com> #26
Here is an example:
I have a list item (see screenshot) where there is Text, Detail Text, and Meta text. I want these to be announced in that same order.
However, talkback announces the order by default like "Text, Meta text, Detail text".
I believe this is because my layout is like this:
Column {
Row {
Text()
MetaText()
}
DetailText()
}
So I think the only way I could workaround this is by creating a custom layout that places the composables in the same order that they should be read out loud in talkback. But this isn't very convenient.
pw...@google.com <pw...@google.com>
va...@google.com <va...@google.com> #27
Another use case:
In short, there is a topBar
in a Scaffold
that is being placed in the same location as the content
slot (and the content is given the space that the top bar occupies as padding values via subcomposition)
Since topBar
and content
are placed at the same location, the logic in SemanticsSort
eventually choose the content
first, since it is a taller element:
That is unexpected, however, since the topBar
will visually be the top-most element. There doesn't appear to be any way currently to affect this ordering, other than by changing where the topBar
and content
are placed.
The same issue is also currently affecting the M3 Scaffold
for the same reason.
ae...@google.com <ae...@google.com> #28
Indeed, so far, more than half the focus-traversal problem cases I've heard involve a top bar. We'll see what we can do to improve that particular use case.
ap...@google.com <ap...@google.com> #29
Branch: androidx-main
commit 58ef0380e0f989b7532babbff23bcef0d3ba64b6
Author: Melba Nuzen <mnuzen@google.com>
Date: Thu Oct 27 16:35:09 2022
Internal change from using SemanticsSort to 'setTraversal'
This change is meant to be pre-work for a larger refactoring of focus order in Compose and shouldn’t introduce any changes in A11y behavior.
Issues seen in
This patch is just meant to check that we can use `setTraversalBefore` to determine our own custom order for semantics nodes (overriding the existing hierarchies). `setTraversalValues` in `AndroidComposeViewAccessibilityDelegateCompat` should order semantics nodes in the same way `SemanticsSort` did, except by setting the `traversalBefore` value for each node that will be read by TalkBack.
This ordering is set in a mapping when semantic nodes are first retrieved. Then when a nodeInfo is created, the code now looks up our custom traversal order and uses `setTraversalBefore` on that ANI. That way, when TalkBack goes through the ANI tree, it’ll use the `traversalBefore` parameter and traverse in the way that we want regardless, of parent/child hierarchies.
Bug: 186443263
Test: compose/ui/AndroidAccessibilityTest/testCreateAccessibilityNodeInfo_forTraversalOrder
Change-Id: I339010bea62afb359e63d6e63889acff2c72cf27
M compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/UiDemos.kt
A compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/accessibility/ComplexAccessibility.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/AndroidAccessibilityTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeViewAccessibilityDelegateCompat.android.kt
b....@gmail.com <b....@gmail.com> #30
Here is another example where we think it would be nice to have an API to specify the custom accessibility focus order. Have a look at LazyRow
of tabs and a HorizontalPager
. When used with TalkBack, the user has to scroll through all the pages back to the first element of the first page to finally jump out of the Pager
and to return to the tabs. The tabs are there to quicken the navigation (the user selects a tab, then the Pager
goes straight to its content). So we think it would be nice to allow the user to exit from the current page in the middle of the Pager
straight to the active tab - not to the previous page. Maybe, it would also be helpful to automatically focus the page right after the user selects a tab, so it is not required to scroll through all the rest tabs in LazyRow
to reach the now-active page.
jo...@gmail.com <jo...@gmail.com> #31
Hello, anybody can show a use case of:
modifier = modifier
.semantics {
requestFocus(label = "label", action = {
anyAction()
true
} ...
For handle talkback focus
Or:
modifier = modifier
.semantics {
focused = false
...
to lost a focus and recovery again.
Thanks!
ap...@google.com <ap...@google.com> #32
Branch: androidx-main
commit c8984d286586fa208df859b6a6f906364db47823
Author: Melba Nuzen <mnuzen@google.com>
Date: Wed Mar 15 11:24:57 2023
Only sort speaking nodes and implement traversal index API
Test: AndroidAccessibilityTest.testSortedAccessibilityNodeInfo_traversalIndex() and others
Bug: 186443263
Relnote: "New semantics property traversalIndex, a float used to reorder nodes in TalkBack traversal (lower values come before)."
The first change in this CL switches the semantics sorting logic so that only `structurallySignificant` or `screenReaderFocusable` nodes are considered in the sorting algorithm. `structurallySignificant` is only true if the node is a container/traversalGroup, or is a scrollable, or has collectionInfo. `screenReaderFocusable` is true when a node will be traversed by TalkBack.
The second change in this CL adds in a `traversalIndex` API that can be used to customize TalkBack traversal order. When the `traversalIndex` semantics property is set on a container/traversalGroup or on a screenreader-focusable node, then the sorting algorithm will prioritize nodes with smaller `traversalIndices` first.
The default traversalIndex value is zero. If a screenreader-focusable node is inside a `traversalGroup`, then it’ll inherit placement of the `traversalGroup`, but inside the `traversalGroup` itself, still have default value of 0. This way, developers can use `traversalIndex` on a group to change the ordering of the group (relative to its peers) as a whole, but still be able to customize the traversal order of the children of that `traversalGroup`.
See go/traversal-index-changes for more details.
Change-Id: I9a81b4acf33c355c1142e28e6fd94788f7937cec
M compose/ui/ui/api/current.txt
M compose/ui/ui/api/public_plus_experimental_current.txt
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/integration-tests/ui-demos/src/main/java/androidx/compose/ui/demos/accessibility/ComplexAccessibility.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/AndroidAccessibilityTest.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/semantics/SemanticsTests.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeViewAccessibilityDelegateCompat.android.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/semantics/SemanticsProperties.kt
lu...@livefront.com <lu...@livefront.com> #33
Any news on when this fix will actually hit a release? The changes look beautiful!
ae...@google.com <ae...@google.com> #34
The new traversalIndex
/traversalGroup
SemanticsProperties will first be released in 1.5.0-beta01, scheduled for mid-next-week. We think it should be a flexible tool to improve a11y focus order for many of the known use cases, I hope it solves your problem!
If it doesn't behave as you expect, please post a video along with sample code, and we'll investigate. Also, please note that there are still known issues with TalkBack initial focus after navigation which traversalIndex
is not yet able to solve (see
lu...@livefront.com <lu...@livefront.com> #35
Greatly appreciated. My use case will definitely put it to the test!
lu...@livefront.com <lu...@livefront.com> #36
Thank you so much for the travesalIndex
/traversalGroup
release! It has mostly worked as expected. The one issue I am seeing is when the parent has semantics(mergeDescendants = true) {}
. I made an example:
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
TraveralTestTheme {
TraversalExample(
modifier = Modifier
.semantics(mergeDescendants = true) { }
.background(color = Color.Gray)
.fillMaxSize()
)
}
}
}
}
@Composable
fun TraversalExample(
modifier: Modifier = Modifier,
) {
Row(
horizontalArrangement = Arrangement.Center,
verticalAlignment = Alignment.CenterVertically,
modifier = modifier.semantics { isTraversalGroup = true },
){
Column {
Text(
text = "I should be announced first",
modifier = Modifier
.padding(16.dp)
.semantics { traversalIndex = 1f },
)
Text(
text = "I should be announced third",
modifier = Modifier
.padding(16.dp)
.semantics { traversalIndex = 3f },
)
}
Text(
text = "I should be announced second",
modifier = Modifier
.padding(16.dp)
.semantics { traversalIndex = 2f },
)
}
}
The announcement order is: 1,3,2.
The announced string is: "I should be announced first, I should be announced third, I should be announced second"
ae...@google.com <ae...@google.com> #37
Got it. traversalIndex
's current implementation only control the order that TalkBack moves its focus box around: we hadn't yet considered the use case of controlling the announcement order within a single merged element. Feel free to file a separate bug on that.
For now, clearAndSetSemantics { contentDescription = "I should be announced first, I should be announced second, I should be announced third" }
could be an alternate way of solving this, although I recognize clearAndSetSemantics
has downsides and it's usually better to avoid it.
lu...@livefront.com <lu...@livefront.com> #38
OK. I will do that! Thank you very much. I have noticed other interesting behavior but haven't been as successful in reproducing it. We think some of the behavior is related to this:
Also remove the idea of 'structurally significant' to only talk about
traversalGroups
by addingisTraversalGroup = true
to Foundation classes (Modifier.scroll semantics and LazyLayoutSemantics). This way, all scrollables are consideredtraversalGroups
in preparation of aosp/2491418 and go/traversal-index-changes.
as we have solved some of our issues by using Modifier.semantics { isTraversalGroup = false }
with scrollable components. The basic description of the issue "the scrollable item seems to be moved deeper into the traversal tree than its peers as it is skipped until the next layer is announced. However, it is properly announced if isTraversalGroup
is set to false
".
ae...@google.com <ae...@google.com> #39
OK, that sounds like another thing worth filing a separate bug for. We can use your example either to improve our default behavior, or to provide guidance on when to specify isTraversalGroup = false
. Please include two videos of what you are seeing (with isTraversalGroup = false
on the scrollable, and without).
lu...@livefront.com <lu...@livefront.com> #40
Of course. Thank you!
lu...@livefront.com <lu...@livefront.com> #41
I made the issue for that first bug!
eg...@gmail.com <eg...@gmail.com> #42
Thanks for this long waiting feature. During integration we faced runtime crash when we switch compose screens: java.lang.IllegalStateException: LayoutNode should be attached to an owner
Similar issue:
ae...@google.com <ae...@google.com> #43
Marking this bug fixed because the new traversalIndex
traversalGroup
If anyone still can't find a way to solve their use case after experimenting with them, please file a new bug and post a video along with sample code.
Description
It would be really useful to be able to change focus order as we were able to do it before with accessibilityTraversalAfter accessibilityTraversalBefore.
This feature is a must have, specifically when designing a view on the Z axe to actually specify to talkback in which order to read element.
Moreover, it is also necessary when using a FAB button, if the element behind is an infinite list, we should be able to set the focus to the FAB Button first otherwise the user experience for a blind person is really poor.
Thanks for you work on Jetpack Compose, and keep going !