Resize floating WebView

I really like the Floating WebView action - it's clean, quick and pretty neat.
One thing that I'm not that fond of is the fact that you are forced to give it one specific width and height.
It'd be nice if I could resize the WebView once it's open.
The window snapping features should also work, once the window is resizable.

This would be nice, Ive been thinking there must be a command key to accomplish this. Looking at manual...

It's a bit complicated because to do what it does, the web view uses a custom window, which doesn't contain the resizing logic standard windows have.

I will add an option to enable resizing if draw bezel is activated (because then it uses standard windows, where it's easy to enable resizing). For the floating views without any visible window controls I'm not sure yet whether I can add resizability in any good way - I'll think about this.

image

1 Like

Thank you! Resizing works great. Just started to have another issue with the web view.

Example site: https://tunein.com/cnn/
Used to show content in the window. Even nicely resized to a small player/pause. Now its blank after doing latest update. Might be a coincidence might be a bug.

Should be fixed in 3.256 (currently building & uploading), it seems like the WKWebView behaves differently than the old webview with cached data. (And because I fixed a memory bug in 3.255 this now became visible)

The resizing option now also remembers the window size during the session when caching is not disabled.

//edit: sorry it will take a bit longer, found another small issue

1 Like

Thanks, its working now.

BUG:

When using the "close" red window button on the webview bezel, it closes the window, but content and audio (if audio) is still running in background. Example site: https://tunein.com/cnn

When you try to open the same Webview again from TouchBar button, it doesn't open. Takes 3 touchbar button presses to open that webview again.

  • 1st. press does nothing
  • 2nd. press stops audio (actually closes process I suspect.)
  • 3rd. press opens web view again - finally.

I expected the red close button to CLOSE that process/connection and it does not. Also making it difficult to re-open. If using the Touch Bar button to close it, the window does close and the process is stopped (it actually closes when touching the same touchbar button).

Various related bugfixes and performance improvements in 3.260, could you check whether that covers your use cases? (will be available in 5 minutes)

If you want the content to "go away"/stop when closing the webview you will need to check the "do not cache" option:

FYI: "Do not cache" is allready checked on all my WebViews.

Then it should behave correctly in 3.260 I think :slight_smile:
However if do not cache is active, it will also not remember the window size, because it basically throws away the whole window. Maybe this can be improved in the future or there could be some "on-close-action"

1 Like

Thank you. It does close the process now.

Did you know when you set the Webview to "stick to desktop" the close buttons get grayed out and cannot use them? And you cannot resize when "stick to desktop" is selected.

Is it possible to add a "normal window" option, so it acts like a normal app (behind windows if it looses focus)?

Ah yes, that's a limitation of the stick to desktop.

I can definitely add a normal app option! I kind of want to have a possibility to show a custom dock icon for the webviews, but I'm not yet sure whether that's possible. I'll definitely also add a new trigger type "custom menubar icon" soon.

1 Like

When stick to desktop, the buttons will work until I mouse click on finder (Wallpaper background), but as long as I switch between apps, the button still work. strange behavior.

Still able to click buttons... haven't clicked on finder items

Yeah I mostly tested this without window buttons with widget like webviews. It's pretty much a hack, which is why the macOS windowing system doesn't handle it correctly after selecting Finder. (I think it's because the Desktop is a Finder window, and activating Finder brings that to front, then the desktop icon layer steals the clicks)

Maybe it's better to stick the window one level higher (then desktop icons will be behind it, but that shouldn't be a big issue). => v3.261 :wink:

1 Like

Its a killer feature for many of my tools. Just trying to give all the options to make it most useful in all circumstances. I think "Normal Window" option will complete the "hack" for me. :slight_smile:

1 Like

Getting there... Not a real bug, only for those opening BTT configuration window while Webview's are open. Close BTT Configuration Window and watch all Webviews close (still processing in background) when you re-open any webview, they all re-appear.

I'm aware of that one, but have decided to not fix it for now, because it's hard to solve and I hope not too critical :slight_smile:

I figured as much...

Looking good, "normal window" will solve all other Webview issues I have in the world. :smiley:

I'd say 3.299 alpha (will be online in 5 minutes) completes the resizing feature. I have also added a checkbox to automatically update the position & size settings after a web view has been moved or resized manually.

Additionally you can configure it to behave like a normal window. Therefore activate these:

  • Show window buttons
  • Draw title bar bezel
  • Show BTT Dock Icon while open
  • Z-Index: specify window level manually
  • NSWindowLevel: 0
1 Like

Dragging up an old thread, but it's the closest one to the issue I'm having. Would it be possible to implement resizing programmatically through javascript? Ie. using window.resizeTo(width,height) within the webview? At the moment calling moveTo, moveBy, resizeTo or resizeBy on the window object has no effect - as expected for html windows not opened via the js function window.open(url,windowName,[features]). However I've also tried opening another window from within the webview using window.open in order to test, which also has no effect.

If I set "Resizable (only if bezel is active" within BTT's webview action prefs then obviously I can drag the corners/edges, (which seems to work regardless of whether the bezel is active or not). This also enables me to resize programmatically through applescript (or via the shell using yabai window manager), but in that case the lack of a window title for the webview makes it difficult to ensure I'm acting on the correct window without doing some clunky checks to log the window id. This is time consuming and so detracts from a smooth visual experience.

Ideally I'd like to be able leave BTT's resizable setting off and thus avoid having the edges draggable, but still resize via javascript according to the content I'm showing, eg. performing my resize logic within the BTTInitialize or BTTNotification functions. In the absence of this, a window title for the webview - preferably following BTT's webview action's "Name" property would at least simplify the required calls to applescript or the shell. Any input would be greatly appreciated, thanks.