Repository navigation
Conversation #9
Description
Hey @NSTechBytes @Yincognyto, I open this issue only to have a public place where to have a conversation about new features and share testing builds. This is to have it public but private enough to avoid sharing the test builds directly on the forums where is more broadly public, I don't like the idea of having bugged/non working versions publicly available on the forums.. Also to avoid creating pull requests with many changes.
Current test package here: #9 (comment)
Activity
RicardoTM05 commentedon Dec 15, 2025
For now, I have working:
--End of PR--
I'm working on:
RicardoTM05 commentedon Dec 15, 2025
So as commented above, here's a testing build:
Will be deleted at some point
[Deleted]
New options:
AllowNewWindow[Default 0]By default it will block any website from opening links in a new window, unfortunately, it also avoids the user from manually opening things on new windows by right click - Open in new window, there's no way around this I could find. Set to 1 if you want windows.
AllowNotifications[Default 0]WebView doesn't allow to use the Notifications API by default, now we can use it by setting this option to
1.New commands:
StopThis new command will stop any navigation. To test, open DevTools - Network tab - change No throttling to 3G to purposely slow down your connection. Then use the command while the site is loading to stop it.
Fixes
AllowDualControlscript should now work fine whenZoomFactoris not1.0AllowNewWindowvalue.Testing skins:
BangCommand.ini
Permissions.ini
Permissions.zip
Extract the zip inside the WebView skin folder. Refresh Rainmeter and load Permissions.ini to test all available permissions. To allow notifications set
AllowNotifications=1You can also use this website to test the Notifications API: https://web-push-book.gauntface.com/demos/notification-examples/
RicardoTM05 commentedon Dec 16, 2025
Alright, in addition to the above, I have finished the two experimental reworks I wanted to propose.
Measure's String and Number value returns rework
Instead of allowing the user to return custom delayed values through window.OnInitialize and OnUpdate JavaScript functions, I propose a new system that returns the following:
Number Value
The Measure's number value would express the current state of the plugin with the following values:
-1This is the initial value.
0It starts its configuration
1It is fully initialized and ready
100Navigation has started
200The site has started loading
300The site has finished loading, navigation is complete.
String Value
The string value would simply be the current URL.
Current URLHowever, this system is not complete without new actions:
Actions
OnStateChangeActionThis action would trigger every time the state changes
OnUrlChangeActionThis action would trigger every time the URL changes
These actions will allow us to set variables, update meters, and so on to keep the skin updated to the latest measure values.
--
Navigation to URL system rework
There's currently an issue with the current way we navigate by setting the
URLoption. We can only navigate if the URL changes, otherwise the button is simply blocked, this leads to confusion while trying to navigate. We can't fix it because otherwise we create a navigation loop on each update when DynamicVariables are enabled. So I propose to change the system:Now the Measure's URL option will be a home page URL. This is the URL where the plugin will navigate on first load, then we only navigate using the Navigate command. However, we need a new command as well:
Commands
GoHomeWe navigate to the set URL on the measure by using
[!CommandMeasure Measure "GoHome"]The URL option remains the same, only that by changing it we simply change the home page URL, we then navigate to it using the
GoHomecommand.I believe this system is more consistent by only using commands to navigate, and variables to set options.
With all that being said, here's the testing build, it of course includes all changes on the comment above.
[Deleted]
And a modified version of
BangCommand.iniBangCommand.ini
Please test and let me know what you guys think.
NSTechBytes commentedon Dec 16, 2025
Sure, I will test it as soon as I come back from work.
Yincognyto commentedon Dec 16, 2025
While you're at it, can you also please share if you can drag the skin from a Youtube video area in various plugin versions (i.e. your 0.0.7 one, and the version posted by Ricardo above - see if they both work or not)? Me and Ricardo have been talking a bit on this topic and what happens is that for him none of the versions can do that, while for me yours works without issues while his need a page reload or coming from Google instead of say Bing when navigating to Youtube. We're not sure what causes it since so far it only happens on YT and my downgraded runtime is the only one able to workaround this or have no issues (if the issue is the runtime version, that is - personally, I have serious doubts on that).
NSTechBytes commentedon Dec 16, 2025
I’m unable to drag skin on the YouTube site in both versions.By pressing CTRL key.
Yincognyto commentedon Dec 16, 2025
Thanks! That's interesting indeed - looks like I'm the only one able to do so in both versions, for whatever reason...
NSTechBytes commentedon Dec 16, 2025
Opening the skin context menu with Ctrl + RMB is also not working in the Yt.
NSTechBytes commentedon Dec 16, 2025
I think the best approach for AllowDualControl is to detect the Ctrl key press using keyboard hooks and then forward the click-through to the WebView window.
Yincognyto commentedon Dec 16, 2025
Yes, those two are more or less related (i.e. usually solving one will solve the other).
You mean doing that internally without any Javascript - a combination of your Clickthrough option principle, only triggered by pressing the CTRL key? If so, Ricardo was saying roughly the same thing, but he worded it differently and I was worried that we'd make the plugin a soup of unrelated things to WebView itself. However, If it's possible to do so without any injected script and it doesn't have side effects (like, I don't know, disable any browser / page features potentially relying on pressing the CTRL key; extensive testing would help here), then I'm all for it - forwarding it to the skin window itself, if possible, could be a possibility too. That would require infallible identification of the said the window (even if multiple in the same skin, or even having the same coordinates and dimensions there), but if feasible it would save the need to update the plugin to "fix" any issues with it appearing later on, and still allow for custom dual control via ExecuteScript if desired.
Side note, Ricardo suggested that I should try upgrading my downgraded Edge / WebView2 versions. I'm open to it mostly out of curiosity, and made plans for reverting it in case it goes sideways, but first I'd like to ask you if you think it's a good idea. What I mean by this is that as of now it seems I'm the only one able to check the backward compatibility of the plugin (with all the advantages / disadvantages of it, see the earlier report related to YT drag working on my side in both versions of the plugin), thus when I upgrade, that possibility and the reports from such a system (which could be helpful for the plugin itself) could be missing. What's your stance on this, as the main developer?
NSTechBytes commentedon Dec 16, 2025
I would like this plugin to work with all WebView runtime versions, so I believe Ricardo should adopt the functionality I mentioned.
Yincognyto commentedon Dec 16, 2025
Same here - let's see how your and Ricardo's ideas fit together, since, as I said, he thought about a similar thing as you did (in principle, not sure about the technical details of it).
RicardoTM05 commentedon Dec 16, 2025
I was telling Ying that we could use both a keyboard and mouse hook for AllowDualControl instead of pure JS, may be more reliable. I haven’t planned on how to implement it yet though. However only if we don’t find a fix for the current implementation, I’m doing other things.
About the WebView sdk version, my plan is to upgrade it to the newest version so I can use all available methods possible for user settings. And once everything’s done downgrade it to the lowest version possible that contains all methods being used.
Any comments on the test build I shared btw?
Yincognyto commentedon Dec 16, 2025
Everything I tried seems to work nicely. I only briefly tested the permissions skin, but it works as well - I like it. For now, the GoHome command bang doesn't seem to be such a bad idea, I like it too - but yeah, I didn't go into more complex scenarios to notice any potential shortcommings. Overall, I'm quite pleased with the test build from a user perspective. I only had one surprise when trying to enter an incomplete URL and nothing happened, but that's no problem - the user can regex and substitute stuff himself if he wants some kind of autocompletion, e.g. "rainmeter.net" to "https://rainmeter.net", I don't think we (well, you, to be fair) should bother with that, let them customize that to their liking instead of doing everything for them in that regard.
RicardoTM05 commentedon Dec 16, 2025
About that, the URL option does check for valid URLs, this was already done by nstechbytes and remains untouched.
Basically, it first checks if the URL has a valid protocol (http://,https://,file://, etc). If it has a valid protocol then it passes it normally.
If it has no protocol then it is treated as a relative path, so it converts it to an absolute path and adds
file:///.So, if
URL=googleit will be translated tofile:///C:/Users/User/Documents/Rainmeter/WebView2/BangCommand/googleYou can actually enter:
URL=#@#Calendar/Index.htmland it will automatically addfile:///to it as well.This only applies to the URL option though, not to the navigate commands. When you enter an empty string to the navigate command it simply doesn't navigate. If you enter a string without a valid protocol nothing will happen either (this is normal Navigate command behavior). So yeah, they can simply create their own logic to handle URLs for navigation.
8 remaining items
Yincognyto commentedon Dec 18, 2025
Oh ok, so this was added because the
Disabledoption couldn't fully "disable" WebView for when you'd need it - all clear now for me, I'm ok with having it, but maybe it should be implemented / worded / explained in simpler terms once and if it gets to a release version, otherwise we'd have questions on that from the users.RicardoTM05 commentedon Dec 20, 2025
Alright, this new build introduces fixes to inject RainmeterAPI to top-level iframes, and a new action and 2 states.
States
-2When WebView fails for whatever reason, this will be the number returned by the measure.
300This state number was previously for Navigation Complete.
400Navigation complete is now
400Actions
OnDOMContentLoadActionThis action will trigger when the DOM content finishes loading, it triggers before
OnPageLoadFinishAction.Other Changes
ExecuteScriptcommand will now also inject to top-level frames.Notes
http-serveris required to frame websites due tofile://scheme lacking the ability to send HTTP-Headers, this is well, because HTTP is a different protocol than file, which is not a network scheme.ExecuteScriptwill inject the same script to the main document and all top-level frames found. A newExecuteScriptOnFramescommand could be implemented to let the user choose, but not completely necessary as the user can design their script to only be injected if the current document is not part of an iframe, or the other way around. Let me know what are your thoughts about this.Testing
Here's the new testing build.
[Deleted]
Click on
Execute Scriptbutton onBangCommand.inito inject text to all available documents.BangCommand.ini
Here's an image of how framing two websites on a single page looks like:
RicardoTM05 commentedon Dec 20, 2025
I think I’ve added enough features to start a pull request. What you guys think? I can start committing tomorrow for you to check the code while @Yincognyto adjusts AllowDualControl’s script to account for iframes positions.
I can continue afterwards. I want to start playing with general user settings and environment options, but I think it would be better for another update after this one.
By the way, I will also enable put_allowhostinginputprocessing, well, I already did actually lol, I believe that option will let the plugin read mouse and keyboard input before reaching WebView, allowing us to implement AllowDualControl.
NSTechBytes commentedon Dec 20, 2025
RicardoTM, have you tried setting up a keyboard hook at the plugin level?
RicardoTM05 commentedon Dec 20, 2025
I did and failed, but that was before enabling the feature I mentioned. Maybe with that enabled the hooks will work. Will have to try.
RicardoTM05 commentedon Dec 20, 2025
Mmm, I'm still not sure how to get it to work. I'm using a low level hook, which is correctly logging keys as long as the focus is on the skin window. As soon as the focus is on the WebView window it stops logging.
I will leave this for after committing current changes. I'm somewhat clueless on this area. I haven't found an example of using
put_allowhostinputprocessing properly, the option is somewhat new. All examples I've seen is how to enable it but that's not much helpful lol
RicardoTM05 commentedon Dec 22, 2025
Here's the newest build for the PR.
[Deleted]
More information here:
#12 (comment) [Closed]
RicardoTM05 commentedon Jan 7, 2026
Just to give a heads up before posting a new testing build and a new PR:
The previous PR was closed due to several parts of the code being changed.
We now have a perfectly working way to drag the skin. The reason why I was not being able to use a hook was because of the old UpdateClickthrough function, which was causing the plugin to crash on load or and on unload when a subclass window procedure was used, or even with the hook only.
Once said function was removed I was able to implement both. The low level hook now can monitor the ctrl key state and send a custom message to the subclass win proc of each skin when the key is press or released.
Since I was now able to monitor the key, I rewritten the old UpdateClickthrough function and used it for this, basically when you press ctrl, a soft clickthrough state is enabled which lets the user interact with the meters behind the webview window but without losing keyboard focus so ctrl based hotkeys were still available. While this method lets the user drag the skin and open the skin menu, it doesn’t have anything to do with them as AllowDualControl used to do. So I decided to rename it SkinControl.
SkinControl has 4 modes:
After some testing, these 4 modes showed to be enough to cover various scenarios.
Since SkinControl now covers all those scenarios, the Clickthrough option was removed as it became redundant.
The PR I will present also includes new options which I will cover soon, it also includes new defaults for options that are still not exposed to the user.
I was working on scripting and frames for this new PR as well, however both proved to need more careful planning to be implemented on a better way, so I decided to delay those features in the hope we can focus only on that in order to plan it carefully and hopefully find a fix for RainmeterAPI not being available on certain sites as well.
That being said, the new PR will focus on SkinControl, the measure’s string and number values rework, and a few new options which I hope will enhance WebView’s customization.
Last but not least, it will also include a new feature called VirtualHost which will be very useful to replace the need of an external http-server in certain situations.
RicardoTM05 commentedon Jan 12, 2026
New PR has been created: v.0.0.8: Reworks, Options and Settings. There you will find details.
Since most example skins were modified, A .rmskin package is included this time.
Removed
Current options and defaults
Yincognyto commentedon Jan 12, 2026
Now that you listed all options and commands, they don't seem that many after all, even with potential frame / script options...
RicardoTM05 commentedon Jan 12, 2026
There’s room
RicardoTM05 commentedon Oct 9, 2026
Current status for v1.1.0
Following the security recommendations on the other issue:
ApiAccessoption to the measure. EnablesRainmeterAPI(disabled by default)FileAccessoption to the measure. Allows file:// and virtual hosts to read and write files using the File System API without requiring permission. Any other site will ask for permission as normal. (Disabled by default)Open in default browserto the context menu.Zoomis used on a skin and correctly reacts to changes ondpi(for Rainmeter 5.0, it has no effect on earlier versions)..rmto the generated url (rmmeans rainmeter). For example,https://rootconfig/index.htmlwill now behttps://rootconfig.rm/index.html. This fixes the 2-second delay seen when using the virtual host feature. Unfortunately, since the origin is now different, users usingLocalStorageorIndexedDBor any other feature that applies to a certain origin will experience a data "loss".UDFwill now be created inside Rainmeter’s plugins folder. It used to be created on the temp folder, which would eventually cause the user settings to be deleted.MeterNameoption to the measure. The plugin requires a meter underneath so the WebView area is clickable, this means that for skins that are resized dynamically one has to keep track of both the plugin measure and the meter size. This option makes the meter follow the size and position of the webview area. The meter will be automatically updated and the skin redrawn wheneverX,Y,W,HorMarginchange and the measure is updated.Marginoption to the measure. This option shrinks the WebView area by the given positive value in pixels, creating a separation between the meter set onMeterNameand the WebView area.RainmeterAPI.UpdateWebViewArea(x, y, w, h, margin)to the host object. This function allows to update the WebView area directly from JavaScript. No measure update required.Testing build:
WebView2_v1.0.8.2435_x64_x86_dll.zip
Yincognyto commentedon Oct 10, 2026
Thanks, Ricardo!