Under automation read roots, a reply's base64 `thumbnail` (a library
item's PNG in `library.get`, a page's PNG in `document.pdfInfo`) was
searched for hidden library paths like any other text, so a short path
that happened to occur in the encoded bytes was rewritten and the image
broke. `thumbnail` now joins `dataBase64`, `pngBase64` and
`thumbnailBase64` as encoded data that is left unchanged; text under it
that is not base64 is still searched.
Under automation read roots, `ui.inspect` kept a folder preference whose
stored value was readable even when the trimmed path the app uses was
not: ` /outside/fonts` reads as a name in the working folder, while the
app uses `/outside/fonts`. A folder preference now stays only when both
forms are readable. A reply string is decoded for path matching only when
it holds a `%XX` escape, so a string such as `width="100%"` is no longer
decoded and thrown away. The library list line in the progress doc now
states when a hidden library's `loaded/<file name>` id moves.
Under automation read roots, a reply replaced only the path inside a
`file:///outside/a.svg` URL, which left `file://a.svg`, a URL that names a
host. The whole URL of an absolute path, with `localhost`, another host or
no host, is now replaced with the file name, unless part of its scheme was
already replaced. A reply key rewritten to read the same as another key of
its object took that key's place and its field was lost; the rewritten key
now takes ` (2)`, ` (3)` and so on, and a key that is not rewritten keeps
its name.
Under automation read roots, a reply shows each path outside the read roots
that the request sent by its file name. A save or export to a path the
client gave inside the write roots then answered with the bare file name in
`path`, where the save replies keep the given path. The `path` and `files`
entries of the reply's result, a `command.batch` step's result included,
that equal a path param the request gave inside the write roots now stay as
given; every other occurrence is still shown by its file name, and loaded
libraries outside the read roots keep their `loaded/<file name>` ids.
- ui.dock's move takes a hidden panel's shown id in target, as the other
docking destinations do.
- Shortcut overrides keyed panel:<panel id>, saved and in an open
Keyboard Shortcuts dialog, show the panel id shown for a library
outside the read roots, also when nothing else refers to it.
- Outside Windows, a native path is matched only as written: a sent
/out/weird/name.svg no longer renames a hidden library at
/out/weird\name.svg, and a reply does not read one as a spelling of the
other. Windows paths are still matched with either separator.
- Outside Windows a `\` stays part of a hidden library's or sent path's
file name; another platform's absolute path is still split on `\`.
- A hidden relative path is matched after leading `./` and `../` parts
only when they start the path, so `/work/./data/icon.svg` keeps its
text.
- `ui.inspect` and `ui.docking` replies are hidden once, so a library
at the top of the file system shows as `loaded/<file name>` with its
separator.
Outside Windows, a path that starts with a drive (`C:`) or a `\` is read
as a name in the working folder, so with the working folder inside a
read root it passed the read check. ui.inspect then kept it in recorded
action steps and replies did not hide it when a request sent it. The
check now counts such a path as outside the read roots wherever the
control channel and the library commands check a path.
A sent path whose text overlapped part of a hidden library's path could
keep that path from being hidden; the hidden libraries' ids and paths
are now matched first. A hidden relative path is also hidden where a
reply shows the absolute path it reads as from the working folder, and
a hidden library sent by that other form shows as the sent path does.
A library loaded from outside a confined client's read roots keeps its
`loaded/<file name>` id for the session, in ui.inspect, ui.docking and
the library commands, so an id taken from an earlier reply still finds
the same library after another library with the same file name is
loaded. swatch.library.copyToUser leaves out `path` when the file is
outside the read roots, as the saves do.
The ids come from the engine's concealed_library_ids, which now reads a
path written with either separator, counts another platform's absolute
path as outside the roots, and keeps each id in the session.
Outside Windows, a library path that starts with a drive or a backslash counts as outside the read roots, since the file access check would read it as a name in the working folder.
Each hidden id or path is replaced once, chosen from the reply as given,
so a hidden path inside another library's shown id is not replaced
again, and a readable id written with %XX escapes keeps the hidden path
it begins with. A path quoted with {:?} is matched with its quotes and
control characters escaped. A path outside the read roots that the
request sent is shown by its file name in a reply that succeeded as in
one that failed, and a path param counts with a relative path too. A
relative path is not replaced where it ends a longer path. Without a
read root, a file: URL that names another host stays in ui.inspect's
recorded steps.
A hidden id or path stays only where it begins another loaded library's whole id with no `.` or `..` part, also when that id has a space after the hidden part.
- Every request under a read root records the hidden libraries before it
runs, and the reply hides those and the ones hidden after it. A panic
is answered inside the request, so its error is hidden too.
- A hidden path followed by more path text stays only when the longer
text is another loaded library's id with no `.` or `..` part.
- Encoded file data is skipped only for a base64 string under
`dataBase64`, `pngBase64` or `thumbnailBase64`; objects and lists under
those keys, and other keys ending in `Base64`, are searched.
- The error of a failed request hides a path outside the read roots that
the request sent by its file name, so it reads the same whether or not
a library was loaded from that path.
- Paths written with `%XX` escapes are hidden, and on Windows paths in
another letter case.
- Recorded steps in `ui.inspect` leave out `~`, paths under `~` and paths
starting with `./` or `../` outside the read roots under any param.
- Hidden libraries are numbered in load order and keep their id from one
request to the next.
Under the read roots, every control reply now shows a hidden library's
id as loaded/<file name> and its path as the file name in every string
and key: status text, dialogs, the command palette query, a script's
report, recorded steps and errors. The id and path are replaced at any
boundary, so a path between spaces, brackets or quotes, followed by a
period or by more path text (<path>.bak), or quoted with escaped
backslashes is hidden too. An occurrence that continues into a longer
path stays only when the request may read that longer path, so a
readable library's id that begins with a hidden one keeps its text.
The libraries hidden after the request ran are hidden, and for a
request that names one, those hidden before it too. A reply with no
path separator in it is not searched. Encoded file data (dataBase64,
pngBase64) is sent unchanged.
Recorded steps in ui.inspect leave out a path outside the read roots
under path, paths, file, files, folder and any param whose name ends in
Path, Paths, File, Files or Folder (diffPath, fontFiles,
destinationFolder), and an absolute path or file: URL outside the roots
under any other param or in any list. The file: scheme is matched in
any case, a URL's %XX escapes are decoded before the check, a file: URL
inside the roots stays, and a file: URL that
names another host is always left out. file_access::is_path_key holds the list of
path params, and testkit's is_path_key uses it.
Follows #6608. ui.inspect shows a library loaded from outside the read
roots as loaded/<file name>. A request may now name the library or its
panel by that id in a panel, library or panels param, in a docking
destination (anchor, before, onto, above, below) and in
window.panel.layout's action: ui.set {panel} reopens the closed panel
instead of floating a new one. The reply to such a request, an error
included, shows the shown id.
ui.inspect rewrites only whole ids, and only in the fields that hold
library and panel ids, so a readable library's id that begins with a
hidden one keeps its path, and status text, the command palette query
and a script's report keep their text. A hidden library does not take
the id of a library loaded without a path.
ui.inspect also leaves out of recorded action steps the path and folder
params, params named like destinationFolder and the entries of a paths
list that lie outside the read roots, also inside a batch step's
commands. It hides a library id holding a path written with either
separator, and checks a folder preference against the roots as written,
without trimming spaces.
A client confined by --automation-read-root saw paths outside its read
roots that the person or an earlier request had put in the session:
- plugin.list: the plug-in folder last loaded and its failed files;
plugin.list and plugin.info: a plug-in's source file; plugin.list,
plugin.safeMode and plugin.setEnabled: the file of a plug-in turned
off for the next launch.
- file.recovery.list and file.recovery.restore: a document's original
file; file.recovery.list and file.recovery.save: the recovery folder.
- ui.inspect's scriptReport: the files a run wrote and the included
file a failed run stopped in.
A folder outside the read roots is now null, and a file outside them is
named by its file name. plugin.setEnabled {file} takes that name. The
restored documents keep their files, and unconfined clients and the
app's own UI see the same replies as before.
object.objectsOnPath.selectMember and object.objectsOnPath.moveMember
change only the document and its selection, as the other Objects on
Path commands do, so both join the commands a plug-in may call when its
manifest lists them.
A four-component JPEG whose EXIF orientation turns or flips it went
through the image decoder, which reads CMYK JPEGs as RGB, and was
stored as an RGB PNG without its inks. It is now stored the way a
turned CMYK TIFF is: its inks, 8 bits each, turned and written as a
CMYK TIFF with the turned resolution.
- vectorcraft_doc::cmyk::turned_cmyk turns the inks of a CMYK JPEG or
TIFF, next to stored_cmyk_tiff; tiff_inks is private again.
- raster_image swaps the resolution axes inline, as its HEIF branch
does.
- The links comment and the docs/target-app-parity.md line on EXIF
orientation now describe the turned CMYK TIFF.
A text on a path that many <use> elements show was laid out along the
whole path once per <use>, and the path was found in the file and parsed
again each time, while the 1 MiB limit on texts built for <use> elements
counted only the text's nodes and characters. A file with a short text on
a very long path and many <use> elements of it could keep the importer
busy far past that limit.
- The elements of the path a <textPath> follows now count toward the
limit. Past it, the remaining <use> elements show the text with its own
properties, and the warning names text paths as well as text.
- The path of each <textPath> is found and parsed once and shared by
every <use> that shows its text.
Files within the limit import as before.
The Dynamic Text: Block entry says the Contextual Task Bar offers the
item for point type too, and that turning it on makes point type area
type with Block on. The Dynamic Text entry no longer says point type in
the selection is left as it is.
`the_menu_bar_is_inert_while_a_file_dialog_is_open` excused a missing
menu row when the composite font or plug-in it named was gone at the
time of the check. A test running alongside can remove such a font and
define it again between the menu read and the check, and the test then
failed. It now runs inside `undisturbed`, as the file's other tests that
compare menu reads do. When the shortcut, plug-in or font generation
changes during a run, the test runs again on a new app. Every row from
before the dialog must then be back as it was.
The element a <use> shows inherits from the <use> rather than from where it
is defined (SVG 2, https://www.w3.org/TR/SVG2/struct.html#UseElement). A
text shown by a <use> now takes the font, size, weight, fill, stroke and
other text properties the <use> or its parents set, in clip paths too,
while the text's own properties still win. Uses with the same parent and
properties share one text. A <use> inside the text it shows is ignored for
inheritance, and texts built for <use> elements stop at 1 MiB of text with
a warning.
dotCooCoo