The gui-o-matic implementation may reuse either of tabs 2 and 4. (Note the lack of a leading slash in 4.)
Limitations
Taking over the user's browser, such as by reusing a tab, is intrusive. In some cases, reusing a tab might not be acceptable - such as when the tab contains user-entered data which can get lost.
This is to say that for the aforementioned idea, it is useful to be able to specify paths relative to reuse_prefix which may not be reused.
From the now-current version of PROTOCOL.md:
Reusing Tabs
The current version of show_url contains a single attribute, namely the string
url
.We need at least args to specify both
url
, andThe latter aids in the selection of the tab to be reused.
One idea is to restrict the set of tabs, from which a tab may be selected for reuse, by a constraint on the tab's URL, in the form of a prefix.
Example
Assume a web application which is running on https://localhost/foo/ and that a
show_url
is issued with:url="https://localhost/foo/bar/42"
,reuse=true
andreuse_prefix="https://localhost/foo/"
.In the user's default browser, there are three open tabs:
The gui-o-matic implementation may reuse either of tabs 2 and 4. (Note the lack of a leading slash in 4.)
Limitations
Taking over the user's browser, such as by reusing a tab, is intrusive. In some cases, reusing a tab might not be acceptable - such as when the tab contains user-entered data which can get lost. This is to say that for the aforementioned idea, it is useful to be able to specify paths relative to
reuse_prefix
which may not be reused.