I have used VSC with LiveServer for some years with only 1 problem, back a few years ago when either LiveServer or Windows10 had an update installed, next time I opened my HTML file in LiveServer, the HTML was rendered in a "basic" layout, and did not include my CSS Styles.
On an Internet search I found a solution for either this site or similar where I needed to add a line of code to either LS or Windows, sorry but I cant remember which. And all was well again until, now. The very same problem has returned, and no matter how much I search, I cant fine the solution.
There are plenty where there were errors in HTML or CSS, but this is occurring on files which haven't changed, and on new ones from the same master I use for my new pages. The screenshot included shows the HTML, LS as basic HTML and how the page loads on the browser directly. I am using Chrome, but have tried on Firefox with same results.
How LS displays and how it should be
You need to open your VS Code project from a directory that contains your HTML and CSS.
Your HTML document is in the root directory of your project (hence the URL being /filename) but you are trying to load CSS from ../../css/filename.
The project needs to be two directories higher for the webserver to include that path.
I have a manifest.json according to the MDN spec and while it works correctly when browsing the website from a mobile device (add to homescreen popup shows up, theme color and icons load...etc) Chrome Dev Tools is unable to parse it. The same problem persists on Lighthouse (chrome extension).
Has anyone seen a similar issue? I would think that the JSON is invalid however copy-pasting into Web App Validator it is marked correct, but when inputting the URL it giving a parse error:
File isn't valid JSON: SyntaxError: Unexpected token in JSON at position 0
It is probably a BOM character issue in the manifest.json file.
If you have Notepad++ on your machine, try open the file, click menu "Encoding" -> "Encode in UTF8 without BOM" and then save the file.
If you don't have Notepad++, search Google for "Remove BOM character" for your favorite IDE/editor.
I changed some permissions on my server and somehow broke TinyMCE so that it can no longer browse for images and files.
I changed the permissions back to what they were but the issue still persists - when I go to browse for files I am just presented with a blank screen:
Would anyone know how to repair this?
(PS using ModX Evo CMS)
EDIT: what I see on console on the edit resource page (nothing appears when I open the console on the browsing window):
6
Refused to set unsafe header "Connection" index.php:1
Uncaught Error: IndexSizeError: DOM Exception 1 /assets/plugins/tinymce/jscripts/tiny_mce/tiny_mce.js:1
2
Refused to set unsafe header "Connection" index.php:1
Thanks!
In case you do use standard installation of tinymce i suggest you reinstall tinymce over the files on the server.
Try checking all the file names for anything that might contain special character. A em dash, n dash, possibly left quote ”, right quote etc...
I would do this via ftp to make sure you can see all the files in admin section. Rename any of the files that might have questionable characters and see if that fixes it.
So I started developing my firefox addon.
Most of the work is performed by a referenced javascript file.
Problem is that when I edit some of the html elements on the page and say, set their text it's written as pure giberish. I am writing the text in hebrew. Can't for the life of me figure the reason.
Any ideas?
Javascript strings are already Unicode at runtime. However, you have to make sure that your files are encoded correctly.
Always use utf-8 (without BOM) file encoding for all your js, XUL, DTD, properties files to be sure.
Firefox might try to guess the file character set incorrectly otherwise, and even worse some stuff might not even try guessing the encoding and instead simply always assume utf-8.
Better yet, do not hard-code strings in js/xul, but use DTD/properties files for localization (XUL tutorial, XUL School).
This, e.g. snippet works pretty well for me (on this very page):
document.getElementsByTagName("h1")[0].textContent="русский язык";
(Just fire up the Firefox Web Console)
"Inline" hewbrew embedded in js files might create additional problems because it is right-to-left and bidi sucks, so the localization approach should be preferred.
I have a web app where the user needs to upload a .zip file. On the server-side, I am checking the mime type of the uploaded file, to make sure it is application/x-zip-compressed or application/zip.
This worked fine for me on Firefox and IE. However, when a coworker tested it, it failed for him on Firefox (sent mime type was something like "application/octet-stream") but worked on Internet Explorer. Our setups seem to be identical: IE8, FF 3.5.1 with all add-ons disabled, Windows XP SP3, WinRAR installed as native .zip file handler (not sure if that's relevant).
So my question is: How does the browser determine what mime type to send?
Please note: I know that the mime type is sent by the browser and, therefore, unreliable. I am just checking it as a convenience--mainly to give a more friendly error message than the ones you get by trying to open a non-zip file as a zip file, and to avoid loading the (presumably heavy) zip file libraries.
Chrome
Chrome (version 38 as of writing) has 3 ways to determine the MIME type and does so in a certain order. The snippet below is from file src/net/base/mime_util.cc, method MimeUtil::GetMimeTypeFromExtensionHelper.
// We implement the same algorithm as Mozilla for mapping a file extension to
// a mime type. That is, we first check a hard-coded list (that cannot be
// overridden), and then if not found there, we defer to the system registry.
// Finally, we scan a secondary hard-coded list to catch types that we can
// deduce but that we also want to allow the OS to override.
The hard-coded lists come a bit earlier in the file: https://cs.chromium.org/chromium/src/net/base/mime_util.cc?l=170 (kPrimaryMappings and kSecondaryMappings).
An example: when uploading a CSV file from a Windows system with Microsoft Excel installed, Chrome will report this as application/vnd.ms-excel. This is because .csv is not specified in the first hard-coded list, so the browser falls back to the system registry. HKEY_CLASSES_ROOT\.csv has a value named Content Type that is set to application/vnd.ms-excel.
Internet Explorer
Again using the same example, the browser will report application/vnd.ms-excel. I think it's reasonable to assume Internet Explorer (version 11 as of writing) uses the registry. Possibly it also makes use of a hard-coded list like Chrome and Firefox, but its closed source nature makes it hard to verify.
Firefox
As indicated in the Chrome code, Firefox (version 32 as of writing) works in a similar way. Snippet from file uriloader\exthandler\nsExternalHelperAppService.cpp, method nsExternalHelperAppService::GetTypeFromExtension
// OK. We want to try the following sources of mimetype information, in this order:
// 1. defaultMimeEntries array
// 2. User-set preferences (managed by the handler service)
// 3. OS-provided information
// 4. our "extras" array
// 5. Information from plugins
// 6. The "ext-to-type-mapping" category
The hard-coded lists come earlier in the file, somewhere near line 441. You're looking for defaultMimeEntries and extraMimeEntries.
With my current profile, the browser will report text/csv because there's an entry for it in mimeTypes.rdf (item 2 in the list above). With a fresh profile, which does not have this entry, the browser will report application/vnd.ms-excel (item 3 in the list).
Summary
The hard-coded lists in the browsers are pretty limited. Often, the MIME type sent by the browser will be the one reported by the OS. And this is exactly why, as stated in the question, the MIME type reported by the browser is unreliable.
Kip, I spent some time reading RFCs, MSDN and MDN. Here is what I could understand. When a browser encounters a file for upload, it looks at the first buffer of data it receives and then runs a test on it. These tests try to determine if the file is a known mime type or not, and if known mime type it will simply further test it for which known mime type and take action accordingly. I think IE tries to do this first rather than just determining the file type from extension. This page explains this for IE http://msdn.microsoft.com/en-us/library/ms775147%28v=vs.85%29.aspx. For firefox, what I could understand was that it tries to read file info from filesystem or directory entry and then determines the file type. Here is a link for FF https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIFile. I would still like to have more authoritative info on this.
This is probably OS and possibly browser dependent, but on Windows, the MIME type for a given file extension can be found by looking in the registry under HKCR:
For example:
HKEY_CLASSES_ROOT.zip
- ContentType
To go from MIME to file extension, you can look at the keys under
HKEY_CLASSES_ROOT\Mime\Database\Content Type
To get the default extension for a particular MIME type.
While this is not an answer to your question, it does solve the problem you are trying to solve. YMMV.
As you wrote, mime type is not reliable as each browser has its way of determining it. However, browsers send the original name (including extension) of the file. So the best way to deal with the problem is to inspect extension of the file instead of the MIME type.
If you still need the mime type, you can use your own apache's mime.types to determine it server-side.
I agree with johndodo, there are so many variables that make mime types that are sent from browsers unreliable. I would exclude the subtypes that are received and just focus on the type like 'application'. if your app is php based, you can easily do this by using the function explode().
in addition, just check the file extension to make sure it is .zip or any other compression you are looking for!
According to rfc1867 - Form-based file upload in HTML:
Each part should be labelled with an appropriate content-type if the
media type is known (e.g., inferred from the file extension or
operating system typing information) or as application/octet-stream.
So my understanding is, application/octet-stream is kind of like a blanket catch-all identifier if the type cannot be inferred.