I work for a media company in Norway, and on rare occasion we see that an image will fail to render in its entirety. When this happens, we can refresh the page and the image will still only partially render. We have only ever seen this happen on Safari, and I have been able to reproduce it both on desktop (Safari 13.1.2) and mobile (iOS 14.4.1).
In the network tab, the image seems to have been fully delivered. The amount of bytes transferred is the expected amount. In fact, if we increment the height of the container by 1px, the image will suddenly appear in full, with no network activity occurring. In other words, the browser did receive the full image, it just is not showing.
Everything in the styling looks totally normal, but we still assumed this was somehow related to the CSS. However, we created a local override, and we were still able to reproduce with the following code:
<figure class="desktopi-45000 mobilei-45000 tableti-45000">
<picture>
<img itemprop="image" data-defer="view" sizes="(max-width: 640px) 640px,(max-width: 1024px) 1024px,1240px" title="- Du hører ikke hjemme her!" alt="- Du hører ikke hjemme her!" class="" srcset="https://www.dagbladet.no/images/73594916.jpg?imageId=73594916&x=15.742793791574&y=14.099216710183&cropw=72.431633407243&croph=57.57180156658&width=760&height=342&compression=70 640w,https://www.dagbladet.no/images/73594916.jpg?imageId=73594916&x=15.742793791574&y=14.099216710183&cropw=72.431633407243&croph=57.57180156658&width=900&height=405&compression=80 1024w,https://www.dagbladet.no/images/73594916.jpg?imageId=73594916&x=15.742793791574&y=14.099216710183&cropw=72.431633407243&croph=57.57180156658&width=980&height=441&compression=80 1240w" src="https://www.dagbladet.no/images/73594916.jpg?imageId=73594916&x=15.742793791574&y=14.099216710183&cropw=72.431633407243&croph=57.57180156658&width=380&height=171">
</picture>
</figure>
Here is an image comparison of what we see when the issue occurs. Note that it can take many, many tries before the bug occurs.
While trying to figure this out, we came across a similar question. However, the answers provided fail to elaborate on the root cause of the problem. One of the answers says to use decoding="sync", and that does seem to resolve the problem (at the very least, we cannot reproduce with that added). However, that is not a viable solution due to the performance impact it has. Given the other sites are not experiencing this problem and do not use decoding="sync", there is something else going on. The question, therefore, is why is this happening? What is causing this, and what can be done to resolve it?
When testing locally, this could seem to be fixed by adding either
decoding="async"
or
decoding="sync"
to the image-tag. For some reason, Safari and browsers running on Apple-products seem to struggle with automatically choosing the best suitable way of decoding images to render.
The most upvoted answer on the question you've come across does actually clarify it a bit. But for a bit more explanation, there the actual Mozilla WebDeveloper explanation here, and according to the second answer, iOS has a bit of a soft-limit when it comes to loading things in, and lower priority things (like something loaded asynchronously) are given less memory. By using decoding="sync" on an <img> tag you are specifying that it should be loaded synchronously, things loaded synchronously tend to be of a higher priority and therefore have a bit more memory to work with. You could opt to lower the resolution of the image in order to not have to rely on synchronous loading to allow a higher memory usage when loading the images in. As far as I can tell, this is, in fact, a known iOS/MacOS issue, but I cannot find any mention of work being made towards it. So synchronous loading or differing image sources (with different resolutions) or possibly even some modern implementation of iframe-style tech (like what's used on JSPs, or any kind of nesting like what can be found in Angular) can serve as ways to alieviate this issue, but it seems like something that Apple will have to solve in order for it to undoubtedly cause problems.
I may be wrong about this, since I am not an Apple Technician, but innate browser issues cannot be solved through Web Programming alone. I apologize for putting all this in an answer, but comments have a bit of a character limit and links count towards it.
in the developer tools, I noticed that if you change something in css, the picture is displayed completely...
it became a solution for me: after the picture was uploaded, using js I added css which will not affect the image on the page like (z-index) or what ever, but thanks to this, the picture began to be fully displayed
Related
When developing and testing a websites responsiveness, is it wise to use chromes built in phone emulators to accurately do so?
I'm not sure what the issue is, but it could be one of these things.
Browser Cache
You may have made a change to that specific element in the past (fixed it) - but because of your browser's cache, it looks the same. Try clearing the cache on your device and see what happens.
Script Issues
There is a chance that the scripts you're using to make the arrow go up and down are a bit too much for the mobile device, and make it behave in a weird manner. Perhaps leaving it still on mobile or removing it all together would be the solution?
Edit: After looking through the errors on the website, it seems like you have quite a few errors and some critical warnings. If you patch these up, it might work on mobile.
If neither of these are a solution, let me know in the comments below.
The problem with your website seems to be a simple case of not loading CSS. Namely, you're trying to load /assets/css/app.css which appears to be missing (404).
Additionally, to fix the arrow's positioning, you'd need
#hero {
flex-direction: column;
}
After some changes to our site, we are seeing that when certain pages are loaded, the page quickly changes width. This occurs every time on webkit browsers Chrome and Safair, but only rarely on some other browsers.
I have not been able to produce the effect at all on Firefox on Windows, Firefox on Mac, nor IE9 and IE11. It seems to rarely occur on IE8 and IE10. I have not found a pattern yet that causes it to appear on IE8 and IE10.
To understand what might be causing this, it would be good to know if certain styling attributes take an initial value while the page is loading but them assume some other value by the time the page is fully loaded. This could explain what is happening.
I should add that this problem developed after some changes which "should" not have caused this issue. Basically having to do with adding URL rewriting to eliminate duplicate pages. Clearly some side effect is operative.
At the moment we only have the code on development servers, so it would not be that easy to actually see it right now, although that is the obvious first question from a responder. So at this point, the question is more "what generically causes pages to reformat under Webkit."
UPDATE: the problem seems to be traced to Google Translate. When I remove that from the page, the problem goes away. Put it back; problem comes back.
Oddly, it mostly impacts Chrome! IE10 and 11 are exempt, and with even earlier IE versions the problem is much less.
I can readily demonstrate the temporary widening of the page just by reloading the page.
I experimented with trying to put the div containing the translate div instead a container div and setting some attributes on that. So far I have not found something that mitigates the problem.
We have suppressed Google Translate recently because it started adding other junk to the bottom of the page. That other junk is gone but we will continue to suppress it due to this new jumpiness.
I believe there is some clever way to contain the issue, but have no more time for it.
I have confirmed that the issue is definitely caused by Google Translate being on the page.
I'm using haxe and openfl to create an html5 application. I tested the app in multiple browsers and devices, all work fine except in Chrome on iOS 7 only. The images used are not appearing seemingly randomly. Every time I re load different images appear and others disappear with exception to a couple that are always there. Here is what I tried:
I tried setting the z-index on the canvas that is used for one of the missing images, as well as a bigger width and height.
I know that the images are being loaded, I used Charles to take a look. There are no errors in the console log and changing the time and place where the images are being added to the display list in haxe changes nothing.
I swapped out one of the images that are always there for an image that is never there and it still didn't load.
The file names had a couple dashes and spaces in them so I changed that as well with no effect.
It's a very strange problem that I can't seem to diagnose. nor can I really find anyone with a similar problem.
The main issue is the fact that I can't see what haxe is building that might be causing this issue.
This is hard to answer without code samples. My advise is to look at what's different about the pictures that stay versus the ones that don't, both in how you're coding and the pictures themselves. I've had problems with images displaying correctly on ios only to find the problem was embedded somewhere in the metadata of an image. Hope this helps.
This is a very weird thing that i've experienced . I've been working on a project lately www.bandness.com, which allows music groups and bands to upload their music. The artistic department has been very keen and precise and they've done an incredible work that allows the bands to have gorgeous profiles .
However, when on Chrome (i've noticed this only happens in chrome), when you enter a profile the background image doesn't load properly until you scroll over it or you "select" the div layer or the ones on top of it.
here are some examples of what i'm talking about
you need to select the layer so it works properly, and that is bugging annoying!!
here you have another example
and this is how the website should be seen without the bug in the left screen
Why does this happen?
The website is www.bandness.com, click on any of the groups where it says "TOP 5 GROUPS" or on the group for each song in "TOP 5 SONGS" and you'll probably spot what I'm talking about.
This has happened to me in chrome, on a macbook pro with the latest OS release. As well as in Windows 8. It bugs me because I have NO idea what is causing this and I fear a chrome bug.
How could it be fixed? Any suggestions are appreciated, I thought of using jQuery to make the layer dissappear/appear or something like that... but i'm unsure of whether this will work.
Ok, so I'm posting this as a help for anyone that suffers the same consequences of this bug at any time.Bear in mind the answer implies using jQuery.
As Christopher kindly pointed out earlier, I tried to do $(SELECTOR).hide().show(), but that didn't make it.
Then I decided to try with $(SELECTOR).hide(100,function(){$(SELECTOR).show()}); ensuring that the effect of showing only happens once the div layer has dissapeared.(that way it actually appears and dissappears).
The solution worked, however this should not be needed and it doesn't provide an answer to why this is happening, but it "kinda" makes the trick .
$(SELECTOR).fadeOut(100,function(){ $(SELECTOR).fadeIn()}); makes this happen in a much fancier way. Again as I said this isn't a fix, it's just a workaround that might get you somewhere if you ever suffer this problem!
In our current project, we have one particular page where, when viewed in IE7 or IE8, fonts seem .1 or .2 em larger than they should be. Having inspected the code and css, I cannot see where this is coming from. This issue affects ONLY ONE PAGE which is to all intents and purposes exactly the same as many others in the site, which display as expected.
Some things I have ruled out:
Text-size settings (it's not that, set to medium, and anyway if so why one page only)
DPI settings (same reason as above)
Browser zooming (it's set to 100% - the problem scales with the zoom setting, btw)
Browser-specific CSS (no browser specific rules are applied to the elements in question)
Stray font-size setting code in the markup (I've been through and eliminated this)
Voodoo (okay I haven't ruled this out - as my frustration increases I'm starting to think it might be this though)
The page displays as expected in Firefox. This is not a live site yet so unfortunately I can't point you at the URL.
Has anyone come across something similar and, if so, what was it?
Many thanks,
G
Without showing us or replicating it at least, asking is pretty much near useless but I suspect it's probably just a tag that wasn't closed on an element with an above average font size.
I'd recommend validating the HTML. If it's good, then it's hard to say without looking at the code/page.