PluginWebView - Make skin using web technology

[Kotofanchik]

By the way, added "proper" manual / on demand updating to the code - see the edited code.

I copied everything again. Although I have not noticed any changes since the new data appeared in the log. And even a couple of times when updating manually, the file size did not grow, but then it began to be added again. The effect is only on my problematic site. Several others update normally.

[Yincognito]

new data from the weather site is still appended to the end of the file. And the file is quite different in appearance from the one saved by the browser. Although the volume is close. It looks like js does not save such data.

I let the skin run while trying to get data from the weather.com site and I ended up with a high CPU usage and a 7 MB file. Rainmeter was barely reponsive and after unloading the skin I looked for </html> in the written file and I indeed found multiple occurences, which means that in this case, data was appended to the end of the file. I think you were right, it's a timing issue probably related to synchronous and asynchronous operations or to some overlapping of actions performed on the file (just look at the parts after </html> in such a file). The amount of data requested was significant in this particular case though (probably around 700 KB the non appending version of the response), so that might play a part in the timing / appending issue, with lighter / smaller responses not exhibiting the problem. The allOrigins API also spent a lot of time until it got the text from the page, in their testing boxes from their site.

Yes, the contents is different from the actual page source - I don't know why exactly. In any case, if this approach doesn't solve the Cloudflare issue, then you might just use a single WebParser directly on a weather site that is accessible, and be done with it.

The effect is only on my problematic site. Several others update normally.

I'd be curious how big the actual response from it is. If it's significant like the case I mentioned above, then most likely the size of it is a cause for the issue. Not going to spend more time on this today, but just to know what are the similarities between what happened on your end and mine in that regard. I doubt anything can be done about this though, since the code seems "by the book" in all aspects.

[Kotofanchik]

My usual answer is 145 kilobytes. But perhaps another reason is that there is a very long response delay. Sometimes he answers quickly, but often takes 10 or more seconds. Moreover, the site may slow down and the connection through the allOrigins API and both together.

[Yincognito]

My usual answer is 145 kilobytes. But perhaps another reason is that there is a very long response delay. Sometimes he answers quickly, but often takes 10 or more seconds. Moreover, the site may slow down and the connection through the allOrigins API and both together.

Yeah, that could be a cause as well, indeed. It took a long time to get the response from weather.com in my case too. Rainmeter is not really built for such large amounts of string data manipulation, and the delay doesn't help either although Javascript should handle that without any issue (I intentionally count time until the next loop iteration and write to the file only once the data is fully retrieved, so that accounts for network delays and such). And since non server Javascript lacks file writing abilities, you get the idea, it becomes tricky.

So, do you want to continue with this, considering that it doesn't seem to workaround the Cloudflare protection anyway?

[Kotofanchik]

For my purposes, it turns out that there is no point in continuing.
But I will think about other options.
For example, force a browser to cache data and read data from the disk cache.
I have not yet found such an opportunity with WebWiev. but at the same time I discovered in the IE cache all the weather pages with which the rainmeter works. Are these traces of webparser work?

[Yincognito]

For my purposes, it turns out that there is no point in continuing.
But I will think about other options.
For example, force a browser to cache data and read data from the disk cache.
I have not yet found such an opportunity with WebWiev. but at the same time I discovered in the IE cache all the weather pages with which the rainmeter works. Are these traces of webparser work?

Alright then. As for the cache files, if I understand this correctly, I don't think those pages are necessarily traces of WebParser itself, but rather traces of browser history (Edge, Chrome, maybe WebView as well?). However, if by any chance the WebView environment (not the plugin) produces such traces and you can identify the names of those pages, you could parse them as local files in WebParser measures afterwards (i.e. after they're created and stored there). So, if WebView eventually gets you the webpage behind Cloudflare and it's temporarily stored in those IE cache locations, maybe you can parse the existing local file normally with WebParser. That will be up to you to see if it's feasible and can be done - I have no way of knowing such details on your system. Plus, you already have examples of how to parse local files, from what we've discussed until now.

[tass_co]

I have a question guys. How can I remove the scrollbar within the page?

[Yincognito]

I have a question guys. How can I remove the scrollbar within the page?

The scrollbar generally appears in a webpage when the area to be displayed is larger than the "viewport" area. Therefore, the easiest way to avoid scrollbars from appearing would be to either reduce the former or enlarge the latter. Other than that, one can "force" scrollbars to not appear even when they would be needed, by adding an overflow: hidden; to the style of the desired HTML element (I suppose that in this case, you're talking about the <body> one). Such a forceful removal can be done in the (embedded or separate) CSS used by the HTML, if any, e.g.:

Code: Select all

body
{
  overflow: hidden;
}

or directly in the HTML code itself, e.g.:

Code: Select all

<body style="margin: 0; overflow: hidden;">
  ...
  ...your <body> code here...
  ...
</body>

Take a look at this example:
https://www.w3schools.com/howto/howto_css_hide_scrollbars.asp

[tass_co]

I realized it after I wrote it. sorry

[Yincognito]

I realized it after I wrote it. sorry