TiddlyTools in-wiki Browser is super-useful

Great! The small range 0.5,1 I confirm is now “fat-finger compatible.”

And thanks for the explanation of the ranges and the example!

TT

Hi @EricShulman

Love the ability to be able to choose zoom settings for the browser window. Sometimes it would be super useful to be able to set the zoom in a numeric box rather than by slider. I find 1.5X to be be perfect for one of the sites I am viewing.

Also my browser does not have the settings or help buttons. Can you say why?

Cheers, Rob

Settings and Help are optional extra add-ons:

For Settings, install TiddlyTools/Panels/Settings
For Help, install TiddlyTools/Panels/Help and TiddlyTools/Panels/Browser/Help

-e

Comment: Now we are Cooking By Gas !!

The miniBrowser is a solution to many issues.

I’ll give one example … Searching the internet from the TW Sidebar …

The tool has …

  • Easy Bookmarking
  • Bookmark Filters
  • Bookmark Folder Assignment to individual miniBrowsers — allowing independent hierarchies of Bookmarks
  • Ability to Auto-Open external Tabs/Windows for non-iframe-ables
  • Record of each miniBrowser’s last site
  • Configurable Zoom ranges in each miniBrowser

I can’t thank @EricShulman enough!
TT

1 Like

The most recent TiddlyTools Browser update (earlier today) no longer uses indexes in $:/config/TiddlyTools/Browser to store the current name and URL for each browser. Instead, it uses separate “qualified” temp tiddlers ($:/temp/TiddlyTools/Browser-1234543...). This was done to make the browser’s “state” information separate from the “config” settings, as well as making the code cleaner and more consistent.

Note that, while these temp tiddlers persist during the current session, they are not usually saved in the file. If you want these temp tiddlers to be saved, you can define a tiddler tagged with $:/tags/Global, containing a macro named publishFilter():

\define publishFilter() [prefix[$:/temp/TiddlyTools/Browser]]

-e

I think I do. They are kinda “where I am settings” worth persisting.

Thanks for the info.

TT

I’ve found a “limitation” when using a named minibrowser with an <a href=...> link.

Suppose you have a tiddler containing:

<$let name="somename">{{TiddlyTools/Panels/Browser}}</$let>

Then, in some other tiddler content, you write:

<a href="https://example.com" target="somename">click me</a>

with the intention of having that “click me” link shown in the aforementioned “somename” minibrowser.

The problem is that this only works if the “somename” minibrowser is already showing a rendered iframe. If it is showing “click to start” or “enter a url or select a bookmark”, then there is no actual iframe for the targeted link, and it will open in a separate tab instead.

-e

Eric, I just had a quick look in passing, and visited TiddlyTools for TW v5.3.8 — Small Tools for Big Ideas!™ just as a test I went to tiddlywiki.com and my knee jerk reactions was to apply one of my JavaScript bookmarklets, only to discover, as one may expect, they only apply to the parent wiki.

Dont go out of your way to resolve this but I just though I would ask if there is any opportunity to permit such bookmarklets to target the iframe window?

  • I was able to place the bookmarklet in a tiddler and drop it into the iframe and run it.

Update: I’ve added handling so a minibrowser IFRAME can be initially rendered by setting enable=yes and any non-blank default URL):

<$let name=somename enable=yes url=" ">
{{TiddlyTools/Panels/Browser}}

This allows you to successfully use <a href=...> syntax to target a specific named minibrowser:

<a href="https://example.com" target=somename>click me</a>

-e

Eric, I added a bookmark inside the mini-browser and provided a bookmarklet in stead of a url, ie a javascript payload and as may be expected it failed. I wonder if there is a way to accommodate these?

You can try this experiment:

In TiddlyTools/Panels/Browser setURL(), this line:

<$let url={{{ [<url>!regexp[^(http|\./|\.\./|file:)]addprefix[https://]] ~[<url>] }}}>

detects URLs that start with “http”, “./”, “../” or “file:”. If none of those patterns are found, then it assumes that there is a missing protocol prefix, and automatically adds "https:// to the URL.

I assume that your bookmarklets syntax starts with “javascript:”. Try changing the above line to:

<$let url={{{ [<url>!regexp[^(http|\./|\.\./|file:|javascript:)]addprefix[https://]] ~[<url>] }}}>

this should allow the IFRAME src param to be set to your bookmarklet code.

Let me know what happens…

-e

1 Like

This is just a comment.

Thanks for that info!

Actually my issue has gone away with your latest additions …

Now I can precisely set the start url and it always displays as I want!

I’ll comment more later.

Best
TT