Chrome Android版FileSystemDirectoryHandle.resolve方法返回路径组件异常问题咨询
Chrome Android版FileSystemDirectoryHandle.resolve方法返回路径组件异常问题咨询
大家好,我最近在测试Chrome 132新引入的文件系统访问API里的目录选择器功能时,发现了一个跨平台的行为差异,想请教下这是设计预期还是首版的bug:
在桌面版Chrome中,目录条目(FileSystemDirectoryHandle)的resolve方法会返回一个Promise,解析后是包含路径组件的数组,能清晰体现文件/目录的层级结构。但在Android版Chrome上,不管目录嵌套层级有多深,这个方法返回的始终是只有两个组件的路径:第一个是document,第二个是一串编码后的字符串,里面用%2F分隔各个目录段,前缀类似primary%3ADocuments%2F这类格式。
举个实际测试的对比例子:
- 桌面Chrome环境下,选择名为
xslt-1.0的目录后,显示的路径是层级化的:- xslt-1.0
- sub-folder1 (sub-folder1)
- module-test2.xsl (sub-folder1/module-test2.xsl)
- module-test1.xsl (module-test1.xsl)
- sub-folder1 (sub-folder1)
- xslt-1.0
- 而在Android Chrome环境下,显示的却是扁平的编码路径:
- xslt-1.0
- sub-folder1 (document/primary%3ADocuments%2Fxslt-1.0%2Fsub-folder1)
- module-test2.xsl (document/primary%3ADocuments%2Fxslt-1.0%2Fsub-folder1%2Fmodule-test2.xsl)
- module-test1.xsl (document/primary%3ADocuments%2Fxslt-1.0%2Fmodule-test1.xsl)
- sub-folder1 (document/primary%3ADocuments%2Fxslt-1.0%2Fsub-folder1)
- xslt-1.0
我写了一段测试代码来复现这个问题(注:代码在iframe环境下执行时,目录选择器功能无法正常运行,仅展示逻辑):
测试代码
JavaScript 部分
async function buildRootDirList(dirHandle) { const ul = document.createElement('ul'); document.body.appendChild(ul); const li = document.createElement('li'); ul.appendChild(li); li.appendChild(document.createTextNode(dirHandle.name)); await buildDirList(dirHandle, dirHandle, li); } async function buildDirList(dirHandle, rootDirHandle, parentElement) { const ul = document.createElement('ul'); parentElement.appendChild(ul); for await (const entry of dirHandle.values()) { const li = document.createElement('li'); ul.appendChild(li); li.appendChild(document.createTextNode(`${entry.name} (${(await rootDirHandle.resolve(entry)).join('/')})`)); if (entry.kind === 'directory') { await buildDirList(entry, rootDirHandle, li); } } } document.getElementById('dp1').addEventListener('click', async () => { const dirHandle = await window.showDirectoryPicker(); await buildRootDirList(dirHandle); });
HTML 部分
<input type=button id=dp1 value=test>
想问问大家,这种桌面和Android版resolve方法的行为差异是有意设计的,还是Chrome 132首版引入这个API时的bug呢?
备注:内容来源于stack exchange,提问作者Martin Honnen
相关产品推荐
相关产品推荐

