v.0.0.8: Reworks, Options and Settings. #13
Conversation
Introducing various new options and features Introducing SkinControl Introducing external user settings
|
Thanks for the PR. I'm not sure why Rainmeter crashes when unloading the skin while using WebView2 in this version |
|
First impressions, after only changing both locales in UserSettings.ini to en-CA so that the browser's task manager is in English:
Quick question: Is the ExecuteScriptFile / Execute < InlineScript | FilePath > command supposed to be dealt with in the next PR? |
|
Which skin(s) crashed? Yes, that command is part of scripting. Ok I see the crash, will investigate. Thanks for reporting. I might have forgotten something when cleaning the code. The crash happens while trying to remove the subclass procedure for Skin Control. It’s been an on and off fight with it since implemented. It’s the last piece on the puzzle to have SkinControl working perfectly. As workaround for now just to avoid it from crashing just leave one WebView2 skin running while testing. It will only crash when the last skin unloads. |
|
Please test new package, I updated it on the same post it stopped crashing for me, also added logs for when the class and the hook are removed. The hook is only installed when the first measure is loaded and removed once the last measure will be removed. The class is set/unset on each skin load/unload |
It seems to have stopped crashing on skin unload for me too, as far as I tested it (the Clock skin was the quickest to crash for me earlier). I tested in both single and multiple WebView2 skins loaded scenarios, and so far, no crash yet. Would the new system (which seems to be a winner against crashes) add some kind of "performance overload" to the plugin, or is it negligible? |
Interesting, thanks.
I haven't found a fix nor implemented a new system yet, all I did was adding the logs lol. It's a bug that doesn't like being observed. But this got me closer, at least I know where things are happening and have a better clue as of why. |
The "fix" is because of the delay created by logging, if that's all you did - it happened in other unrelated cases for me. Something doesn't have the time to be freed / released / disposed / garbage collected normally when the skin unloads - my suspicion. Bugs and inconsistencies:
|
|
It's fixed already, will update when I get on the pc later. Edit. Spoke too early.
Not a bug, this is normal. When SkinControl=1 The plugin can't magically block the skin menu for the whole skin, it only controls WebView related stuff. The ContextMenu option This is important to understand:
Yep, that's because CTRL is pressed and WebView doesn't scroll when CTRL is pressed, even if zoom control is technically disabled, not a bug and there's not much I can do about it. As a quick test, simply set SkinControl = 0 and ZoomControl = 0 and try ctrl + scrolling, it won't do anything, it won't scroll the page, not because of the plugin, that's how the browser works. The "fix" would block all CTRL hotkeys instead of only the ability to scroll. If you enable NewWindow, it will also make every link you click open on a new window (because you are ctrl + clicking everything). Not a bug. Just ctrl + click the document so it gains keyboard focus, release ctrl and scroll using the up and down arrows. You can also enable caret browsing (F7). —— Something that is also important to understand is that WebView and the actual skin are 2 different entities, we basically have a window on top of another window. They don’t share neither mouse nor keyboard focus. That’s why SkinControl exists, to be able to control the focus between both windows by technically disabling the WebView window while keeping it visible to us, but invisible to the mouse. This of course comes with limitations like the aforementioned. Still the option is great because it covers multiple scenarios, but yeah, it’s not perfect. The app-region feature, which I just remembered I didn’t mentioned on the post, comes really handy as well (with its limitations of course). I used it on the header of the YouTube player by the way (in case you haven’t notice it yet). Really handy but of course it also have limitations (the browser’s context menu doesn’t work on the area, but the skin menu opens if you right click on it, and more). |
|
Alright, should be fixed now. Updated the package on the same post Turns out it was my bad. The bug was more specific than simply crashing when unloading. I also improved the logic for the config file parsing logic as it was slowing initialization down a little, should perform better now. Will commit after I'm sure everything's ok. |
|
I hadn’t reviewed all the changes earlier.One question why did you use the external SimpleIni.h library? What is its purpose? Why wasn’t the default Windows API used instead? |
No, it's not normal, that's why I said "bugs and inconsistencies" (my bad, should have used "or" instead of "and", and only used "bugs" because I didn't know if it was intentional before checking the source code myself). I do understand how this works and never mentioned that blocking the skin menu was expected for the whole skin, I referred to the webview area only. My point was more about SkinControl=2 being deprived of page menu in favor of ContextMenu having the last say, than about skin menu, tbh. Let me explain why they're inconsistencies, and why this can be "better":
Like 1), 2) happens even considering that SkinControl=0 is supposed to mean "no skin interaction" (including skin menu, btw). Now, I'm not contesting that it's nice to not have to hold CTRL for one behavior or another, or that it isn't useful, I'm only saying that it makes no sense having that for a functionality that's incomplete (who would want selectable text that he can't copy paste on the page in the first case above, or a skin that can trigger its context menu without being able to be dragged in the second case above - assuming the above option values would be set), or unintuitive (in the case of the Calendar skin, the user has to remember that: a) even though he can skin menu without CTRL, he can't drag without CTRL; b) even though he has to CTRL for dragging, he can skin menu either with or without CTRL). These things all happen in the current implementation. All this was supposed to be done by "SkinControl" itself, where you'd get the complete package of environmental behavior (that is, both drag and menu for that environment, and not just one of them) either by setting the option to a value, or by toggling behaviors via a hotkey or similar, e.g. full page behavior when X, alternate full page or skin behavior when Y based on the hotkey, full skin behavior when Z (honestly, even though we added them just to have all the combinations, ContextMenu=0 while also SkinControl=0 doesn't make much sense in terms of usage either). Especially since you already added the "Skin Menu" item to the page menu, so now even if SkinControl=2 and ContextMenu=1 (or even only the former) one can access the skin menu without pressing CTRL anyway (well, it's an additional menu, but Windows 11 already does that, so no big deal). To be even clearer to you, Ricardo, SkinControl was working fine with the previous SkinMenu, now the one thing that made it complete and literally everything one would need in terms of "dual control" (i.e. full page control too), even without CTRL, is gone and depends entirely on having ContextMenu=1, since otherwise all you'd get is various skin menus and no page menu.
This SkinControl=3 point actually makes way more sense than the first point, and I agree. That being said, the user might wonder: "hey, how come I can actually type in a google box when only pressing CTRL to enter the box and not while typing, while I can't do the same when scrolling"? I'm sure there may be a reason for that too, I'm just saying that unfortunately SkinControl=3 also results in an incomplete behavior (just like for the first inconsistencies above), where you can very well "toggle invert" everything (that's credit to you all the way, coming up with the idea on how to do that)... except scrolling. Even if you'd want to use that, you'd always have to keep in mind that, well dang, scrolling "doesn't work". You know better when you say you cannot do much about it, just that I - and probably whoever tries it - will think whether the box typing trick can be used for scrolling to, i.e. without having to press CTRL for the entire duration of that action. These are just some things you guys can think about if you want. I'm not trying to convince anyone of anything anymore, my only point was that having certain things work only partially in different circumstances (whether it's about the context menu, the skin control, the api, the frames, or the scripting) when in some cases a resolve might be possible, makes something a situation I thought we left behind with the old plugin. It's not your fault, you're trying hard - it must be me cause I want it all and don't accept limitations. Most likely MS fault too, by not providing easy ways to pass control to the host app and others, or not providing them in due time (5 years till done). |
I came across it and thought it could be useful, I tried it and liked it for its simplicity, it’s a single 129kb file and saved me some time. But it can be removed of course and the logic replaced with window’s logic if you feel it’s overkill. Not an external library exactly as it doesn’t have dependencies, it’s a single Simpleini.h file As of why it was causing performance issues before, it was me, not simpleini. I was reading and writing the file on each initialization step instead of only once on environment creation and save the file once WebView was initialized. |
You are defining SkinControl like if it was meant to control all skin-mouse related features all at once, and I get it, it makes sense. But that's not how it works. It simply allows the mouse to interact with the skin. It doesn't cover what happens to the context menu. Even if it did, how would it do it? Let's say ContextMenu doesn't exist. How do we control what happens to the browser's context menu? We just don't? We have to be forced to use JavaScript if we want to display the SkinMenu or the SkinCustomMenu on WebView? Should SkinControl have 7 values? I'm sorry, you tried to be even clearer to me but I still don't understand. I thought you didn't like SkinMenu either because of the same reason.. And now SkinControl is not working fine because SkinMenu was renamed ContextMenu and was given 2 new values? I'm interested on your opinion about this too @NSTechBytes, if you don't mind.
I don't have to be convinced, I just need to understand. I keep without understanding exactly how SkinControl should work. This is what I've come up with that actually worked, and I worked around it's limitations to offer customization to the user. You also link to a WebView2 thread about To me the perfect "SkinControl" would be the one that wasn't even an option. Simply have the plugin work flawlessly with the skin like if it was just another meter, same for clickthrough and all other skin settings. Just don't know how to do that. |
|
I think SkinContextMenu would be a clearer name than SkinMenu. |
You're actually very close since your snippet covers all bar the custom skin menu feature, which can be at SkinControl=3: Longer version:If you look closely, the rest of the combinations now are either not doing anything (e.g. SkinControl=0 + ContextMenu=0), doing too little (e.g. SkinControl=2 + ContextMenu=0 lacking page menu), not able to perform operations (e.g. SkinControl=3 + ContextMenu=1 and page scrolling), or being redundant / reproducible already in a different way between operations (e.g. the rest). Heck, even with no skin menu or skin custom menu available in 3 of the values above, you already integrated the "Skin Menu" item into the WebView context menu internally without any JS whatsoever (at the cost of an additional click just like in Win 11), and I bet you can do the same with a "Skin Custom Menu", if you insist in having it - so a skin like the Calendar one doesn't even need ContextMenu=2 anymore since you already have the item in the WebView context menu. Likewise, one can already integrate stuff like Dev Tools or Task Manager in the skin menu or the skin custom menu for the reverse. Like I already said to you - but of course you don't remember, while you expect me to remember what property you used 3 weeks ago, as a non C++ developer, despite the fact that I was only trying to help - I was completely neutral to the previous SkinMenu, I didn't like it, I didn't hate it, I just didn't care about it, since for me personally SkinControl=2 + SkinMenu=1 was already doing everything I wanted to have and more than just SkinMenu alone - I didn't find it hard to hold CTRL when I needed. I would have had zero problems with the existence or naming of ContextMenu too, if SkinControl=2 wasn't deprived of page (aka browser) menu when ContextMenu=0. I know that this is the logical behavior given the new circumstances, it just felt like an attack on the - again - only option (whether it's named SkinControl or else) which can have everything about control if combined with ContextMenu like above, instead of taking away from it and essentially crippling it in that particular combination, so it was a defense mechanism from my part. Sure, I still have the almighty SkinControl=2 + SkinMenu=1 one which is ideal for many reasons and understandably quoted by you above, but if you did that, then I expected worse might happen to it later on. To me, that SkinControl or whatever option is untouchable, it's a deal breaker for me, after finally getting it right starting with nstechbytes' Clickthrough which was beautifully developed by you into what's now SkinControl. You have to understand, Ricardo, that, to borrow from a classic, I have to put myself in the end user shoes because no one else does it. The end user won't really care or know if SkinControl and ContextMenu are different options or are internally based on different approaches, he will see them as one unit giving him the control he needs over the skin or the page as desired. My point is that in the current implementation, even though basically covering all angles like we both initially agreed which is fine, you can get easily lost when using them (e.g. do I need to hold CTRL for this or that, or not?; what was that value doing again?), some combinations simply allow only "drag" or "menu" and not the both expected by the user when using the same technique (for the record, by "page drag" I mean the equivalent of skin drag but on the page, which usually results in selecting text), and some combinations like SkinControl=3 have unfortunate drawbacks that might cause more questions than answers. Shorter version:To summarize, I felt that SkinControl=2 + ContextMenu=1 / SkinControl=0 + ContextMenu=1 were threatened by ContextMenu=0 taking features from SkinControl that the previous SkinMenu didn't, I eventually realized the many combinations can be confusing, and saw some of them as incomplete or problematic. If the 2 above combinations are safe I'll be fine, but it might be difficult to explain them satisfactorily to users. I'm not opposed to them, just wary about them. And yeah, the ideal control shouldn't even had to be an option, it should have been provided seamlessly by WebView2. |
|
I’m just going to give @NSTechBytes more context first because he’s obviously clueless about all our conversations through PM’s.
Sorry, SkinMenu is an option that never saw light out of PM’s between Ying and me. It simply used to replace the browser menu with the skin menu. The same that ContextMenu=1 and ContextMenu=2 does right know. At some point it was also Ctrl controlled, but when SkinControl was introduced, SkinMenu needing ctrl was not useful anymore as SkinControl was already “doing” what SkinMenu used to do, it was actually limiting. And no, it’s not that I coded SkinMenu into SkinControl, it’s only that when SkinControl is enabled the user is clicking the skin instead of webview, so the SkinMenu is what’s available by nature when the user is interacting with the Skin and the BrowserMenu when interacting with WebView. Just to give more context, my first implementation of SkinControl was WebView based instead of via a hook, and was not as good as this new implementation because it wouldn’t work if WebView didn’t have keyboard focus. Then I “hacked” into it to make it possible but it wasn’t reliable enough, there was a delay. So it was until I managed to implement the hook correctly that I was able to have a better working system that didn’t relied on WebView at all, no keyboard focus issues and had no delay, the real SkinControl option was born. It wasn’t that I decided to remove the Ctrl based functionality out of the now gone SkinMenu, is that it’s functions relied on the not working correctly system I had just replaced by the hook. But now SkinMenu was naturally opening the SkinMenu because the right click was now happening on the skin while holding Ctrl. Since SkinMenu was now obsolete I made it into ContextMenu which is not Ctrl controlled, it simply allows to change what context menu pops up on WebView. It also allows to completely disable the context menu. Totally independent of SkinControl (which again, doesn’t control the menu at all). Why do I think ContextMenu is good? DetailsIt allows for different combinations. Like the Calendar skin which now feels like a normal skin, there’s no browser menu on that skin, only the SkinMenu and still draggable while holding ctrl.On the clock and prayers skins there isn’t a browser menu either. But that’s because SkinControl=1, and that renders ContextMenu unusable. Why? When SkinControl=1 there’s no interaction with WebView, and ContextMenu only controls what happens on WebView. Technically, SkinControl=1 is the same as if you had Clickthrough=1 on the previous version. ContextMenu only applies when SkinControl=0, while NOT holding CTRL when SkinControl=2, and while holding CTRL when SkinControl=3 Again, that behavior is not coded anywhere, since ContextMenu is a WebView option it only applies when interacting with WebView. Why is it allowed to completely disable the menu when ContextMenu=0? DetailsJust because that was naturally what 0 means, ContextMenu=0 means disabled which means no context menu logically. Is it useful? May be.Why didn’t I simply merged SkinControl and ContextMenu? DetailsAgain, SkinControl does nothing but toggle Clickthrough on and off. In pseudocode:The plugin can’t control what happens out of the WebView area nor inside it when Clicktrhough=1 so SkinControl can’t simply replace the SkinMenu with anything because it has no control over that, it doesn’t control any mouse gesture or anything, it simply toggles Clickthrough and nothing else. No, it doesn’t make the skin draggable either. The skin is draggable because you are physically dragging the skin. SkinControl literally means “To Control The Skin”, I guess “ClickthroughControl” would have been a better fit. It was gonna be called Clickthrough instead but we thought it being called Clickthrough would have been even more confusing since Rainmeter’s clickthrough has only 2 values: 1 and 0. How does ContextMenu work then? DetailsContextMenu is linked to WebView’s OnContextMenuRequested event, which allows to intercept context menu requests and return the skin menu instead, or even block the context menu. So whenever SkinControl enables Clickthrough there’s obviously no ContextMenuRequested event because the user is not clicking on WebView. That right click is totally handled by Rainmeter. Yes, the user can intercept that by using the RightMouseDownAction on the meter behind WebView that is used as background.How does exactly SkinControl work? DetailsWhen the plugin is loaded it starts a low level keyboard hook, this hook is global for all skins. It also subclasses each skin window, each skin has their own subclass procedure. When the hook detects a CTRL key press/release, it sends a custom message to all WebView skins. Setting SkinControl on a skin allows that skin to read those custom messages through its subclass procedure. Now the skins know if CTRL is held or not through the custom window messages that arrive to them. When SkinControl=2 the CTRL pressed message enables clickthrough, and the released message disables clickthrough. When SkinControl=3 its the other way around. When SkinControl=0 or 1 the plugin simply disables or enables clickthrough. The hook is still sending the custom messages but the skins simply ignore them.In short:
Why did I add the SkinMenu option to the context menu? DetailsI consider that it being a Rainmeter plugin should give access to Rainmeter’s skin menu at all times one way or another.— Now, to answer Yincognito: NP means Not Possible
Hopefully after reading how SkinControl works you understand why it is not possible to do what you ask for. The way SkinControl works right now doesn’t allow for it. I don’t know about you, but at least I don’t know how to do what you are asking for, I have no clue, you are basically asking to drag the skin while interacting with webview and get the BrowserMenu while interacting with Rainmeter, things that if were possible they would be already implemented. However I’m all ears and welcome anyone that proposes a system capable of doing such things. — What I propose: Details
This would be less customizable but far more consistent. All WebView windows would be, by rule, disabled/unclickable while holding CTRL, this way we make sure that all skins are, by consequence, draggable while holding CTRL. Collateral:
Those are the only things that I’m aware that wouldn’t work on this system, but there are workarounds for them.
Why ContextMenu stays?
Without SkinControl “confusing” anyone, everyone will understand that the option is to modify WebView’s context menu.
How are they going to understand that?
We are going to clearly document that pressing ctrl disables all interactions with WebView and nothing else, it doesn’t control menus nor anything like that. To control what happens while ctrl is pressed the user has to use Rainmeter, like I did on the BangCommand.ini skin that when you press CTRL a hint displays below, that’s simply a MouseOverAction on the background meter. Or that Ctrl + Scrolling zooms the site, those are simple MouseScrollActions on the background meter.
Why don’t we use a Mouse Hook instead to actually drag the skin without needing CTRL?
WebView is interactive by nature, there are many elements that can be dragged. Using a mouse hook would make it very hard to decide when it is safe to move the window and when it is not. This is because WebView can’t give us information about anything that’s being rendered on the WebView window without using JavaScript (which is out of the table given that is not reliable on all websites).
Without that information we could only take half-informed guesses based on window messages related to things like mouse position, cursor kind being requested, etc.
That doesn’t guarantee that we won’t break some page functionality by moving the skin window instead of dragging an actual web element.
|
|
Notification: Updated post above. |
|
I. 1st proposal (@Yincognyto):
TBH, I only left 4. because you like SkinCustomMenu, otherwise 1. + 2. + 3. are practically enough (4. is reproducible in 2. & 3.). Basically, 1. is all around browser behavior, 2. is all around skin behavior, 3. is CTRL toggling between browser and skin behavior. The 1. would go to SkinControl=0, the 2. would go to SkinControl=1, the 3. would go to SkinControl=2. A simple, effective option. Even if one wanted the skin standard / custom menu while the browser behavior was active, this is already present, credit to you: II. 2nd proposal (@RicardoTM05):
As much as SkinControl=2 functionality is useful, enforcing it is not. As was already mentioned, this means that:
So, the user won't be able use any CTRL + Mouse events in Javascript, which would break skins relying on that. III. 3rd proposal (alternative): Another way to approach this, if the 1st proposal is still not acceptable even after proving it's possible, would be to just remove SkinControl=3 and ContextMenu=0 from the current implementation. This won't fix inconsistencies, but will eliminate what's not working or useful, and alleviate things in that regard. This requires minimal work and will provide "some" context menu in all cases like it's normal to happen while removing the unworking scrolling, but on the other hand it won't change the fact that the "clickthrough" system and the "contextmenu" system are simply not connected with each other in a coherent fashion like the user would expect, which is more or less the root of the problem in this matter and what the 1st proposal is trying to address. It's hopefully clear how the 1st proposal is coherent, unrestrictive, simple and functional - just what the end user expects. |
I read again, you clearly wrote:
SkinControl=1 = Clickthrough=1 If you can’t click on WebView you can’t request the BrowserMenu.
Then it doesn’t even make sense that you mentioned it, we are talking about what the plugin can do, and it certainly can display the skin custom menu, only not where you are trying to place it. What you propose is equally restrictive. Enforcing the BrowserMenu is not a good idea, even if I already added SkinMenu as an item. On the calendar example you showed it perfectly. 
The BrowserMenu is not as useful as the SkinMenu on that skin for the simple fact that the browser menu is not modifiable. Using the SkinMenu or the SkinCustomMenu is more useful for most skins because it lets give the end user direct access to custom functions that really matter for the skin (see Clock.ini), not for a browser. You want it to be:
When it could be simply:
PS. I’m using Clickthrough instead of SkinControl to be clearer on functional meaning, but I'm still taking about SkinControl. Definitions:
Since Mode 1 is non interactive they will only have access to the SkinMenu/SkinCustomMenu through Rainmeter. Modes 0 and 2 have access to all context menu types based on their preferences, no restrictions. Only Mode 2 has ctrl based functionality and restrictions which may or may not affect skin functionality, in case it does then they can move to Mode 0 and implement their own logic through JS as they like, or stay at Mode 2 and simply re-think their logic to not use Ctrl. This system satisfies everyone, I know you will stay at Mode 0 and use full scripting, I would certainly sit on Mode 2 and most beginners using webview to display simple stuff will sit at Mode 1. While browsing skins are possible and totally supported, those shouldn't be used to define what should be the standard for everyone. We should be using original skins as the standard, not skins that simply display a website or try to mimic a browser, which again, are totally supported and perfectly valid skin types. Third proposal:
Take into account that removing the ContextMenu is also possible through JS, so I don't see why the plugin should forbid it: And, if you indeed give a good reason why it shouldn’t be allowed, then the option should be renamed again because 0 won’t mean disabled anymore, which will be confusing.
ContextMenu and Clickthrough systems are not related, they are not connected. You or the user expect it or not, they are not and they won't be because, in fact, they technically can't be connected through the current implementation. One controls WebView context menus and the other the ability to click on the WebView area. Relating each other is like relating an apple with a pineapple just because both have “apple” in their names. What do you think @NSTechBytes ? I think we should forget about SkinControl as a name and use clickthrough as that is apparently less confusing, even though it has 2 values instead of only 1. |
|
I think ClickThrough is fair enough, as adding more options can create confusion for users. We can achieve the SkinControl behavior by using the basic functionality of the plugin. |
Exactly! Sorry, I meant SkinControl=1 -> SkinControl=1 + ContextMenu=2, I was misled by the fact that SkinControl=1 + ContextMenu=1 does precisely the same thing in practice, i.e. give the skin menu, when I wrote it. I know why this happens, but users who don't will find it confusing, redundant and against the docs that say ContextMenu = 1 = browser menu and ContextMenu = 2 = skin menu, yet they do the same skin menu for different ContextMenu values. They'll say that "the browser menu doesn't work when ContextMenu = 1", and "why skin menu is given for both the 1 and 2 values of ContextMenu".
I only mentioned it because you added ContextMenu=3 on your own in the first place, even though it was perfectly reproducible from the skin itself, so if anything, it didn't even make sense that you added it. That wasn't the point though, the point was that is possible which is is, despite the NP argument and that "I" was the one mentioning afterwards. Seriously now, this is not about me and you, your options vs my option, your skin vs my skin, we need this to work coherently for everyone.
I already mentioned this, but it's ok, I'll repeat myself for the N-th time - Windows 11 already does this with the "Show More Options" item in its context menus, yet I didn't hear you complain about it, being a happy Windows 11 user, it's only when I propose the exact same thing, based on your own work and brilliant addition of Skin Menu in the browser menu, only then it's an issue. But I'll give you that, you do have an argument here, unlike in other cases, but hey, they can't be all in front, right? I'll again do what I shouldn't do and give you ideas that you can abuse on me later on, just because we're friends, lol: maybe you can also expose the browser menu items to the user so they're free to make a mess out if it and move their own items from the skin menu to the browser menu. This has an additional benefit, at least for me: the browser menu is same theme as Windows aka dark, while the skin menu insists being light cause well, I have no idea why (yes, I know I can force it dark, just saying).
I just don't understand you grasping at straws at every word I say - "you want it to be" is precisely "when it could be simply" above - literally the only differences between what you implemented and what I proposed are these, for my proposal:
I don't want ContextMenu gone, I simply want it work seamlessly and coherently with Clickthrough in the background, that's it.
No. I use both Clickthrough=0 AND Clickthrough=2 (the 1st in my Earth cause it's already written, the 2nd once this is done and because it's toggleable by demand being CTRL based). I don't use Clickthrough=1 simply because there is no way to get the (complete) browser behavior in that case, which is what this plugin should be all about, along with skin behavior of course.
I just gave you the most compelling one: nobody wants no context menu at all. It's either one or the other, as the user desires.
You keep bringing this even though I proved the exact opposite above. Ok, I wrote SkinControl=1 -> SkinControl=1 + ContextMenu=1 when I should have written SkinControl=1 -> SkinControl=1 + ContextMenu=2, my bad I was misled by your implementation in the first place, but it's not a big deal, since I repeatedly said that I meant complete skin behavior when referring to that choice, aka Clickthrough=1, obviously with the skin menu and not CTRL based, to make it clear what I meant. So, to summarize: It's the same thing, for the love of God. Just with the internal ContextMenu behavior not exposed as an additional option confusing users and providing unrelated behavior compared to Clickthrough and same behavior for different option values as clearly explained in my 1st paragraph, but aligned with what Clickthrough does, either via your own internal code for ContextMenu or coming it naturally as a consequence of Clickthrough. So, when I'm dragging the skin I also want the skin menu, when I select some text on the browser I also want the browser menu, and when I hold CTRL I can choose between them. I'm ok with the ContextMenu functionality if that helps, I just don't want it behaving differently than Clickthrough itself. |
|
Ok, let's agree to disagree. I'm not following this conversation, I could go on giving reasons why keeping We all agree on
@NSTechBytes has the last word about what we disagree on: @Yincognyto 's @RicardoTM05 's
|
So you're ok with only: just make sure we're all on the same page with a single, clear and coherent option? |
|
To be perfectly clear, I’ll repeat myself.
The functionality Ying mentions above that has to do with menus is consequential only, not To test how the plugin would work with To test with ContextMenu use: PS. |
We should all agree on this, this is not a plugin for just one of us, but for everyone, and we all want the best for it.
I'm ok with it either way, that why I said "or coming it naturally as a consequence of Clickthrough" earlier. I would have preferred to come from your ContextMenu functionality, just to avoid all this and please you - hence compromising with the alternate proposal rejected earlier. I have zero intention of antagonizing anyone only because of a ContextMenu option that just doesn't follow what Clickthrough does in terms of consequential or not effect on menus, and has a part in having the same behavior on menus for different values of the option, which was my entire case in this too long and too heated discussion... |
I totally understand that you defend your position, as I defend mine. We are on a disagreement and that’s perfectly fine, you don’t have to please me nor I have to please you. We are both looking for the best for the plugin from different points of view and that’s fine. I understand your position: you see Clickthrough=1 and holding Ctrl while Clickthrough=2 shadowing ContextMenu as incoherent, inconsistent. That can raise questions about why is ContextMenu “not working” at all when clickthrough=1 or partially when holding Ctrl. We both have our opinions and made our decisions, now is NSTechBytes turn. PS. I also agree that we should all agree on the same, but let’s be human, we can’t agree on everything and that’s fine. We can agree with whatever decision NSTechBytes takes and move on. |
|
If you don’t mind, I’m not in favor of using a ContextMenu because it conflicts with the ClickThrough behavior. |
|
I’m also considering releasing the final version of the plugin, as it now seems stable enough for release. Some testing is still pending on my side. RicardoTM, could you please update the README when you have time? You’re familiar with all the recent additions and changes. |
Let me know if you have questions.
Sure, I will be adding to it as I have time. |
|
I agree with everything Ricardo said - we need people to start using this consistently (with the addendum that we're aware of the YouTube issue with RainmeterAPI and of a potential workaround, and we'll try to find the best solution for it, hopefully "official" if possible as nstechbytes said, and implement it) as its "core" is already in its final & stable form. Maybe suggesting them to already have a version of their work (i.e. skin or skins) using the WebView2 plugin instead of the old WebView one (like I did with all my skins, Earth, BlueMarble, etc.) would be a good idea, as it's just about adding a "2" to the plugin name and potentially set a few options (like e.g. Clickthrough) as desired to do this. I'm of the firm belief that only actual usage in "real world" scenarios with skins and everything, would allow any user to let us know of any other things (ideas, issues, scenarios, etc) worth considering, if any - and for that, the time off Ricardo mentioned comes really handy, as it allows that for everyone. The scripting / RainmeterAPI can be done "in the background" from a development point of view, of course based on everyone's feedback on what would be needed at least at a minimal level, as anything pertaining to it won't (radically?) change the existing options. Speaking of scripting, RainmeterAPI and YouTube, I'm not yet sure how we should best inject RainmeterAPI: only in the top window, or in all windows (all descendants, not just direct top window children). On one hand, the former seems the best solution in terms of efficiency, non redundancy and maybe performance, but on the other hand it's only the fact that Ricardo did the latter that allowed me to discover what could be a potential workaround (e.g. using window[N].RainmeterAPI instead of window.top.RainmeterAPI). By the way, Ricardo, maybe you should send nstechbytes (or even post it somewhere in our GitHub conversation thread) one of your plugin versions that does scripting / all descendant frame injection of RainmeterAPI (so as to avoid you working on adding that on the current version now just for this), only for him to be able to test the window[N].RainmeterAPI workaround on YouTube and see that it works, because as of now I think he only has my report about it and no means of testing / debugging / see why that happens and why it doesn't for the top window, etc. If we're going to try and solve that, we should use all resources (and people) we can, you never know "what hole the rabbit comes out of", so to speak - after all, I only discovered that because I spent time trying all avenues on those versions of yours, and while I am a developer, I'm not even a C++ developer... P.S. Minor observation on the sample BangCommand.ini file, Ricardo - the "tooltip" below WebView still has the value of 3 info. |
|
The current version already injects RainmeterAPI on the main document, top and nested frames. This is because it is injected through the It’s only ExecuteScript command that only executes scripts on the main document. The other version was executing on every frame as well, which was not the best implementation. I personally liked more using the designated frame event script actions instead of having ExecuteScript triggering on all documents at the same time, iterating on frames is expensive. The script actions were more “organic” as they would trigger at the right times on frame events instead of everywhere at the same time. The only thing missing was being able to choose what frame to execute the scripts on, unfortunately frame recognition is not possible as there’s no information accessible to both the user through html and the plugin that could be used to identify them. Sure I can publish a version for him to try the workaround. Just know that current options may be missing, have different name or work differently. Will do on the appropriate issue. We should also take a decision about ExecuteScript by the way before any release. Should we leave it as ExecuteScript or should we only name it Execute instead? So, it would be something like: Then we could have another like: And I mean, it could work with ExecuteScript too only that it would be longer. But I digress, what matters right now is the command name. Ah, thanks for letting me know, I’ll fix it and will commit together with the Readme.md file when done. |
Ah, you're right indeed - no need to post an older version, this one is sufficient to test how e.g. But yeah, for example, I can do this: and print "Test" to the Rainmeter log from a YT page already, which is good enough to test for anyone including NSTechBytes.
As of now, without more cases to investigate where executing scripts on frames would be really useful, I think it's a safe and wise decision for this PR. Not entirely sure if it applies to every scenario, but I think the user might be able to run the things in his script on the desired frame (probably subject to cross origin security though) just through the window[...][...]... system. My take is that IF the user is already able to run whatever in a frame of his choosing, then the plugin shouldn't necessarily try to do that for him, bar maybe helping out with whatever security system is getting in the way of that.
I personally think just Execute is fine. Either "Execute Script ..." and "Execute File ...", or "Execute ..." where the plugin detects whether it's an inline script or a script file is fine with me (can be variations of that, of course). Just about the only thing I would insist on (for - you guessed it - consistency and coherency) is that the syntax is similar between the two. For example, I would not particularly like "ExecuteScript" for inline scripts, but "ExecuteScriptFile" for script files - in such a hypothetical case, I'd prefer "ExecuteScript" and "ExecuteFile" instead, cause it has the same "syntactical parts", so to speak.
Could be, but like I said, IF the user is able to better select the desired frame than the plugin does it (with the plugin ensuring access to every frame at any level, if possible), then let him do it. The way I see it and based on what you explained to me, identifying frames is trickier from the plugin side since WebView2 doesn't provide enough info for that, so maybe the user is able to better do that from JS and such, if he can run his thing in those frames in the first place. |
|
Alright, I’m fine with that. If the user can do it on their own then I agree on not adding further framing logic as JavaScript side is more reliable. Ok, I think having it simply as And after the scripting update also support: It feels more consistent with the other commands syntax. @NSTechBytes What do you think?? |
|
Sorry to interject before NSTechBytes shares his opinion on the latest subject, but regarding the existing "ExecuteScript" command: just made a quick test, and you can actually use a WebParser (and probably a Quote plugin measure with a file ending char as separator as well) to run even now a script file, regardless of whether you replace newlines with spaces or not which I didn't expect but was curious to see if it worked - which is pretty neat. Sure, if you change that file you'd have to command the WebParser to update before using it again as a parameter to ExecuteScript from the FinishAction, but it works! Obviously, a dedicated "Execute ...file..." would make it much more comfortable without resorting to such workarounds, but I thought you should know the above, as it's quite nice. I just tested my frame digging script file, and it returned all windows (aka frames) on the W3Schools frame test page flawlessly. This could make the "Execute ...file..." implementation much easier as you wouldn't have to bother with formatting the contents of the file (I think?)... Side note, the left side of the W3Schools frame test page doesn't return anything via View Page Source, but it's the same as in the browser, where a View Page Source isn't even given in the context menu, so it's not a plugin issue - just a curiosity to test. |
|
Actually, since the frames logic wouldn't be necessary anymore, I can include the script file logic when committing the Readme.md file if you are ok with that. I already have that logic written so it wouldn't take much time to include it. Then the plugin would release on 1.0 as practically feature complete. |
Me, I'm ok with that, if NSTechBytes is ok with it too. We could present the YT workaround of calling the RainmeterAPI of a suited window[N] for whoever needs it, while we could look for a more "official" way to deal with that (if and when available), as the last piece of the puzzle to have this rock solid. It would simplify things and make this much easier for you. Just a thoughtJust as a last idea on the now removed ContextMenu option that only occured to me now (sorry, some thoughts can occur later): if it's possible to make it enter into effect only if present as an option, the same way the virtual host option reacts (i.e. if ContextMenu option is present, then the actual result table I wrote earlier comes into effect with the interdependency between Clickthrough and ContextMenu; if not present, Clickthrough reacts as if completely alone and exactly as it does now). As long as you'll be the one answering questions on their interdependency from the users and it doesn't get in the way of the current behavior of Clickthrough when the latter is alone, I personally don't have a problem with that. Just an idea, up to you guys to weigh on it, I don't want to restart a controversy, just cover all possibilities of tackling that issue before it's gone forever. If reasonable, fine, if not, also fine. |
I’m not sure I understand. That’s how it used to behave, when the ContextMenu option was not present it would behave exactly as the current version behaves right now. Or was there a “side effect” when the option was missing that I’m not aware of? |
No, you're right - it behaved the same because the ContextMenu default was 1 aka the browser menu when missing. I worded my previous reply incorrectly, writing about Clickthrough alone but referring to those 6 cases where it was actually Clickthrough (former SkinControl) that was getting in the way of ContextMenu in terms of expected vs actual results if the latter was considered "independent" as you'd normally want and expect from an option. Sometimes that Clickthrough "override" was desirable if you looked for Clickthrough behavior (e.g. Clickthrough: [1, 2 with CTRL on] and ContextMenu: [1]), but of course in all those said cases it didn't match with what ContextMenu promised to provide on its own (i.e. the "side effects"). Clickthrough naturally got away easily with it since its existence and flexibility made it essential for this kind of control, so ContextMenu took all the blame for it even though technically it was the former that was overriding things in most cases (with the notable exceptions of Clickthrough: [0, 2 with CTRL off] and ContextMenu: 0, when it was actually ContextMenu overriding what Clickthrough was providing on its own - further adding to the perceived "instability"). Testing mostly in BangCommand.ini which contained and allowed changing both options at will, made the matter excessively obvious, even more so if you looked at the tooltip texts you nicely placed as helpers. But yeah, if on its default of 1 or missing, Clickthrough behaved the same as it is now. I think what I really meant with the above is if there was a reasonable way to communicate that "hey, if you use both you're on your own and the result isn't guaranteed to go one way or another as per each option's own description", it could have been somewhat more acceptable to have both, given the extra that ContextMenu sometimes provided. Too bad the 2 of them together affected the "predictibility" of each... I'm pretty sure even you, after a year or two of settling on one or two particular combinations, things becoming less fresh in your mind, and then starting to often adjust their values, would have been at least surprised by their effect together. |
Well, they are on different categories, while
I highly doubt it. I, personally, understand how Anyways, just to summarize things a little bit for @NSTechBytes, we need answers to these questions so I can commit the readme when done:
|
|
I have no issue with changing from ExecuteScript to ExecuteCommand. |
Just for clarity:
The command Execute would accept scripts as strings or paths to .js files. For example: [!CommandMeasure WebView2 """Execute alert("example"); console.log("script string executed");"""]As a file: [!CommandMeasure WebView2 "Execute #@#script.js"]@Resources\script.js alert("example");
console.log("script file executed");It is not a complete script parser, but a way to execute scripts correctly formatted on their own .js file. I can upload a testing version if you’d like to see it in action. it is especially useful when injecting longer scripts, as you are no longer limited to one liners, but can write a complete script file and inject it. |
|
Not sure what the "like" means but here's the testing version: Simply use on the [!CommandMeasure WebView2 "Execute alert('example');"]or, create a [!CommandMeasure WebView2 "Execute #@#script.js"] |
Exactly, yet they're forced to relate as part of the same plugin. The duo is like this together: functionality = exists, usefulness = exists, predictibility = lacks. The first two are great. The last only exists all around if folks would go "developer technical" about it.
Just to add to Ricardo's explanation about executing script files, it has several benefits:
Think of a more complex animation executed on click or mouse over, as an example. Doing that in a one liner is uncomfortable. I would be curious to know why you thought it was a bad idea. I mean sure, you can use Lua, but can't do as much in Lua as you can with JS, and certainly not necessarily in a web context. This would just bring the abiility to execute JS at the same level to Lua. You tried to do the same, with the unfortunately async P.S. By the way, besides trying to find an official solution for RainmeterAPI on YouTube as a pending issue, I think the ability to use non UI extensions (like e.g. UBlock Origin) would help immensely with both security and comfortable navigation in the plugin. Ricardo already enabled their usage, but it appears a bit more code and testing would be needed to have that functional. It's certainly possible, if the extension is in an unpacked state. We made some tests before, but we're still missing something to work.
I think it's for clarifying and explaining what it meant - I gave you a like for the same reason (I'm slower with likes on GitHub though, I "like to like" things only after the matter is settled and set in stone, so I react "retroactively" in that regard). |
That’s why I initially thought it was a bad idea, especially since the previous version was rejected. However, I now realize that adding the Execute File is actually a good move. |
Ah, ok - sure thing. The rejection was more of an adjustment to try to keep the things that worked flawlessly and as expected. |
|
Alright, so we all agree on
The readme file is almost finished. |
|
About extensions: On Sunday I had some time to re-try extensions with great news. I managed to install them. Unfortunately I didn't have time to actually test with real extensions, I tested with an example extension from the docs. Anyways, I did implement some logic into it. I won't have much time so I would appreciate it if you could test it with real extensions when you guys have time: WebView2_v0.0.8_x64_x86_dll.zip Also only tested with a single extension. To install an extension:
To disable\enable an extension
To uninstall an extension
Logs will be logged when the extension is either installed/uninstalled or enabled/disabled. Here's the extension I was using to test. It creates an "Example" tab on DevTools. example-devtools-extension.zip 
|
|
Brilliant work - this last upload is a keeper, once given the green light! Tested Extensions: Internet Download Manager (IDM) and UBlock Origin (UBO) - Test Results: Success In Both Cases - Side Notes: UI Elements Are Incorrectly DevTools Positioned. I tested everything except What I did was to follow the above instructions by @RicardoTM05, and then simply paste (and rename for conveniency) the WebView2 - Extensions - IDM Enabled, UBO Disabled (W3Schools) > notice how the ad at the top of the page is displayed:
WebView2 - Extensions - IDM Enabled, UBO Enabled (W3Schools) > notice how the ad at the top of the page is not displayed:
WebView2 - Extensions - IDM Enabled, UBO Disabled (YouTube) > notice how the ad over the page video is displayed:
WebView2 - Extensions - IDM Enabled, UBO Enabled (YouTube) > notice how the ad over the page video is not displayed:
In the last two images above you can also notice how the On the same bright side, about the !Execute comand, RainmeterAPI and YouTube... Drag example on YouTube, if CTRL on and Clickthrough=0 (1st valid RainmeterAPI is placed in top.api for usage):The above simplified > "Test" should always be printed at the Rainmeter log when executing the script on YouTube:
Thanks for the great work, both of you! |
|
Great. Yeah the UIs on DevTools is unexpected, but I guess they did it that way so extensions could have UIs. Among other fixes, the package also contains a fix I’m somewhat proud of.
It was really tricky to fix but I was successful at the end. You can see on the YoutubePlayer skin that now you can, apart from dragging it without pressing control, Right Click anywhere on the background and the skin menu will pop up. Right clicking on any other element will display the browser menu.
This was key to fix extensions. Turns out I was calling their APIs from the wrong object lol, including the Extensions API. Those fixes except for the last one were also available on the previous version I shared, but didn’t mention them as they were still under testing. |
Hmm... dunno, to me it looks like either IDM not getting the correct "window" (which is not really a window in the classic sense) coordinates from WebView2 (runtime or plugin), or not expecting WebView2 instead of the browser. Unfortunately you can't test it unless I send it to you, since it has an app behind it which is not free. Also, in the previous extension tests before, I set IDM to capture downloads from the WebView executable and with the new plugin version I noticed that my clouds video was always downloaded from my Earth skin even without me telling it to do so, but once I unchecked the WebView executable from the app, it ceased to do that as expected, while still showing the panel as usual. By the way, the said panel only appears if you reload the page, it doesn't appear the first time - might be IDM or the plugin. In any case, this is on the right track, and I'll further investigate these glitches, because I'm certain there's a solution for them. |
|
Must be either the extension or WebView2. The plugin can only Install, enable/disable and uninstall extensions. It has no access to the extensions. The window issue could be though, given that it’s running inside a “nested window”, which could complicate finding it to attach its UI. |
Just checked the positioning again, and it seems the IDM extension is aware of the video dimensions in WebView, since the panel does in fact position itself from around the left edge of the DevTools window, plus the width of the video area. So, if I toggle the width of the WebView2 measure in BangCommand.ini, the panel will move horizontally according to the changed width of the video, but according to the left side of the DevTools window (more or less) instead of the left side of the video in the WebView2 area, so it seems the 1st possibility above is true. EDIT: Got it with the IDM panel positioning! Well, not in the WebView2 area, where it still displays in the DevTools window, but in a new window, if NewWindow=1, where it displays exactly where it should. So it's indeed about a "proper" window... The IDM extension positioning in a new window (at the bottom):
I think this is down to the extension, which assumes an actual window and not an embedded one, since, well, the app was made for typical browsers in the first place. There's probably some place in the extension code where this could be adjusted. |
|
Like Yincognito, everything is working except Uninstall = true. P.S. Sorry, I can’t join the discussion because the timing doesn’t match my country’s time zone. I’m usually asleep when the discussions happen. |
|
That’s weird,
To install the extension again simply drop the extension’s folder back to the Don’t worry, we are all from different time zones, we understand. :) |
|
Edit: There was a typo. It’s working fine now. |
|
Readme.md finished. New PR -> #14 |
3 participants
This update contains the following:
Measure Returns Rework
Measure Returns Rework
Number Value
The measure's number value now represents the state of WebView2 before any navigation, and the state of the navigation afterwards. The following numbers apply:
-2WebView failed-1WebView not running0WebView Initializing1WebView Initialized100Navigation Start200Loading Site300DOM Content loaded400Navigation CompleteString Value
Current URLNow the measure will return the current URL whenever is available.
Example:
https://www.forum.rainmeter.net/New Actions
New Actions
To reflect states, we also have new actions.
OnWebViewStopActionTriggers when WebView stops successfully.
OnStateChangeActionTriggers every time the state changes
OnUrlChangeActionTriggers every time the URL changes
OnPageDOMLoadActionTriggers when the DOM content finishes loading, it triggers before
OnPageLoadFinishAction.Commands Rework
Commands Rework
There are now only 4 commands:
WebView
Starte.g:
[!CommandMeasure WebView "WebView Start"]Stope.g:
[!CommandMeasure WebView "WebView Stop"]Restarte.g:
[!CommandMeasure WebView "WebView Restart"]Navigate
Homee.g:
[!CommandMeasure WebView "Navigate Home"]Backe.g:
[!CommandMeasure WebView "Navigate Back"]Forwarde.g:
[!CommandMeasure WebView "Navigate Forward"]Reloade.g:
[!CommandMeasure WebView "Navigate Reload"]Stope.g:
[!CommandMeasure WebView "Navigate Stop"]URLe.g:
[!CommandMeasure WebView "Navigate http://example.com/"]Open
DevToolse.g:
[!CommandMeasure WebView "Open DevTools"]TaskManagere.g:
[!CommandMeasure WebView "Open TaskManager"]ExecuteScript
Remains untouched. This command may change in the future to
Execute.New Options
New Options
Clickthroughdefault:2Allows the user to interact with the meters behind the WebView2 window, it has 3 modes:
0disabled: No skin interaction (full WebView interaction)1enabled: Full skin interaction (no WebView interaction)2toggle: Full skin interaction while holdingCTRL.This option is especially useful to drag the skin. By default all WebView2 skins that don't set this option to something other than
2will be draggable while holdingCTRL.NewWindowdefault:0When enabled, the user will be able to open new windows, while disabled all navigations will happen on the main window.
AllowNotificationsdefault:0WebView doesn't allow to use the Notifications API by default, now we can use it by setting this option to
1.AutoStartdefalut:1When disabled, WebView will not start automatically when the skin loads.
UserAgentdefault:""Allows to enter a custom user agent.
ZoomControldefault:1When disabled, internal browser zoom control will be disabled. This means the user won't be able to alter the zoom through default hotkeys such as:
CTRL + SCROLLCTRL + PLUSCTRL + MINUSCTRL + 0AssistiveFeaturesdefault:1Allows to disable assistive browser features: 'Find', 'Print' and 'Caret Browsing'.
Special Feature: Virtual Host
Special Feature: Virtual Host
Now the plugin supports internal virtual hosts. A new example skin called
YoutubePlayershows how it works.This replaces the need to install a
http-server. Although it doesn't come without a cost, skins that use a virtual host will take a little longer to load (not horribly longer though).This feature includes the following options:
HostSecuritydefault:1Choose between
httpandhttpsprotocols.0Not secure:http1Secure:httpsHostOrigindefault:1Choose between using the
Root Configor theCurrent Configas the origin.0Current config1Root configChoosing between one or the other lets you decide how the Local Storage will behave:
Choosing current config will make the local storage accessible only to the current skin (config).
Choosing root config will make local storage accessible to all skins (configs) that belong to the same root (good for suites).
HostPathdefault:""Enter the path to the folder where your
file.htmlis.e.g:
HostPath = #@#This option alone tells the plugin that the user wants to use a virtual host, then generates an URL that's mapped to that folder, using a host name according to the
HostOriginoption, and a protocol according to theHostSecurityoption.How it works:
The plugin knows you want to use a virtual host when the
HostPathoption links to a valid folder. Then it starts the virtual host and generates a newURLthat can then be used to access the virtual host.e.g: Let's say this code is in the
Illustro\Clockskin.On the code above, we chose
httpsas our protocol andIllustro\Clockas our origin. Theindex.htmlfile is inside@Resourcesfolder. The generated URL then will be:https://illustro-clock/Now we can simply navigate to it by setting the
URLoption to that:URL=https://illustro-clock/index.htmlWe can also simply do:
URL=index.htmlThe
URLoption will automatically know that we are using a virtual host and will navigate to the correct URL.The local storage will be exclusive to the
Illustro\Clockskin. Or, in other words, to thehttps://illustro-clock/origin.The other way would be:
On the code above, we chose
httpas our protocol andIllustroas our origin. Theclock.htmlfile is inside@Resources\Clock\folder. The generated URL then will be:http://illustro/Now we can simply navigate to it by setting the
URLoption to that:URL=http://illustro/clock.htmlWe can also simply do:
URL=clock.htmlThe local storage will be shared between all configs that belong to the
Illustroroot config. Or, in other words, to thehttp://illustro/origin.External User Settings
External User Settings
When the WebView2 environment is created, a user folder called
RainmeterWebView2is also created at:C:\Users\User\AppData\Local\Temp\RainmeterWebView2\. A new file is now automatically created at this folder location, calledUserSettings.ini. This new file holds some personal settings that the user can change by manually modifying it. All options will be set to their Defaults automatically when the plugin is loaded for the first time.All options in this file affect all skins, that's why they can't be exposed to the plugin's measure, also some of them require the environment to be re-created, which means the user requires to exit Rainmeter and then launch it again.
UserSettings.ini
Path:
C:\Users\User\AppData\Local\Temp\RainmeterWebView2\UserSettings.ini[Environment]
These options require Rainmeter to be restarted to take effect. Changing any of this options while using the plugin will make WebView2 fail to start, simply restart Rainmeter.
Extensionsdefault:falseAllows extensions to be installed. Extensions are not supported by the plugin yet, this option is there for future testing.
FluentOverlayScrollBarsdefault:trueAllows to go back to the ugly default scrollbars.
BrowserLocaledefault:system.This option determines the language of WebView's context menu and other integrated UI's.
Locales need to be in the format of BCP 47 Language Tags. e.g:
en-USes-MXfr-FRja-JPIf set to 'system', it will use the default OS locale.
A list of locales can be found here: https://appmakers.substack.com/p/bcp-47-language-codes-list
BrowserArgumentsdefault:--allow-file-access-from-filesAllows to enter custom browser arguments. Available arguments can be found here: https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/webview-features-flags?tabs=dotnetcsharp#available-webview2-browser-flags
[Controller]
These options require Rainmeter to be refreshed (using Refresh all), or the plugin to be restarted using
WebView Restartcommand.ScriptLocaledefault:systemThis option determines the default language for JavaScript. It's the default for all Intl based JS functions, such as dates, decimal separators, etc.
Locales need to be in the format of BCP 47 Language Tags. e.g:
en-USes-MXfr-FRja-JPIf set to 'system', it will use the default OS locale.
A list of locales can be found here: https://appmakers.substack.com/p/bcp-47-language-codes-list
PrivateModedefault:falseAllows to use the private mode, aka incognito mode.
[Core]
These options require Rainmeter to be refreshed (using Refresh all), or the plugin to be restarted using
WebView Restartcommand.StatusBardefault:trueAllows to disable the status bar.
PinchZoomdefault:truePinch zoom functionality on tactile screens.
SwipeNavigationdefault:trueSwipe navigation functionality on tactile screens.
SmartScreendefault:trueMicrosoft Defender SmartScreen ("SmartScreen") is a security feature that is enabled by default to help users safely browse the web.
More info: https://learn.microsoft.com/en-us/legal/microsoft-edge/privacy#smartscreen
[Profile]
These options require Rainmeter to be refreshed (using Refresh all), or the plugin to be restarted using
WebView Restartcommand.DownloadsFolderPathdefault:""By default WebView2 will use the Windows Downloads folder. This option allows you to choose another folder as the default.
ColorSchemedefault:systemAllows to choose a preferred color scheme for WebView2's UI's like the context menu and others.
Options are:
system: System preferencelight: Light themedark: Dark themePaswordAutoSavedefault:falseWhen enabled, password information is auto-populated, suggestions are shown and clicking on one will populate the fields, new data is saved, and a Save/Update Password prompt is displayed
GeneralAutoFilldefault:trueDetermines whether general form information will be saved and autofilled.
Other Changes
Other Changes
AllowDualControlhas been removed.Clickthroughhas acquired a new value:2.window.OnInitializeandwindow.OnUpdateno longer change the measure’s string nor number values.URLoption on the measure now works as a Home Page URL and is the URL to which WebView2 will navigate after starting. To navigate somewhere else you now have to use theNavigatecommand. To navigate back to the home page set on theURLoption you now use theNavigate Homecommand. In other words, dynamically updating theURLoption will not navigate, it will only set the new URL as the Home Page.virtual hostor ahttp-server. This works by bypassingX-Frame-Optionsand injecting our own "frame ancestor", which would be the current base URL (origin) that is trying to frame, e.g:https://illustro-clock/orhttp://localhost:8080/.YoutubePlayerhas been added. Shows how to use thevirtual hostfeature.UserSettings.iniparsing.1.0.3650.58.DownloadsView page sourceTask managerandSkin menu. Note: The names of these options won't be translated when using a different BrowserLocale.app-regionCSS style which allows to set draggable zones through CSS.Known Issues
Known Issues
What's next
What's next
After releasing the PR, the focus will be on Scripting support. These features require careful planning to deliver a well thought out implementation.
A kind reminder:
This plugin is still on an Alpha state, which means that many things like options names may change, and other things may be added or removed. This plugin is not suitable for production use as of yet. We of course appreciate you testing and sharing feedback.
A testing build can be found here.