I'm building a series of web pages. Some have images on them. I need to update the images and view the result. BUT in the moment Chrome takes the images from some kind of cache or other mechanism. I did a test and created some html with the image. Here's the original image:
<p class="Regular"><img class="img-responsive" max-width="40%" height="auto"
src="/jpg/image30.jpg" ><br/><br/>
That image is old. I uploaded (via WinSCP) a new image30.jpg, but the old one continues to display. I went to what I think the Chrome cache in
C:\Users\username\AppData\Local\Google\Chrome\User Data\Default\Cache
And deleted all files except for data_1, _2, etc.
I went into Chrome's settings and deleted browsing data.
If I change the image name in the Html to some other name, even one which doesn't exist, an image does display, usually an older one.
This also happens with Firefox and Opera.
You can press CTRL + F5 to reload the page without cache. Under google chrome develop tool, we have an option to disable the cache:
Related
I have a slideshow PWA made with Gatsby. Here's the repo (actually a light, unbranded version of the real thing). I've also hosted the build on Netlify.
Steps to repro :
Open the Netlify install, preferably with an iPad.
Add PWA to home screen
Open PWA via the home screen icon ; don't touch anything after it's open
Go to ioPad settings and disable WiFi/Internet
Return to the app and browse the slides
Notice that slide images aren't loaded (we see only the black background)
The images will load fine while connected to the WiFi. Also if you open the slides before turning off the WiFi, they will cache and remain available even if the app is closed and then reopened.
Desired behavior :
That as soon as the app is open, all the images contained in the slides be cached and ready to use without having opened the slides. This app is meant to be used in an environment where WiFi won't be available. I don't want to have to ask the people to open all the slides one by one to make sure the images are cached before usage.
What has been tried :
Generating all the images once :
// src/pages/index.js, line 156 :
<div id="offline">
{data.slides.edges.map((s) => {
return s.node.frontmatter.gallery.map((i, key) => <img src={i} alt="" key={"cache-"+key} />)
})}
</div>
The rationale was that by generating them once, they would immediately be cached and work offline.
Put the header Cache-Control: public, max-age=31536000 ; it was said to create an "agressive" cache policy...
Use for each single slide image.
Tried both the normal <img src="..." /> tags and the gatsby-image <Img fluid="..." /> tag, in the hopes that maybe the latter would come with its own cache policy override.
Searched the documentation for gatsby-plugin-offline and gatsby-plugin-manifest ; I don't feel I'm missing anything there.
The "real" app is about 45MB big, so it's tight but I feel it should be able to cache properly on an iPad. I don't know what I'm missing ; it seems to me like the number one advantage of a PWA is its ability to (reasonably) work offline. What more can I do to make sure the images are cached without having to open all the slides (there's quite a lot on the real app) ?
Thanks so much !
An answer came to me from a stranger on Reddit where I posted the same question.
In my gatsby-config, I had the following options set up :
{
resolve: gatsby-plugin-offline,
options: {
globPatterns: ['**/*.{js,jpg,png,html,css}']
}
},
But apparently I needed to put the globPatterns inside a workboxConfig object :
{
resolve: `gatsby-plugin-offline`,
options: {
workboxConfig: {
globPatterns: ['**/*.{js,jpg,png,html,css}'],
},
}
},
Can't believe I spent nearly 3 days going back and forth on the whole app and the server configs.
Thanks to anyone who took some time to think about my problem even a little !
Im using CKeditor version 4.5.8 in 'inline' mode (so directly in the content with the 'contenteditable' html attribute). This all works fine, except for one thing. I've added the 'Image upload' plugin, to add support for uploading an image while it's drag/dropped in the editor. This all works pretty good, except for one thing I can't get to work:
when dropping the image in the editor there should be a 'uploading' progressbar (tested in Chrome and in Firefox). But instead I almost directly see the message 'Upload complete'. But, at that time the upload is not completed (I've added a debugger breakpoint I my code to assure this is the case) and the 'success' response is not yet received (I see it as 'Pending' in the developer tools 'Network Tab'.).
However, when I 'throttle' the connection via Chrome dev tools, I do see a progressbar, however it's not showing the upload progress, but a 'Internal progress' of the browser of somekind? See screenshot:
Any ideas how to fix this?
The progress CKEditor 4 provide is taken from the XHR2 progress event. Note that it may not work properly on the localhost when the upload works immediately. Also I see your images are taken from cache ("from cache" in the 5th column in the Network Debugger). Try to disable cache and check does it helps.
Additionally I see your arrows next to data:image/jpeg. CKEditor, before uploading images, loads them locally as BASE 64 data to show user the preview. Then these images are uploaded and the source of the image is replaced. These data is not a real network data, it is the content JavaScript loaded locally.
Why images not showing when I paste from MS Word.
Ckeditor show that source
<h1><img src="file:///C:\Users\user\AppData\Local\Temp\msohtmlclip1\01\clip_image002.jpg" style="height:88px; width:1005px" /></h1>
This file exist.
Ckeditor version is for AspNet.
Tested on Chrome, IE 10 and IE 11
Your CKEditor is presumably running on a web page, with a http:// address.
Modern browsers don't support embedding images (or anything else) from file:// URLs in http:// pages (or https://, or any other protocol) for security reasons.
This is because there'd be the danger of a malicious site embedding something from your private files (like a document), and then using some security hole to read and upload it elsewhere.
But even if this worked, it wouldn't do you much good: the image isn't uploaded into CKEditor so the image would show up on your computer only. Anyone else watching the page you're editing would see a broken image link.
As far as I know, there's currently no way around uploading the image separately.
I am creating a pdf document (via ColdFusion), but when I preview the rendered pdf in Firefox, I get the number "4" where my checkmarks are supposed to be (see photo below). When I preview the exact same pdf in Chrome or IE, I see the checkmark, and it all works perfectly!
I am pre-populating the pdf form fields (via ColdFusion session variables), and then rendering the pdf using the following markup:
<cfpdfform source="82040.pdf" action="populate">
<cfpdfformparam name="org" value="">
</cfpdfform>
Here is the resulting pdf form in Internet Explorer:
Note how the checkmark is rendered properly:
Here is the same form previewed in FireFox:
Note how the the checkbox has a "4" instead of a checkmark:
Any help would be greatly appreciated!
It is a bug with Firefox's PDF Viewer. Currently, there is no fix. As radiovisual's post points out, the bug in the underlying library (pdf.js) was supposedly fixed. However, there is still the issue of Mozilla updating the older version baked into Firefox (which is what most folks are using). Currently, that bug is still outstanding.
Probably the best you can do is to return the pdf as an "attachment", rather than "inline", so the browser prompts them to "open/save" the file. If the user opts to "open" the pdf, it should open with their default program instead. (Adobe Reader is the default for most users).
<cfheader name="Content-Disposition" value="attachment; filename=fileName.pdf">
<cfcontent type="application/pdf" .../>
Update:
This bug was apparently addressed already, as pointed out via the project's github repo: the bug was supposedly fixed during this commit. So if you are still experiencing problems, it either means:
You are using an outdated version of the pdf.js library,
Or, the problem has been re-introduced into the library.
So to start things off, you will want to make sure that you are using the most up-to-date version of the pdf.js library. If you are still experiencing problems, even with the most up-to-date version, then the problem is still within the embedded pdf document viewer, and there aren't too many things you can do to fix this until the project maintainer's finally fix the problem.
The issue you are experiencing (the reason why you are seeing a "4" where there should be a checkmark, is because the pdf.js library is using a special symbol font to render the checkmarks, but in problematic versions of firefox's embedded pdf-viewer the symbol font isn't rendering the checkmark correctly, so it shows a "4" instead of a checkmark -- because the checkmark symbol they are using in the custom font just so happens to be mapped to the number "4".
Similarly, for the same reasons cited above, if you assign the checkbox to render squares (instead of checks), the letter "N" will appear in the checkbox instead of a square, because the square shape symbol is mapped to the letter "N".
This problem only exists in the embedded pdf document viewer in Firefox but will look perfectly normal when viewed in Adobe Acrobat Reader, or other offline pdf readers (and other browser pdf readers, which is why it looks fine in Chrome and IE), so when users download the form, it will appear like you would expect it to.
Some workarounds / optimizations you could try:
Try one of these, or all of these, they are in no particular order (or guaranteed to work)
Don't rely on the built-in pdf.js browser extension in firefox, instead, make your own updated version based on the latest pdf.js source or target another pdf library and use it's browser-agnostic API to render and display your pdfs.
Create an HTML form for the user to fill and verify all the information, then render the pdf based on the data supplied by the HTML form, for download only (no previewing in the browser). This will force them to open the pdf in their default pdf viewer where the issue is not present, because, again, the problem you describe only happens in Firefox's embedded pdf viewer and not in other pdf viewers like Adobe Acrobat).
Make sure you have the ZapfDingBats Font installed on your server. I haven't confirmed this, but that commit that was supposed to have solved this issue seems to have added support for this font, so it is worth a try to make sure this font is accessible on your ColdFusion server, then try previewing the rendered pdf in Firefox.
Detect that the user is accessing your form via Firefox, and if so, warn the users of the issue, but assure them that downloading the form and viewing in their default pdf viewer will work as expected.
Convert the page to HTML5 (if you aren't already), then add in an HTML5 shiv (so HTML5 features can be used on older browsers), and a CSS normalizer, and test if the problem persists using these optimal settings. It's worth a shot to make sure that the problem is somehow treated differently under the HTML5 standard, since not everyone is having the same issues as you.
Lastly, make sure that your HTML is being rendered as valid markup via your ColdFusion output by using an HTML validator.
Other than that, there isn't a whole lot you can do until the mozilla team updates their embedded pdf viewer. But since the problem is only in the firefox viewer, and not in the pdf itself, it it up to you to decide if this is a deal-breaker or not, and search for alternatives.
Note: PDF.js is built into version 19+ of Firefox.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Update: You can use this pdf (which represents the character mapping of the ZapDingbats symbol font) as a way of testing your browser's interpretation of embedded fonts in the pdf rendered via pdf.js. Note that at the time of this writing, the above pdf does not display the Zapf Dingbats properly in Firefox (via pdf.js), but other browsers render them just fine (notice the "4" next to a20[x2714] in firefox, and the checkmark next to the same entry (a20[x2714]) in Chrome.
I have an old program that shows an embedded browser using the HTML Rendering library from Carbon. I am migrating it from codewarrior to Xcode, using the 10.4 SDK. While the HTML is displayed correctly, including links, the images just don't show up. I can see the alt content, and dimensions are properly set with the width and height fields.
I am doing the initialization with:
OSErr err = HRNewReference(m_HRRef, kHRRendererHTML32Type,
GetWindowPort((WindowRef) m_pWindow));
And then I open my local HTML file with:
err = HRGoToFSRef(m_HRRef, &f, false, false);
My images are also stored locally but just do not appear, it was working fine previously on my ppc-only codewarrior compilation.
I tried with web pages on Internet with HRGoToURL, and I tried replacing my pictures src fields with http:// or file:// links to images, in jpg, gif and png, always with the same result.
Are you aware of any issue like this? I know I could, and probably should, migrate to WebKit but that would me more involved.
Sylvain
This is a shot in the dark (I am completely unfamiliar with HTMLRenderingLib), but it reminds me of this. Maybe here too it doesn't load images, even local ones, asynchronously; have you tried letting the run loop loop (whichever way is most appropriate to your app: WaitNextEvent, return back to the main runloop, spin a sub event loop, …) and see if the images load?