QWebView not loading Qt resource images - qt

I have a QGraphicsWebView to which I construct a page by appending tags. For example:
webElement.appendInside("<img src=<img src=\"qrc:/img/ioLlogoTopLeft.png\" />");
This happens in a secondary QThread. I also use resources to set styling in the same thread:
defaultBaseFrame->setStyleProperty("background-image", "url(qrc:/img/ioLGradientTop.png)");
Both of these lines were working fine, but in the last few builds they've stopped working, and I've no idea why. Instead of an image I now get an empty frame, and the background fails to appear. The resource paths seem fine, and work fine in other (non web-view) parts of the program.
On the other hand, when I replace an image URL with a location on the internet (an http:// url), the image loads normally.
Is there some quirk to using resources in a multithreaded environment (or was that just a red-herring?) Resource images were working before, and I can't think of anything relevant in the code that I've changed recently.

Solved it. And not a particularly satisfying solution; more just a quirk of Qt. It turns out the problem started when I removed the (I assumed) redundant initialisation of the WebView to a blank page:
webView->setHtml("<html><head></head><body></body></html>");
When I re-added it, images in resource files started working again. There didn't seem to be any other difference in functionality; all the other page elements render the same, just that one little quirk was fixed.
Recall that I'm building up the page from a blank DOM tree. I had falsely assumed that the above line was redundant because QWebView always inserts those boilerplate HTML tags automatically regardless, and almost everything works as it should either way.

Related

Links inside of a Xamarin.Forms/Xamarin.Android WebView won't work

I have a Xamarin.Forms app that opens locally saved HTML files which contain relative link to each other (think an old HTML offline docs) in a WebView. Everything functioned in Android 10, but now I needed to make a custom renderer in Xamarin.Android due to the new Android 11 changes needing AllowFileAccess (I have all accesses currently on for testing until I get this problem fixed) in the WebSettings. The WebView's OnElementChange sets all the Control's settings, sets the WebClient (which has a ShouldOverrideUrlLoading set to handle particular filetypes like PDF), and then loads the URL. The first page loads fine, but none of the links operate (this testing page has a few links to other HTML pages and some to PDFs). Click on the highlights them as normal, but nothing opens.
No breakpoints in the WebClient's ShouldOverride are hit and neither are any in the Android WebView's OnElementChanged when I click a link. The output window registers the touch, but doesn't do anything more. I feel like this is some kind of communication problem between Xamarin.Forms WebView and Xamarin.Android WebView (possibly even the Xamarin.Android's WebView not being up to date with Android's WebView), but I do not know where to look. Has anyone run into a similar situation and have a fix to get the links functioning again?
Thanks.
After much blood, sweat, and tears, mostly tears, I found the solution.
First off, WebView doesn't tell you directly, but anything that targets a new window (IE _blank and potentially others) will not hit your WebViewClient's ShouldOverrideUrlLoading method and instead hit your WebViewChromeClient's OnCreateWindow method. So you need to handle loading through that one as well as through your WebViewClient.
Second, links will not always work because of Safe Browsing in the WebView. Again, Google doesn't specifically say it can cause issues with urls, but it works against outside urls (which in a file is potentially every url). I had to turn it off, which you can find instructions at developer.android.com/guide/webapps/managing-webview, and I was able to navigate just fine. I feel you will want to set up safeguards to prevent people from abusing your app (like having a WebView that is for your stuff with Safe Browsing off and another for all others, or blocking any sites that aren't yours) since cybersecurity is always a thing.
Lastly, I found IFrames won't load properly if you manually load the page in the view passed to WebViewClient's ShouldOverrideUrlLoading. The sizing goes all off in my docs, which leads me to believe the elves in the background do something special if you return false and the WebView handles it. I found I needed to handle all my other cases (IE pdfs, images, etc) and then return false from ShouldOverrideUrlLoading if it is my iframe htmls.
As a note, because I had forgotten this having worked on Windows for so long, remember that Android's base file system is case sensitive, which makes links case sensitive. You need to either makes sure all your casing is correct in your files or have them on a FAT file system SD card if you want them to be insensitive.

Character on :before sometimes displays incorrectly…

I have a character applied to a :before that sometimes doesn't display correctly in Chrome. I can't quite work out the trigger, but I've found that opening the console and refreshing (while the console is still open) seems to get the character back again. However even after closing the console and coming back later it works fine - and then at some point later I'll notice that it's reverted back to this unusual character - but as I say I haven't noticed what triggers it, if anything. A standard refresh without interacting with the console doesn't resolve it.
How it's supposed to look:
How it sometimes looks:
As you can see the character is wrong in the console style preview, as well as on the rendered page (but the CSS is unchanged, and states: content '“' (that's a copy and paste with the actual character, by the way).
(I have tested the page in other browsers, and it looks fine, but as I don't know what triggers it I'm not sure that's relevant).
The only place I've ever seen an issue like this is with editing code directly in Bitbucket, on save many characters turn into these strange little glyphs. But that isn't the issue here.
I've double checked and I'm declaring the charset on all pages: <meta charset="utf-8" />
Any ideas?
EDIT
I've now seen this issue on two sites I'm working on locally - with very different codebases. The only commonalities are the fact that it's on a :before pseudo element and running in Chrome.
Try unicode content: '\201c';.

'</div' injected in Classic ASP html response, page continues to load

So, this is weird.
We have a 2008 R2 server and Win 7x64 dev workstations running Classic ASP.
One page in the site, at exactly carat position 98301, a </div is being inserted into the source. Notice it's not a fully closing div (</div>) tag. Just </div .
So, all sorts of things are breaking since it moves around, based on other things that modify the page (user permissions, querystring values, etc). But always exactly at position 98301 in the code. And always only on this one page.
I've never seen this before and have no idea where to figure out what's doing it. We have many other pages with hundreds of thousands of characters that are fine. We have shorter pages, too. All the IIS settings are the same for all pages and include a 4Mb response buffer and both static and dynamic compression enabled (which I togged both ways without change). We also have 3 source control branches and this is happening in them all, only on this one page.
We are using 2 Win7x64 dev workstations, 1 Win2008R2 local test server and 1 Win2008R2 prod server, and they all do exactly the same thing.
I've moved around the code some, cut out functions, added new code in there to loop Hello World, and no matter what I do, it always inserts just </div at exactly carat position 98301.
I can't think of anything else to test. All suggestions are welcome! Thank you!
Turns out it was the combination of htmlEncode() and htmlDecode() being on the page, and was only a problem in Chrome (currently v39.x). Firefox and IE worked fine. On our page we had about a 600 line script block, and htmlEncode() and htmlDecode() were close to the top of the block. By moving them to immediately before the </script> tag everything worked and </div was not being injected. While I was not the author of that page, I can see the htmlEncode() and htmlDecode() functions were sourced from here: HTML-encoding lost when attribute read from input field
Additionally, we have both Prototype (1.7.1) and jQuery (1.11.x) loaded, and jQuery loading as var $j = jQuery.noConflict(); before Prototype. Changing return $('<div/>').... to return $j('<div/>').... and even return jQuery('<div/>').... had absolutely no affect on the situation.
I still do not know WHY this was happening, but it has been resolved (for now, anyway) by moving the functions to the bottom of the script tag.

Making StyleSheet Render First?

I have a program that works fine on my development machine and on QA but it does not work properly on Stage.
The issue seems to be that Stage is a much slower box and it takes a long time for the web page to come up. When it does come up most of the various sections of the page look fine, but there is one section of code that comes up "raw"...but this I mean that the stylesheet has not been applied to it.
Is there a way to "force" this stylesheet to be applied to the page first?
Thanks

HTTP: pictures not fully received. how to avoid that, i.e. force browser to try again?

I have written a small picture script which shows a directory listing with thumbnails and also previews of the pictures.
Directory listing example
Image preview example
Source code
In some cases, when you click through several image previews (you can also use the arrow keys left/right to do that faster), some images don't fully load (and they are only shown partly then).
I think this has started to appear more often since I am preloading the next few pictures but it also has appeared before. This also occurs most often if you switch the images very fast.
I wonder why this appears and how I can avoid this. I guess that the browser somehow looses some connection to the server (or the server closes it unexpectedly for some reason). Thus I tried to work around this by setting Content-Length (and I was hoping that the browser would reconnect automatically if the file was not received fully) but that didn't helped.
Also, in the browser, a normal reload of the page doesn't help, I have to force a full reload.

Resources