I have the following:
HTML
<input id="files" name="files" type="file" multiple="multiple" />
<button id='subButton' type='submit'>Upload (0) files</button>
Javascript
$("#files").change(function(evt) {
debugger;
$("#subButton").text("Upload (" + evt.target.files.length + ") files");
});
You can see it in action in this Fiddle. If I select 1,700 files, the code works fine and the correct number of files is returned by evt.target.files.length. However, if I select all the files in my directory (2279 -- total size of 210MB), then evt.target.files.length returns a 0.
Is there some sort of ambiguous file limit with the File API?
In my web.config I have: maxRequestLength="700000" which should handle the given size of the files. However, this seems to be a client rather than a server side issue to me in that nothing is being submitted to the server.
Any ideas?
This is not a limit of the HTML5 File API but of the browser implementation or operating system.
Testing Firefox on Windows Vista, for example, there seemed to be effectively no limit to the number of files I could select (I tested up to 10,000). On Chrome, it appeared to return 3758 of the selected files.
The difference is that Firefox is using the new IFileOpenDialog interface which returns the selected files as an enumeration, but Chrome seems to be using the old GetOpenFileName API, which relies on a fixed size buffer. If the buffer isn't big enough, it's supposed to return an error, but on Vista it just returns truncated and slightly corrupted data.
Interestingly, from the number of files returned by Chrome, and the knowledge of the filenames I was testing with, I can make a fairly good guess that the buffer size being used is probably 32768.
I'm guessing you're using Windows 7 or 8 and the GetOpenFileName API has been fixed to the extent that it now returns an error if you exceed the buffer size. So when you select too many files, the browser doesn't attempt to process the truncated data, and just returns 0.
The exact limit will be based on the length of the filenames and the path of the directory containing those files.
Other operating systems will obviously not have these same limits, but could have their own problems depending on the design of their file selection APIs.
Related
This question is about executing javascript AND HTML in the command line.
**** very important : this is NOT about scrapping. It's about "rendering" or executing the javascript contained in a private .html (not web accessible) and save the result in a new .html with the javascript executed result
CONTEXT : I have private .html (those .html have css, javascript, etc) but "unrendered"... if I see what I mean.
WHAT I WANT TO ACCOMPLISH : in a automated php script => I create a raw (unexecuted) .html => cli with the .html => execute javascript => save the result in a new .html
I TRIED : google-chrome headless -> it can save as PNG or PDF, but unable to save it as .html :(
OTHER ISSUE with google-chrome headless : the option --dump-dom saves the original .html not the executed one...
example
google-chrome
--headless --hide-scrollbars --run-all-compositor-stages-before-draw
--virtual-time-budget=10000 --disable-translate --disable-popup-blocking
--disable-infobars --ignore-certificate-errors --autoplay-policy=no-user-gesture-required
--disable-gpu --dump-dom
"someHTML_with_CSS_AND_JAVASCRIPT.html" > final.html
Other command line solutions like CutyCapt, wkhtmltopdf, etc have the same problem : only save in pdf or jpg or png, I want to save in .html
A web page after post-render can be stored generally in 4 other formats apart from the pre-render html/css/js components
The first two are the more familiar screen rendered image (PNG is best) or encapsulated vectors (PDF is the best and simplest)
The other two are different html format but not always built the same way. This century Firefox has problems (23 year old bug) with saving the post rendered web format but it is more native to Edge (preceded as I.E) & Chrome/ium variants.
One is to encapsulate the render and media in a html5X.zip file as used by zip.ePub3 the other is as a single mhtml(x)/.mht and the easiest way is to right click save as web page. "MHTML was proposed as an open standard, then circulated in a revised edition in 1999"
As described in the bug report, there are extensions for both FireFox and Chrome
One of web extensions that already make this possible is called "Save Page WE". It has been actively maintained. Users can save a complete webpage or selected items. Further, users can save one or more selected webpages (i.e. selected browser tabs). Information bar at top of each saved HTML file is supported as well and can be enabled among settings. Web Extension is available for Firefox - link and Chrome - link.
So saving this page as html
the top left svg Stack Overflow logo will start off as
Content-Transfer-Encoding: quoted-printable
Content-Location: https://cdn.sstatic.net/Img/unified/sprites.svg?v=fcc0ea44ba27
<svg width=3D"189" height=3D"530" fill=3D"none" xmlns=3D"http://www.w3.org/=
2000/svg"><path d=3D"M48 280.8v7.6l8.5 7.6L73 281.2V273l-16.5 14.9-8.5-7.1z=
M22 324v3l4 4 7-6v-4l-7 6" fill=3D"#5EBA7D"/><path d=3D"M8 280.8v7.6l8.6 7.=
6L33 281.2V273l-16.4 14.9" fill=3D"#C9CBCF"/><path d=3D"M45 191h29l-14.4-15=
" fill=3D"#F48024"/><path d=3D"M5 191h29l-14.5-15" fill=3D"#C9CBCF"/><path =
d=3D"M59.6 243L74 228H45l14.6 15zM6.5 322.5L0 329h13" fill=3D"#F48024"/><pa=
th d=3D"M7.5 386.5L0 380v13l7.5-6.5zm47.5 87l-8-6.5v13l8-6.5zm-48.5 0L14 48=
0v-13l-7.5 6.5zm20-84L33 383H20M6.5 341.5L0 348h13M19.5 243L34 228H5M19.5 1=
20l2.9 9.2H32l-7.7 5.6 3 9.2-7.8-5.7-7.8 5.7 3-9.2-7.7-5.6h9.6" fill=3D"#C9=
The old switch for mhtml saving is --save-page-as-mhtml and was proposed several times for --headless removal !
However I could NOT get that to work in Edge. There are open issues where it does not work as expected https://bugs.chromium.org/p/chromium/issues/detail?id=624045&q=save-page-as-mhtml&can=2 thus have to suggest you need a manual emulation. e.g. using a puppeteer.
Personally for small one offs I use sendkeys from Windows.
In Edge (Chrome?) keyboard scripting can save the current file,
TRY it with this page
CTRLSALTTDownDownUpEnterEnter
#CherryDT pointed me to "chromium"
chromium --headless --dump-dom "raw.html" > "rendered.html"
it does What I needed ;)
I am trying to download encrypted pictures and decrypt them using RNcryptor within a Javascript web application and place them within the html of my app. Everything works perfectly except for when pictures are larger in size and cause the call stack to be exceeded.
This error does not occur when to and from devices such as the Iphone, but when I try to send them to the web app, I get this error from the Iphone 6+ but no other device
This is my function used to convert a byte array to base64 string:
function encode(data)
{
var str = String.fromCharCode.apply(null,data);
return btoa(str).replace(/.{76}(?=.)/g,'$&\n');
}
Is there a more call stack efficient way to convert the data? I am willing to sacrifice speed if necessary.
The reason this is happening on only the Iphone 6 (and I assume it is mainly with pitcures made using its camera) is because the file you are sending is to large. This error probably would not occur with an older model Iphone such as the 5 or the 4 because of the picture quality.
The way that I would fix this is in your app where the picture is originally being encoded and placed on the database, I would resize it before doing so.
I have a 2D barcode generator making some barcodes on the (Java) backend. It gives me data URLs and I set them on the client side using Javascript. All works fine in Chrome, Firefox. But not in IE8 (of course!) although half of the images work and half don't work.
My images are a couple hundred bytes (so much less then 32kb)
Here is an example not working in IE8:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAAAAADFHGIkAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAEnRFWHRTb2Z0d2FyZQBCYXJjb2RlNEryjnYuAAAAgklEQVR42nVRixKAMAjy/3+a2hBwdVtdD1RELFxOXS6+9v1+F/+ICFs5jpGqsQWSosy3MQbVGSEDC7q4FaQrRiJDepJ1iG2sATggaqkeCc3VqicDDu6omgk1VdmS4W3Uq4sr4hE8llSYKe7GXsTxTPdZTdlyLQA4xrKQOit+Ryv7nwfFATbY5mERHQAAAABJRU5ErkJg
Here is an example working in IE8:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAFMAAABTCAAAAADG2WTcAAAACXBIWXMAACZzAAAmcwHzbHUKAAAAEnRFWHRTb2Z0d2FyZQBCYXJjb2RlNEryjnYuAAABAklEQVR42u2ZwQ7AIAhD+f+f3nbwMGwBl3hYg1xM5ngmUBE3u/abCTHtMTZcS4N3O0z3dNiYg+eeickZ02LMVzRcPJ0DD77zPsw5CQv6BGaYIwkmxo6+/V7S2CKHGShvYaNDmngN+T0TfGk9Y/E0DL4YkxVsWCQsSGGOOjPhHaNVfM5W2YMpMCFu2A3QQyHb722ZkQAT+dLzVJEJvqz4hYqc1H2Y4XHgU0WPCmzFxJhMjrTO00K3uDd7MXm8SSdKc1fej/7LLGTK+8yvPW0jZrGZ15sQXWbUGCTXOXIoiDGLLx3RUN1lOjOzCp5MkzZUmlkIM9JnGs9ezF2mxuz8r2e33b2PHKlEJ4PKAAAAAElFTkSuQmCC
Here is a fiddle. JS fiddle doesn't work so good in IE8 so use this link to view the result directly.
If you got an idea about the cause of this problem please share :)
For some reason the failing base64 decoded .png is invalid. If you download the image and re-save it the filesize is different.
I see 237 bytes for the original verses 409 for a re-saved copy.
This can be confirmed with the pngcheck tool.
Z:\pngcheck-2.3.0>pngcheck.exe original.png
original.png EOF while reading CRC value
ERROR: original.png
Z:\pngcheck-2.3.0>pngcheck.exe re-saved.png
OK: re-saved.png (24x24, 32-bit RGB+alpha, non-interlaced, 82.2%).
Using the following valid re-saved.png base64 encoded data fixes the problem in IE8.
background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAAABJ0RVh0U29mdHdhcmUAQmFyY29kZTRK8o52LgAAAPlJREFUSEu1VdESwyAM6v7/o7vpqYcEova6vnRmNSRA9HP/nuufTwMorwL06rvm5MQI0n9X1FZAialCOD6+wY09kYqdgE15dpJx9QjGHYfukCJFBbbOHeLa/Wc1QDDFv6OW4xPAqZCuCKkBU6XcEqprjurfSoe5TRlFmVVDoRkAWzOztLP40IDtpShjlznX2TlALhFATbeb5kcuYhGzM4vnJsxBRoPiWek0dc9UZMcAT26oFmw7ClVcq7F3+rCdrQacwFGVHRvsvLpebXD+lsngwrL3wVI0uHB2DBE6UMezGkI11dtn0Yo2dcko90kN1FA9jQ0A9veb6y86oobBWhxQUgAAAABJRU5ErkJggg==);
I assume Chrome and Firefox are more lenient with the CRC.
As part of a loading screen for an offline-enabled web application I'm building (using a cache manifest), I'd like to display an accurate progress bar that lets users know which files has thus far been downloaded and which are still pending. Something like the following:
Loading...
/assets/images/logo.png: loaded
/assets/images/splashImage.png: pending
I know that I can use the cache "pending" event, but I don't see that the event arguments have any data associated with them.
Is there any way to do this?
There is a progress event that gets triggered when each file downloads, however its payload does not include the file name in any browser that I've tested with (Chrome, Safari, FF beta). Chrome displays the file name in the Console (though as far as I know it's inaccessible to JS), but neither Safari nor FF even go that far. And from what I've seen, the files do not download in the same order that they're listed in the manifest, so there's not even a way to generate an ordered list then knock them off one at a time.
So in answer to your question, no, there isn't any way to do this right now. It's possible that in the future the progress event will include the filename - at least in some browsers - but right now this isn't possible.
I should add that in Chrome (not in Safari or FF) you can at least get a count of files to be downloaded, allowing you to at least calculate an accurate progress bar. To get this in Chrome you'd use the following:
function downloadProgress(e) {
totalfiles = Number(e.total);
}
window.applicationCache.addEventListener("progress", downloadProgress, false);
However this will error out in other browsers, so you need to wrap a try/catch or some other method (typeof(e.total)) to avoid the error.
This is a few years late, but maybe it'll help someone else who's researching this.
It doesn't list the files or anything, but it shows an accurate(ish) progress bar based on the total number of files loaded. It may still need a little work...
https://github.com/joelabeyta/app-cache-percent-bar
We recently started using SVN Keywords to automatically append the current revision number to all our <script src="..."> includes (so it looks like this: <script language="javascript" src="some/javascript.js?v=$Revision: 1234 $"> </script>). This way each time we push a new copy of the code to production, user caches won't cause users to still be using old script revisions.
It works great, except for IE6. For some reason, IE6 sporadically acts as though some of those files didn't exist. We may get weird error statements like "Unterminated String Literal on line 1234," but if you try to attach a debugger process to it, it won't halt on this line (if you say "Yes" to the debugger prompt, nothing happens, and page execution continues). A log entry for it shows up in IIS logs, indicating the user is definitely receiving the file (status code 200, with the appropriate amount of bytes transferred).
It also only seems to happen when the pages are served over https, not over standard http. To further compound things, it doesn't necessarily happen all the time; you might refresh a page 5 times and everything works, then you might refresh it 20 more times and it fails every time. For most users it seems to always work or else to always fail. It is even unpredictable when you have multiple users in a corporate environment whose security and cache settings are forcibly identical.
Any thoughts or suggestions would be greatly appreciated, this has been driving me crazy for weeks.
Check your log with fiddler2 to make sure the browser request the page, and do not use the cache instead. Also check the URL of the JS script and the header returned.
Are you using GZip? There has been issues reported with it.
I would suggest testing using Internet Explorer Application Compatibility VPC Image. That way, you can do your tests with a 100% IE6, and not one of those plugin that claims to simulate IE6 inside another browser.
I think this is a very clever idea. However, I think the issue could be related to the spaces in the url. Technically, the url should have the spaces encoded.
See if you can customize the keywords in SVN to generate a revision number without special characters.