Title for Webview

i tried to add title definition to webview html but didnt see an effect

  <title>SWM - Fullscreen Overlay</title>

like i mentioned in here before, im trying to identify is floating view active or not

giving support for title helps webview can easly selected on visible window list

floating windows visible as BetterTouchTool - - 2147483631 currently
i guess it should visible as "BetterTouchTool - SWM - Fullscreen Overlay - 2147483631" with title support
and i can identify is webview active easily with visible_window_list contains "BetterTouchTool - SWM - Fullscreen Overlay" advanced conditions


I was just searching for the same ability. I've discovered through long trial and error that it is technically possible to query for a specific webview window via Applescript with:

property webviewTitle : "whatever your webview's HTML title is"

tell application "System Events" to tell process "BetterTouchTool"
	set wins to (windows whose title is "" and subrole is not "AXSystemFloatingWindow")
	repeat with win in wins
		set found to (first UI element whose description is webviewTitle) of scroll area 1 of group 1 of win
		if (found is not missing value) then return 1
	end repeat
	return 0
end tell

This code runs fine within Script Editor, but unfortunately:

  • Attempting to run via a BTT Run Applescript action locks up the UI (spinning beachball) unless Run in background is selected - in which case it's then useless to use as a condition for other triggers because the result is not awaited.
  • Using a runAppleScript() call from a webview or Run Javascript action it runs ok, but is slooow (at least compared to the speed of checking the visible_window_list var), again rendering it of little use as a condition for other actions/functions.

I attempted to get around the lack of a window title initially by a similar strategy to @yw4z (setting/unsetting a BTT var to denote when a specific webview is visible), but ran into issues when that webview is cancelled via any means that fails to call its BTTWillCloseWindow - because said variable remains set. In the end, I've just had to check for a title-less window on the same level as I've set within the webview's config. But this is fragile, limits options elsewhere, and requires a lot of refactoring across different triggers and js scripts whenever I decide to change the level.

@Andreas_Hegenberg is there any possibility of adding the webview's HTML title as its window name please? Ideally this would also respond to the title being changed during runtime via js, but even just taking the specified title from the HTML would be a huge step up from having to implement these hokey workarounds :pray:.

Floating webviews already have their UUID as title. (You can get it by right-clicking the trigger that opens the webview)

Unfortunately I can't reproduce this expected behaviour - the title of webview windows within BTT's visible_window_list is always just "" :thinking:.

The title property of the UI element I specified via Applescript correctly shows the contents of the HTML title tag that I've set, but there's currently no way to get this information back as a condition (or even via workaround for the reasons described above).

Maybe macOS only returns the window title if the title bar is activated for the window :thinking:

It seems to work ok for the webviews I checked:

Ah I see - my webview has its title bar switched off as I'm trying to create a system(ish) native-looking overlay. Back to the drawing board I suppose :man_facepalming::joy:.

Visible like this in Visible Windows Inspector without UUID
BetterTouchTool - - 2147483631

Titlebar has no UUID even if titlebar activated
Screen Shot 2023-03-06 at 16.00.14

Properties with AppleScript

{{minimum value:missing value, orientation:missing value, position:{923, 509}, class:window, accessibility description:missing value, role description:"system dialog", focused:false, title:"", size:{280, 160}, help:missing value, entire contents:{}, enabled:missing value, maximum value:missing value, role:"AXWindow", value:missing value, subrole:"AXSystemDialog", selected:missing value, name:missing value, description:"system dialog"}}

Attributes with AppleScript

{{false, false, "", {application "System Events"}, {972, 562, 1252, 722}, {972, 562}, missing value, missing value, missing value, {{SectionUniqueID:"AXContent", SectionDescription:"Content"}}, missing value, false, {-1, 1441}, missing value, missing value, missing value, false, {group 1 of window 1 of application process "BetterTouchTool" of application "System Events"}, "AXWindow", application process "BetterTouchTool" of application "System Events", missing value, missing value, false, "AXSystemDialog", missing value, "system dialog", {280, 160}, missing value, "_NS:10"}}

UUID for SWM > SWMFLOAT-5416-4806-A04E-88E117D32D34

But not visible on list


I'll check again, maybe there is something wrong with the code

I think a more performant way would be to set a variable in the lifecycle methods (BTTInitialize and BTTWillCloseWindow), then you could just query that variable and BTT wouldn't need to reload the window list. Doesn't that worK?

The customVariable1-5 can even be used in conditional activation groups.

Yes I've just changed my titlebar options and I'm seeing the same results as @yw4z just described. Thanks for looking into this :+1:.

im setting a variable on launch with SWM-ON > 1
then settting variable to 0 on close

but it leads to a serious bug. if SWM or BTT crashes variable stucks on 1 until next launch of SWM

Its serious because i use it for middleclick and 3 finger tap detection

BTT starts to ask which trigger to use on use these triggers if user assigned more to them

Screen Shot 2023-03-06 at 16.17.32

Did you maybe use set_persistent_string_variable instead of set_string_variable? (the latter will be gone if BTT quits, the first one persists)

You could also initialize/reset the variable when BTT is launching:

Already using set_persistent_string_variable,
SWM uses more than 10 callBTT and more than 10 applescript/shellscripts on launch
i guess this causes to BTT crash, but SWM-OP variable turns 1 before BTT crash
crash ratio is around %1 or %2. but i see daily because i use SWM more than 100 daily

thanks for your suggestion I will add for next release :+1:

I think a more performant way would be to set a variable in the lifecycle methods (BTTInitialize and BTTWillCloseWindow)

I did try this but found that there are some circumstances where BTTWillCloseWindow doesn't seem to be triggered and my variable remains in the state set within BTTInitialize (or BTTNotification). I'm trying to update an existing webview's contents according to the value of a variable set within another trigger, listening for changes using BTTNotification. Or if I call the same trigger again then it should close the webview. I have the logic worked out to do this reliably but I found that when I call the same trigger and close the webview, BTTWillCloseWindow is never called. My Run Javascript trigger is as follows:

(async () => {
  const missioncontrol_active = await callBTT("get_number_variable", { variable_name: "missioncontrol_active" });

  if (missioncontrol_active) {
    runShellScript({ script: `afplay /System/Library/Sounds/Bottle.aiff &` });

  } else {

    // this is my current placeholder condition using window level as described above
    // I've tried to just check against a (non-persistent) variable as you've suggested instead, but it's inconsistent
    const list_visible = !!parseInt(await callBTT("trigger_named", { trigger_name: "webview.detect.dynamicList" }));

    // this is set within BTTInitialise or BTTNotification once the webview contents have been loaded / updated
    const current_config = await callBTT("get_string_variable", { variable_name: "dynamicList.loadedConfig" });

    // this is set within other triggers before calling this trigger
    // it should dynamically refresh the webview contents if it is already onscreen
    // or open the webview and load contents according to the specified value if the webview isn't already visible
    const new_config = await callBTT("get_string_variable", { variable_name: "dynamicList.newConfig" });

    // if dynamicList not on-screen || attempting to load same config
    if (!list_visible || current_config === new_config) {

      // this calls the webview trigger itself, which is set to toggle between displayed / hidden
      // if the webview is already on screen and I attempt to load the same config, BTTWillCloseWebview is never called
      // (my 'dynamicList.loadedConfig' var should also be unset, but remains populated)
      await callBTT("trigger_named", { trigger_name: "webview.toggle.dynamicList" });  // toggle dynamicList webview


If the webview is still active in background it will call the BTTWillHideWindow function instead, so you also might need to change the variable there.

function BTTWillHideWindow() {
callBTT('set_string_variable', {variable_name: 'customVariable1', to: "off"});


@yw4z you should not use the persistent one if you don't want to have the same state after a crash.

Awesome, this is the bit of info I was missing, I should hopefully be able to get it working without querying the windows at all now - thank you :clap:.


im using these in html


but "Preload immediately after BTT launched" option changes SWM-OP variable changes to 1

anyway to skip this

When preloading you should use

function BTTWindowWillBecomeVisible() {


instead of BTTInitialize I think.

looks like fixed, but still using visible window list simpler option it would be great if BTT supports


Yep think I've honed my logic to work correctly now in this instance, thanks for pointing me in the right direction.

But still definitely not seeing any UUIDs as window titles in the visible_window_list, regardless of the title bar settings for individual webviews - that would def be useful in other situations more generally.

Using visible_window_list is quite performance hungry though (BTT needs to ask the system for all windows, then extract their titles and then run a search on the whole list). Thus if you can get the variable to work, it will be much more efficient.