Closed Bug 643383 Opened 15 years ago Closed 15 years ago

upload big file

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: hzhao, Unassigned)

Details

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; InfoPath.1; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Build Identifier: uncaught exception: [Exception... "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIDOMFile.getAsBinary]" nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" .............. Reproducible: Always Steps to Reproduce: 1. firefox 4.0 2. select one big file ( >200M ) 3. XMLHttpRequest().sendAsBinary
It looks like bug 604561 didn't fix all code paths ?
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
A minimal testcase would be great.
Bug 604561 made it so that instead of silently returning truncated data on out-of-memory the getAsBinary call would throw an exception. That's the exception listed in comment 0. If you can't allocate a single 400MB chunk of RAM, you can't getAsBinary a 200MB file. This is why you can send blobs directly, by the way; that way you don't have to round-trip them through a string. So this looks invalid to me. Everything is working the way it's supposed to. Once we switch to 64-bit builds, the problem will go away for files of a few hundred megs in size, of course.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.