confirmed on Ubuntu 64/LibreOffice 4.1.1.2

Created attachment 86097 [details]
bt at random

On pc Debian x86-64 with master sources updated today, I confirm this.
I attached console logs and a bt at random

Michael: any idea who could take a look to this one? (bt+console logs attached)

No idea - sorry; it's a nice bug report for sure; patches appreciated. I guess there is some web link to an image:

http://<somewhere>/bmi/www.e-teatr.pl/pl/zdjecia/dramatopisarze/obcy/ameryka/%28150x0%29kushner_tony.jpg

And that connecting there is timing out / not working at all in whatever way and that this is the fundamental problem here.

I imagine that clobbering that stack trace to queue an asynchronous load of that:

#26 0x00007f2ad79bd7e2 in SfxMedium::GetMedium_Impl (this=0x7fff52186210) at /home/julien/compile-libreoffice/libo/sfx2/source/doc/docfile.cxx:2360
#27 0x00007f2ad79b46dc in SfxMedium::GetInStream (this=0x7fff52186210) at /home/julien/compile-libreoffice/libo/sfx2/source/doc/docfile.cxx:548
#28 0x00007f2ad79bdf91 in SfxMedium::DownLoad (this=0x7fff52186210, aLink=...) at /home/julien/compile-libreoffice/libo/sfx2/source/doc/docfile.cxx:2441
#29 0x00007f2ab8fc29a0 in ImpLoadLinkedGraphic (aFileName="http://1.1.1.1/bmi/www.e-teatr.pl/pl/zdjecia/dramatopisarze/obcy/ameryka/%28150x0%29kushner_tony.jpg", 
    aFilterName="JPEG - Joint Photographic Experts Group") at /home/julien/compile-libreoffice/libo/svx/source/svdraw/svdograf.cxx:110
#30 0x00007f2ab8fc5013 in SdrGrafObj::ImpUpdateGraphicLink (this=0x2cfb070, bAsynchron=false) at /home/julien/compile-libreoffice/libo/svx/source/svdraw/svdograf.cxx:736
#31 0x00007f2ab8fc4884 in SdrGrafObj::ForceSwapIn (this=0x2cfb070) at /home/julien/compile-libreoffice/libo/svx/source/svdraw/svdograf.cxx:611
#32 0x00007f2ab76fa3cf in SvxMSDffManager::ImportGraphic (this=0x2cfb810, rSt=..., rSet=..., rObjData=...)
    at /home/julien/compile-libreoffice/libo/filter/source/msfilter/msdffimp.cxx:3932
#33 0x00007f2ab76fc020 in SvxMSDffManager::ImportShape (this=0x2cfb810, rHd=..., rSt=..., pClientData=0x7fff52187c00, rClientRect=Rectangle = {...}, 
    rGlobalChildRect=Rectangle = {...}, nCalledByGroup=0, pShapeId=0x0) at /home/julien/compile-libreoffice/libo/filter/source/msfilter/msdffimp.cxx:4229
#34 0x00007f2ab76fa7b3 in SvxMSDffManager::ImportObj (this=0x2cfb810, rSt=..., pClientData=0x7fff52187c00, rClientRect=Rectangle = {...}, rGlobalChildRect=Rectangle = {...}, 
    nCalledByGroup=0, pShapeId=0x0) at /home/julien/compile-libreoffice/libo/filter/source/msfilter/msdffimp.cxx:3955
#35 0x00007f2ab7704a54 in SvxMSDffManager::GetShape (this=0x2cfb810, nId=1026, rpShape=@0x7fff52187cf8: 0x0, rData=...)
    at /home/julien/compile-libreoffice/libo/filter/source/msfilter/msdffimp.cxx:6105
#36 0x00007f2aa61cf9c0 in SwWW8ImplReader::Read_GrafLayer (this=0x2caece0, nGrafAnchorCp=262) at /home/julien/compile-libreoffice/libo/sw/source/filter/ww8/ww8graf.cxx:2448

Rather than having the 'Download' phase in the import is the right thing to do.

tested under Win7x64 with a 5 years old laptop and it took just 2 minutes to load document under LO 4.3.2.2
what's your current performance?

tommy27: I still can't open the file after several minutes on pc Debian x86-64 with 4.3.2 LO Debian package

Master sources updated yesterday show this:
warn:unotools.misc:2789:1:unotools/source/misc/mediadescriptor.cxx:736: caught Exception "" while opening <http://1.1.1.1/bmi/www.e-teatr.pl/pl/zdjecia/dramatopisarze/obcy/ameryka/%28150x0%29kushner_tony.jpg>

it takes 1 minute and 50 seconds to open in

Version: 5.0.1.2
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: es-ES (es_ES)

on Windows 7 (64-bit)

any Linux user can retest with LibO 5.x ?

With LO Debian package 5.0.1.2, I stopped to wait after 3 minutes. (i5, 6GB with just Iceweasel, Icedove and some console opened)

Looks similar to bug 90700.
The couple of path I have ready for  bug 90700 seem to cure this as well.

In LO 5.1.0 this bug should be fixed.

Please see bug 90700, comment 13 for a way to adjust http(s) protocol timeouts.

Time to open: around 25 seconds
Version: 5.4.0.0.alpha0+
Build ID: 33f5bc54aaa7fe7aa9335726e30f9c349155e04d
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-12-01_23:21:05
Locale: nl-NL (nl_NL); Calc: CL

I can no longer reproduce it in

Version: 6.2.0.0.alpha0+
Build ID: 4c6e11886a9d396bf7be18e9e3209a73c6e303ad
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

nor in

Version: 6.0.4.2
Build ID: 1:6.0.4~rc2-0ubuntu0.16.04.1
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

Closing as RESOLVED WORKSFORME

@Julien Nabet, Could you please doublecheck?

With LO Debian package 6.0.5, I don't reproduce this indeed but it seems there's a image at the beginning which doesn't display.

Idem with master sources updated today.
I noticed this kind of log:
warn:ucb.ucp.webdav:5053:5131:ucb/source/ucp/webdav-neon/NeonSession.cxx:1816: Neon returned NE_ERROR, http response status code was: 0 'Server certificate verification failed: issuer is not trusted'

Anyway, the initial pb is no more there.

(In reply to Julien Nabet from comment #16)
> With LO Debian package 6.0.5, I don't reproduce this indeed but it seems
> there's a image at the beginning which doesn't display.
> 
> Idem with master sources updated today.
> I noticed this kind of log:
> warn:ucb.ucp.webdav:5053:5131:ucb/source/ucp/webdav-neon/NeonSession.cxx:
> 1816: Neon returned NE_ERROR, http response status code was: 0 'Server
> certificate verification failed: issuer is not trusted'
> 
> Anyway, the initial pb is no more there.

Same behaviour on MSO 2010...