http://bugs.winehq.org/show_bug.cgi?id=29249
Bug #: 29249 Summary: iexplore fails to load ftp.adobe.com Product: Wine Version: 1.3.34 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: wininet AssignedTo: wine-bugs@winehq.org ReportedBy: RandomAccountName@mail.com Classification: Unclassified
Created attachment 37819 --> http://bugs.winehq.org/attachment.cgi?id=37819 Terminal output (builtin iexplore)
Running "wine iexplore ftp.adobe.com" gives only a blank page. Workaround: winetricks wininet
It doesn't work in IE8, either: it only shows "Internet Explorer cannot display the webpage" unless I use WINEDLLOVERRIDES=wininet=n.
http://bugs.winehq.org/show_bug.cgi?id=29249
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
http://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #1 from Ken Sharp kennybobs@o2.co.uk 2011-12-11 06:49:10 CST --- Does it work if you run "wine iexplore ftp://ftp.adobe.com"? You might need to escape the ://
http://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #2 from A Wine user RandomAccountName@mail.com 2011-12-11 07:28:19 CST --- (In reply to comment #1)
Does it work if you run "wine iexplore ftp://ftp.adobe.com"? You might need to escape the ://
Nope, it's still a blank page.
Well actually, ftp://ftp.adobe.com does work in 0.9.33, but it's a blank page in 0.9.43 and newer. Meanwhile, ftp.adobe.com still shows a blank page in 0.9.33. So it's a separate bug, I guess?
http://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #3 from A Wine user RandomAccountName@mail.com 2011-12-11 07:45:47 CST --- On second thought, maybe not. Builtin iexplore and IE8 both correctly redirect ftp.adobe.com to ftp://ftp.adobe.com right now, at least according to the content of the address bar, but then fail to display it.
I'll try to bisect the failure with ftp://ftp.adobe.com, but it may take a while, as I haven't compiled such old versions in some time and didn't keep very good notes on what's necessary to do so. (whoops)
http://bugs.winehq.org/show_bug.cgi?id=29249
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |jacek@codeweavers.com Regression SHA1| |76de315e736f95bed56c954a5f5 | |829fbfade328d
--- Comment #4 from A Wine user RandomAccountName@mail.com 2011-12-13 05:10:19 CST --- Well, the result of regression testing with builtin iexplore is:
76de315e736f95bed56c954a5f5829fbfade328d is the first bad commit commit 76de315e736f95bed56c954a5f5829fbfade328d Author: Jacek Caban jacek@codeweavers.com Date: Fri Jun 8 00:27:07 2007 +0200
mshtml: Switch to Wine Gecko 0.1.0.
:040000 040000 67026661252a9a5358117ad5fa69bc952cb59d0d 2d14f0be45f08ed7b91a49af7f3668f714779d2a M dlls
Checking out this commit gives a blank page, while the one before it works.
Is it still likely to be a wininet bug anyway? If not, I guess the problem in IE8 must be unrelated (this commit couldn't cause a regression for native mshtml).
http://bugs.winehq.org/show_bug.cgi?id=29249
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #5 from Bruno Jesus 00cpxxx@gmail.com 2011-12-13 18:20:30 CST --- Isn't it because some callbacks are not implemented yet? For example 40 (receiving response) and 41 (response received).
+urlmon show lots of: warn:urlmon:internet_status_callback Unhandled Internet status callback 40 warn:urlmon:internet_status_callback Unhandled Internet status callback 41
http://bugs.winehq.org/show_bug.cgi?id=29249
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |frederic.delanoy@gmail.com Ever Confirmed|0 |1
--- Comment #6 from Frédéric Delanoy frederic.delanoy@gmail.com 2012-02-14 09:02:00 CST --- Confirmed in 1.4-rc3
http://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #7 from Ken Sharp kennybobs@o2.co.uk 2012-09-10 19:47:34 CDT --- Still present in wine-1.5.12-194-g688aa1f
http://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #8 from Frédéric Delanoy frederic.delanoy@gmail.com 2013-05-28 09:38:59 CDT --- Still in 1.5.31
fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} fixme:ole:CoResumeClassObjects stub fixme:storage:create_storagefile Storage share mode not implemented. fixme:urlmon:URLMoniker_BindToObject use running object table
http://bugs.winehq.org/show_bug.cgi?id=29249
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kennybobs@o2.co.uk
--- Comment #9 from Ken Sharp kennybobs@o2.co.uk 2013-07-12 14:37:47 CDT --- In wine-1.6-rc4-122-g104adb7 and IE8 (working around Bug 25648) it completely ignores both ftp.adobe.com and ftp://ftp.adobe.com and loads the homepage. Very odd behaviour. Native wininet makes no difference. I guess this is a new problem.
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #10 from Jerome Leclanche adys.wh@gmail.com --- Still in wine-1.7.11
http://bugs.winehq.org/show_bug.cgi?id=29249
hanska2@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hanska2@luukku.com
--- Comment #11 from hanska2@luukku.com --- Still an issue, installing wininet solved this.
wine 1.7.22
https://bugs.winehq.org/show_bug.cgi?id=29249
Yuan Chen huddsinyuan2014@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |huddsinyuan2014@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #12 from Yuan Chen huddsinyuan2014@gmail.com --- Still in wine-1.7.32-45-g77e061f
I run WINEDEBUG=+wininet,+urlmon wine iexplore ftp.adobe.com and get this:
trace:wininet:FTP_SendCommandA 6: ("/") 27 trace:wininet:FTP_SendCommandA Sending (RETR /) len(8)
trace:wininet:INTERNET_GetNextLine :24 550 Failed to open file.
https://bugs.winehq.org/show_bug.cgi?id=29249
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #13 from super_man@post.com --- still an issue 1.7.50
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #14 from Frédéric Delanoy frederic.delanoy@gmail.com --- Still in wine-1.9.18-121-g4e9cc30
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #15 from Bruno Jesus 00cpxxx@gmail.com --- AFAICS the problem is that wininet thinks every URL points to a file and then tries to download it [1] using FtpOpenFileW.
http://source.winehq.org/source/dlls/wininet/internet.c#3477 :
case INTERNET_SCHEME_FTP: client = FTP_Connect(hIC, host, urlComponents.nPort, user, pass, dwFlags, dwContext, INET_OPENURL); if(client == NULL) break; client1 = FtpOpenFileW(client, path, GENERIC_READ, dwFlags, dwContext); if(client1 == NULL) { InternetCloseHandle(client); break; } break;
The file in this case is "/" which means to retrieve the root folder listing for the FTP.
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #16 from Bruno Jesus 00cpxxx@gmail.com --- It may sound strange but maybe wininet should make the HTML for the listing automatically, that seems to be why native solves the problem.
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #17 from Jacek Caban jacek@codeweavers.com --- I'm pretty sure wininet doesn't compose HTML listing itself. I'd suggest to test it with Wireshark or similar tool and see what's the difference between native and builtin wininet. That should give a precise hint what's wrong.
Also note that in this case, we control all the stack from MSHTML down to wininet. wininet is called directly by urlmon. It may be that the problem is outside wininet, but if you say that it works with native, then wininet is indeed most likely to be the problem.
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #18 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Jacek Caban from comment #17)
I'm pretty sure wininet doesn't compose HTML listing itself. I'd suggest to test it with Wireshark or similar tool and see what's the difference between native and builtin wininet. That should give a precise hint what's wrong.
The difference is that after login wine sends RETR / resulting in invalid file and native sends CWD /, TYPE A, PASV, LIST and then somehow we end up with a file listing in iexplore screen.
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #19 from Jacek Caban jacek@codeweavers.com --- I found that it's even documented [1]. I tested it a bit and it seems like wininet should indeed create HTML out of file listing.
[1] https://msdn.microsoft.com/pl-pl/library/windows/desktop/aa385103(v=vs.85).a...
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #20 from Bruno Jesus 00cpxxx@gmail.com --- Sounds fun =) As a good Brazilian I never read manuals or remarks so I would never find that.
Will you try do implement it?
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #21 from Jacek Caban jacek@codeweavers.com --- I don't have plans to work on this myself anytime soon.
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #22 from Ken Sharp imwellcushtymelike@gmail.com --- Still present in Wine 3.0-rc3 and Staging 2.21, except in both cases closing iexplore doesn't actually kill the process and it remains in memory.
https://bugs.winehq.org/show_bug.cgi?id=29249
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #23 from joaopa jeremielapuree@yahoo.fr --- Unfortunately, bug is still there in current wine(3.21)
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #24 from Ken Sharp imwellcushtymelike@gmail.com --- No change in Wine 4.18 from Comment 22.
https://bugs.winehq.org/show_bug.cgi?id=29249
--- Comment #25 from A Wine user awineuser@mail.com --- Still doesn't load in wine-6.13-114-ga5f787ac445.
https://bugs.winehq.org/show_bug.cgi?id=29249
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
-
wine-bugs＠winehq.org -
WineHQ Bugzilla