Bug 129216 – Files being uploaded are always represented to a destination site as huge-sized(originally posted in Midori Launchpad, Windows)

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[InAndOutLand]

Created attachment 224982 [details]
Google Mail, Yandex Mail, Mail-Ru cases of a wrong uploaded file size report 

Original bug: https://bugs.launchpad.net/midori/+bug/1234542
(this has been worded slightly differently)

When you try to upload some tiny files to a post-office site, the post-office interface says that these files are NNNN GigaBytes long. So, most of such systems do not accept my files at all, some of them try to upload files to a file hosting. Technically, the upload process itself may work OK in some cases (at least, once I was lucky to upload 50 MBytes video to VK.com - because VK runs a very robust user interface, which usually works in all possible cases)... But, as I alredy said, the uploading file size is reported totally wrong.

Steps to reproduce:

1) Upload a file
2) Observe the results

Actual results:
Website reports that file sizes are HUGE, and doesn't upload.

Expected results:
The website should report that files are normal-sized and upload normally.

Happens only on Windows.

[InAndOutLand]

Created attachment 225291 [details]
Six sreenshots, showing libsoup-tracing process

fernitoid (d-postbox) on Midori Launchpad(https://launchpad.net/midori) wrote this: 

Well, at least I tried to make soup tracing.

I attach here a *.zip with cmd console & Midori screen shots - made right during some of those hundreds milliseconds when the engines seemed to output in the log most intensively.

I must notice that command line console in "headers" debug mode flows pretty fast when Midori browses through the Web 2.0 - and I see no evident way to process the entire sheet, just because it does not fit into the console window. I can only say that I have not visually noticed any sign of critical malfunction there.
Nevertheless, there are some ЕГГОГs indicated in the very beginning of Midori's start-up process - they are clearly visible on the first shot.

[Sergio Villar Senin]

I couldn't reproduce this issue. I uploaded several files to GMail (some Kb, hundreds of Kb, and a few Mb) and all of them are properly recognized.

Could you please add some extra information like the versions of libsoup, midori and webkitgtk you are using?

[InAndOutLand]

fernitoid (d-postbox) on Midori Launchpad wrote this:
...
(I use: Midori 0.5.5 (En-UK), win7 (Ru, genuine); Intel x64 triple-core 3 GHz; 4 Gbyte RAM; ATI video.

Here is what Midori says about my desktop computer system in its about:version...
{
Version numbers in brackets show the version used at runtime.

Command line F:\Program Files 2 (x86)\Midori\bin\midori.exe
Midori 0.5.5 ((null))
GTK+ 3.6.2 (3.6.2)	Glib 2.34.3 (2.34.3)
WebKitGTK+ 1.10.1 (1.10.1)	libSoup 2.40.2
cairo 1.10.2 (1.10.2)	libnotify No
gcr No	granite No
single instance Sockets
Platform Windows NT 6.1
Identification Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.6 (KHTML, like Gecko) Chrome/18.0.1025.133 Safari/537.6 Midori/0.5
Video Formats H264 [x] Ogg Theora [x] WebM [x]

Netscape Plugins:

Google Update	Google Update
Java Deployment Toolkit 7.0.400.43	NPRuntime Script Plug-in Library for Java(TM) Deploy
Windows Activation Technologies	Windows Activation Technologies Plugin for Mozilla
Shockwave Flash	Shockwave Flash 11.8 r800
Java(TM) Platform SE 7 U40	Next Generation Java Plug-in 10.40.2 for Mozilla browsers
Unity Player	Unity Player 3.5.5f3
Silverlight Plug-In	5.1.20513.0
}
)
PS: also happens in Midori 0.5.7, recommend using a real version of Windows instead of using WINE.

[Sergio Villar Senin]

(In reply to comment #3)

> PS: also happens in Midori 0.5.7, recommend using a real version of Windows instead of using WINE.

Oh in Windows, ok that's why I wasn't able to reproduce it. Might be a libsoup issue then as we have some windows specific code there.

[InAndOutLand]

Well http://midori-browser.org/contribute/#testing said
"For testing your changes unfortuantely a real system is needed because Midori and WebKitGTK+ don't work properly under Wine. Even if it works some problems are not visible when using Wine, but are present when running under a real Windows system and vice versa.

One way around it is to virtualize Windows on a Linux host and mount your MinGW directories as a network drive or shared folder."
So yeah.....
Windows System Builders discs are only about $99 dollars, the price of a mid-range phone. http://www.amazon.com/Windows-8-1-System-Builder-64-Bit/dp/B00F3ZN2W0/ref=sr_1_2?ie=UTF8&qid=1395075275&sr=8-2&keywords=Windows

[bug]

Confirming bug on Windows 7 x64.

I don't think Sergio was trying to use Wine in the first place, for what it's worth...

[Michael Catanzaro]

Obsoleting this bug, since WebKitGTK+ doesn't run on Windows at all anymore.