Everytime I try to navigate to a JS file on Firefox I get a save-as dialog. I would like to just be able to view the source in the actual browser and not have to download and open the file in another editor.
Is there any way I can force Firefox to view the files?
EDIT here's a snapshot:
In Firefox, You can use the view-source: psuedo protocol.
Enter into the URL address bar:
view-source:http://server/whatever/your/url/is.js
See also:
How can I convince IE to simply display application/json rather than offer to download it?
I would try the excellent Open in Browser add-on, which is worth having as part of your standard Firefox install.
Have you ever been annoyed when you wanted to see a document and the download popup appears which forces you to select an external application to view it?
This extension allows you to open the document directly in browser. You can also change the MIME type of a document being viewed.
This extension is necessary due to a 9 year old bug in Firefox. When given Content-disposition: attachment by the server, Firefox will only offer to open the resource with an external application or to save it to disk. "Open here, now, in this Firefox" should also be an option for MIME-Types it handles, but currently isn't.
I agree with the last comment, from just 8 days ago:
not allowing content types that Firefox can handle (text/plain, image/png,
etc) is to be viewed directly is a clear-out bug. Dancing through hoops like
saving the file to some random place then opening it manually is a ridiculous
workaround.
There are three places that Firefox looks for the MIME type of a .js file. (There is a fourth place for some files, such as .html files.)
The first is in a file in your profile called mimeTypes.rdf; if you have ever clicked on a link to a .js file with an unrecognised MIME type then when you save it Firefox will associate that MIME type with .js files. See Mozilla bug 332690 which describes the equivalent bug for .svg files.
The second possibility is that your registry entry HKEY_CLASSES_ROOT\.js\Content Type may have been set to an incompatible value. If present it should be set to one of the values application/x-javascript, application/javascript or text/javascript.
Only if these locations are not set then Firefox will use its internal default which I believe is application/x-javascript.
There is a nice JSView extension that should help you: https://addons.mozilla.org/en-US/firefox/addon/jsview/
If you view the source of a website in Firefox, you can navigate into the javascript files from there also by just clicking on the link in the src="" property.
(This could potentially be influenced by Firebug that I have installed)
Using the devtools it looks like this Ctrl+Shift+K > Debugger > Sources:
Related
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.
I have script that using selenium and firefox to automating download action.
The problem is whenever I run script I always get pop up from firefox keep asking what kinds of action I would like to do, even though I set download path in firefox preference. I checked files and folders to create master mimeTypes.rdf for all users, but I couldn't find mine.(I'm using ubuntu). I found ~/.mozilla/firefox but there was no file for directory of my profile name nor any file has an extension like .rdf
here is the criminal's pic that making me crazy
firefox download popup
below is what I've done to disable the popup.
profile = FirefoxProfile()
profile.set_preference("browser.download.panel.shown", False)
profile.set_preference("browser.helperApps.neverAsk.openFile", 'application/zip')
profile.set_preference("browser.helperApps.neverAsk.saveToDisk", 'application/zip')
profile.set_preference("browser.download.folderList", 2)
profile.set_preference("browser.download.dir", "/home/i-06/Downloads")
driver = webdriver.Firefox(firefox_profile=profile)
I have spent many hours trying to suppress that "save or open" pop-up that appears when downloading a file using the firefox driver with selenium (python 3.x). None of the many suggestions involving various values for profile.set_preference worked for me. Maybe I missed something.
Still, I finally got it working by the other method that is recommended : using an existing firefox profile.
You can tweak your default (or custom) profile to the file save behaviour you want. Type the following in the firefox address bar and make changes here :
about:preferences#applications
Then the only setting up you need to do to download the file into your current working directory is :
from selenium import webdriver
fp = webdriver.FirefoxProfile(<your firefox profile directory>)
fp.set_preference("browser.download.folderList",2)
fp.set_preference("browser.download.dir", os.getcwd())
driver = webdriver.Firefox(firefox_profile=fp)
If you have a typical ubuntu setup, you can find your default firefox profile dir by viewing ~/.mozilla/firefox/profile.ini
In that .ini file, look for Path under [Profile0]
I doubt you need to define both. Remove the below line from your code
profile.set_preference("browser.helperApps.neverAsk.openFile", 'application/zip')
Also sometime the MIME type of zip file can be different based on the server. It could be any of below
application/octet-stream
multipart/x-zip
application/zip
application/zip-compressed
application/x-zip-compressed
So in Network tab check what is the content type you are getting and add that to your profile to make sure the dialog doesn't come
I removed profile.set_preference("browser.helperApps.neverAsk.openFile", 'application/zip') as Tarun Lalwani suggest and it still work. But my problem was that I put application/mp4 instead of video/mp4. You could check MIME type here.
I'm creating a Javascript Windows 10 Universal app. It complained about using javascript inline with html-- due to having script tags inside my .html file.
"CSP14312: Resource violated directive 'script-src ms-appx: 'unsafe-eval'' in Host Defined Policy: inline script. Resource will be blocked."
So I did some research online and it turned out that I could avoid this error by doing two things:
Open package.appxmanifest:
add to start page:
StartPage="ms-appx-web:///index.html"
Add to package.appxmanifest:
<uap:ApplicationContentUriRules>
<uap:Rule Match="ms-appx-web:///" Type="include" WindowsRuntimeAccess="allowForWebOnly" /> </uap:ApplicationContentUriRules>
(You read this right: we need 3 slashes... ///)
Now this works great and my program is running now without the errors. But I noticed that if I change the start page via the GUI then it can't save it because it complains it's an illegal uri. So the only way I could do this was right-click the package.appxmanifest and choose "view code" and then do it through code. (Actually #2 above can only be done through code).
Maybe someone can clue me in, did I do something wrong? Here's a screenshot doing this through the GUI:
I saw a similar bug has been filed - when use the same uri format in manifest's Content URIs setting, same issue occurs. It's because the there is a rule checks whether the uri has a host. If the uri's host is null or empty, the uri validation fails.
Seems VS team is considering removing this rule, so I think it will be fixed in future release but I cannot say which update will have the fix.
I have a #JavaScript annotation in my application to load a .js file from the classpath.
Now I've made an update to the file and redeployed (locally), but I always get the old version back. I've tried reloading everything (ctrl+R, ctrl+F5) but that doesn't work and also I wouldn't want the users to have to do that.
A trick I used in the past (without Vaadin) was to append a request parameter with the version (e.g. ?version=1) and update that so that the URL changes. But apparently that isn't allowed for the #JavaScript annotation (Vaadin doesn't even try to load the file).
I have overcome this by utilizing the resourceCacheTime parameter of the Vaadin servlet configuration:
#VaadinServletConfiguration(ui = MyUI.class, resourceCacheTime = 0)
Although it has its limitation as described in my answer to another question here.
This is browser feature to localy cache JS files, nothing to do with Vaadin.
As you figure it out yourself: If you want to make sure users have latest version of JS file, you should rename JS file name to: script_buildNumber.js.
Use the Chrome's incognito feature (and not use it when visiting spicy/unpleasant websites).
Just open your browser in Incognito mode https://support.google.com/chrome/answer/95464?hl=en and the browser will cache nothing.
Other browsers have this feature as well (Opera, IE, Firefox, Safari).
As I noted in my comment on the question on January 12th, renaming the file worked. This seems to be currently the only way, although it's far from ideal.
Yeah I know this may be a duplicate, but all previous posts regarding this were for Chrome or Firefox .. I'm asking for Internet Explorer only, as that's the browser my client uses for the localhost web-app we're making for them ...
Basically I have a HTML file selection control in place ...
<input type="file" name="vestingFileBrowse" id="vestingFileBrowse"/>
... and I want to extract the full path of the file that has been selected.
Note that unlike Chrome, for Internet Explorer, the full path is displayed on the form once the user chooses a file .. So in theory, is it not possible to simply read the value of that text box control, to get the full path ?
Note that I cannot use jQuery, or any other 3rd party library, due to the project's requirements ..
Also, I cannot add the localhost site as a Trusted Site in Internet Explorer, due to requirements ... (Otherwise IE would've given the full path instead of C:\fakepath\...)