Apache OpenOffice (AOO) Bugzilla – Issue 123744
Pictures in pasted WEB-site contents: only placeholders shown
Last modified: 2017-05-20 10:35:24 UTC
Steps how to reproduce Reproducible with "AOO 4.0.1 – German UI / German locale [Rev. 1524958 2013-09-20 11:40:29]" on German WIN7 Home Premium (64bit)", “historic” 4.0 User Profile used for all predecessor versions: 0. From AOO Start center open new HTML document 1. open <https://www.facebook.com/khessia.famor.96/friends> (does not matter, same for other similar pages, you might need Facebook account) 2. Select from "All Friends" first eight friends 3. <control+c> for Copy 4. Click into new HTML document 5. <control+v> for paste As expected contents becomes pasted Bug: Pictures stay as placeholders, no pictures will appear :-( Additional info: (a) Works fine with LibO 4.2 (b) with menu 'tools -> Options -> OO -> General - Update links = "Ask": does not ask (c) All the same with normal Writer documents (d) worked fine with server installation of "AOO 3.4.0 – German UI / German locale [AOO340m1(Build:9590) - Rev.1327774]" on German WIN7 Home Premium (64bit)", own separate user profile (e) if necessary I will narrow down appearance of problem. (f) not a general problem, I tried Wikipedia main page, pictures will be shown (g) but also other Facebook pictures, for example on same page 9 Thumbnail photos show the same problem.
As I have no facebook account I am not able to reproduce the described defect. Rainer: Can you save the created HTML document and attach it? The corresponding link information should survive the saving process. Thx in advance.
Created attachment 82321 [details] Sample Document > Can you save the created HTML document and attach it? @Oliver: Problem is not reproducible with saved HTML page, but I think I found an other way how to reproduce the problem with the document I created doing steps 1-5 of my original report: 11. Open attached "thisworksnot.odt" From AOO4.0.1 Start Center Bug: Instead of pictures only placeholders will be shown. :-( 12. Close document without changing changes 13. Open attached "thisworksnot.odt" From AOO3.4.0 Start Center As expected after few moments thumbnail pictures will appear :-( I am pretty sure the problem in step 13 is the same as in step 5 of original report.
Thx for sample document - I am taking over to have a deeper look.
(In reply to Rainer Bielefeld from comment #2) > Created attachment 82321 [details] > Sample Document > > [snip] > > 11. Open attached "thisworksnot.odt" From AOO4.0.1 Start Center > Bug: Instead of pictures only placeholders will be shown. :-( > 12. Close document without changing changes > 13. Open attached "thisworksnot.odt" From AOO3.4.0 Start Center > As expected after few moments thumbnail pictures will appear :-( > > I am pretty sure the problem in step 13 is the same as in step 5 of original > report. I can confirm this defect. I will take these reproduction steps to work further on this issue. I reproduced the defect also in AOO 4.0.0 --> adjusting fields "Version" and "L.C. on" Some further investigations: I switched to the OpenOffice Open-File-/Save-File-dialogs. When I open the URL of the first image directly in the Open-File dialog in AOO 3.4.1 I got a warning dialog regarding a certification mismatch (I am not sure, if this is a false-positive as Firefox is fine with the certification). Continuing the process opens the image in Draw. Cancelling the process nevertheless opens the image in Draw. This is a defect in AOO 3.4.1 from my point of view. Doing the same in AOO 4.0.0, AOO 4.0.1 or my current trunk build shows the same certification mismatch dialog. 'Continuing' opens the image in Draw. 'Cancelling' does not open the image and provides error message 'Error reading data from Internet. Server error message.' My first assumption is that we had fixed the above observed defect for AOO 4.0.0 and thus, such linked images are no longer loaded. Now, I will have some debugging sessions to find the root cause and hopefully an acceptable fix.
The certification mismatch warning is a not correct. The certification alternative names for valid domains is not correctly read - see method <handleCertificateValidationRequest_(..)>. The first entry in the alternative names is not considered. For the URL of the first image this alternative name is the needed wildcard one to match the domain of the image's name.
The wrong certificate mismatch warning is only one part of the root cause for this issue. Corresponding debugging sessions on current trunk and AOO 3.4.1 code line reveals that together with our update to serf 1.1.0 the defect is triggered. From observing the serf API calls and its results it reveals that since version 1.1.0 serf got it right regarding certificate validations. AOO 3.4.1 using serf 1.0.0 got the data stream of the linked images in spite of the the fact that the certificate was not validated automatically or manually. This is no longer the case in current trunk (which already uses serf 1.2.0, AOO 4.0.x are on serf 1.1.0).
Further investigation reveals that in the non-interactive case (e.g. loading of linked images in the background - as for the sample document or the original described copy-and-paste from a browser), the alternative domain names of the given certificate are not considered. Now, (as I hope) I have all pieces together to provide a fix for this issue.
"orw" committed SVN revision 1560062 into trunk: 123744: method <handleCertificateValidationRequest_(..)> - correct considerat...
"orw" committed SVN revision 1560071 into trunk: 123744: method <SerfSession::verifySerfCertificateChain(..)> - consider certi...
fixed in trunk for next release. @Rainer: Could you verify that the original reported defect is also fixed. Once a buildbot build containing my fix is available you could have a look. Thx in advance.
Shouldn't SerfTypes.hxx changes done in revision 1560071 also be applied to other headers and sources in same dir?
(In reply to Yuri Dario from comment #11) > Shouldn't SerfTypes.hxx changes done in revision 1560071 also be applied to > other headers and sources in same dir? Yes, such changes could be made to the other includes as well. There are not necessary, as we add the corresponding folders (.../apr/, .../apr-util/ and .../serf/) to the include path.
I'm building with the system serf, so headers cannot be in two different directories. So if path is /usr/include, <serf/serf.h> is correct but <serf.h> fails. The other way if include path is /usr/include/serf.
(In reply to Yuri Dario from comment #13) > I'm building with the system serf, so headers cannot be in two different > directories. > So if path is /usr/include, <serf/serf.h> is correct but <serf.h> fails. The > other way if include path is /usr/include/serf. I am sorry that I was not clear: .../apr/, .../apr-util/ and .../serf/ are added to the include path in case the system apr|apr-util|serf is _NOT_ used. Thus, go ahead to change the includes as for the case that the non-system ones are used it should not matter, if <serf/serf.h> or <serf.h> is included.
"ydario" committed SVN revision 1569046 into trunk: #i123744# use only one way to include serf headers.
I looked again at the header path issue for serf and apr. System headers on my linux system are in /usr/include/serf-1 /usr/include/apr-1.0 these paths are defined in APR_CFLAGS and SERF_CFLAGS by set_soenv.inv when system libs are in use, thus using <serf/serf.h> or <apr-util/apr_uri.h> should be breaking the build on unix systems. I wrote 'should' because I'm on OS/2 where my setup is similar (and I can't do a linux build). I propose to revert headers to old coding, without the directory name.
(In reply to Rainer Bielefeld from comment #2) > Created attachment 82321 [details] > Sample Document > > > Can you save the created HTML document and attach it? > > @Oliver: > Problem is not reproducible with saved HTML page, but I think I found an > other way how to reproduce the problem with the document I created doing > steps 1-5 of my original report: > > 11. Open attached "thisworksnot.odt" From AOO4.0.1 Start Center > Bug: Instead of pictures only placeholders will be shown. :-( > 12. Close document without changing changes > 13. Open attached "thisworksnot.odt" From AOO3.4.0 Start Center > As expected after few moments thumbnail pictures will appear :-( > > I am pretty sure the problem in step 13 is the same as in step 5 of original > report. the 11 issue still exists on Rev. 1573601
(In reply to zhaoshzh from comment #17) > > 11. Open attached "thisworksnot.odt" From AOO4.0.1 Start Center > > Bug: Instead of pictures only placeholders will be shown. :-( > the 11 issue still exists on Rev. 1573601 I use the same revision under Linux/Ubuntu. Can't reproduce the problem. Only with 4.0.1 Rev. 1524958. I can remember a similar but solved bug with https in OOo <3.3.