Issue 19510

What is the file format ? 

Please Attach the documents which make this problem, so we can test
it.  (Without the documents, we cannot confirm the problem easily)
Don't forget to cut other part of the documents, so the file size is
small, but we still able to see the problem.

back to reporter

Created attachment 12913 [details]
This is a file that causes this error on Win2k

I have found that by disabling the IE viewer, you can get open office 1.1.1 to 
open files off a https webserver.

If you have open office installed on your windows xp machine follow the steps 
below:

Steps
1- Close open office.
2- Go to start,control panel
3- Add remove programs
4- Chose to modify open office install
5- Under optional components, disable the ActiveX control (right click the 
blue arrow to get a red X)
6- Click modify to continue, finish the rest of the prompts. 
6- Try opening a doc that you could not open previously.

This worked for me, which proves to me that it is the IE activex viewer that 
is causing the issue. I assume the install could be changed to fix this.

Jerry

Well - it seems the Win32 OO.o install can't handle 'https' URIs itself - I
presume it wants IE to download the file itself and then execute the app with
that. Quite how we tell IE. that a control can or cannot handle various types of
URI is not clear to me; having a dig.

So - isolating this in the code doesn't really help; the dialog is thrown up by:

extensions/source/activex/SOActiveX.cpp (OnDrawAdvanced):
LoadURLToFrame failing with the https URI and doing:
OutputError_Impl( mOffWin, STG_E_ABNORMALAPIEXIT )

The only way I could see to make it fail nicely was to poke at
IPersistPropertyBag impl. to return E_FAIL or somesuch with an https:// URI -
but that makes IE extremely confused so ... I guess we just have ship this
component turned off.

*** Issue 27705 has been marked as a duplicate of this issue. ***

*** Issue 21503 has been marked as a duplicate of this issue. ***

The problem could be fixed in two ways, either by letting the office support
https protocol or by letting IE download the file for the ActiveX control. The
first one is not planned for OOo2.0.

Created attachment 19546 [details]
It is a monthly newsletter, but it happens everytime I take it from my email.

"An API call exited abnormally" - I've had this problem with OOo long time. 
Currently I have 1.9.79 version installed and if I try to open .XLS-file into 
browser, I get this message everytime. 

The same problem arises in our intrnet site. whenever i clicked the hyperlink, 
the document is not opening, and giving the API error. What is the reason 
behind this error.

Changing the target and sending the task to myself for fixing.

The fix is ready, but integration to OOo2.0 seems to be too risky. The fix
introduces a new thread into ActiveX control implementation, that changes hardly
the timing of the control execution. Usual testing shows that the fixed control
implementation works pretty well, but an intensive testing is required. There is
no resources to do such a testing for OOo2.0, so I change the target.

moving my temporary fix-description (as long as the proper fix is not applied
yet) from 32988 over to here:

Alright, here is a possible fix in step-by-step manner:
> 1- Close open office.
> 2- Go to start,control panel
> 3- Add remove programs
> 4- Chose to modify open office install
> 5- Under optional components, disable the ActiveX control
> (right click the
> blue arrow to get a red X)
> 6- Click modify to continue, finish the rest of the prompts.
> 7- Try opening a doc that you could not open previously. 

cyb->mav: As progress seems already to be made, I set this issue to started.

*** Issue 32988 has been marked as a duplicate of this issue. ***

*** Issue 20049 has been marked as a duplicate of this issue. ***

*** Issue 32489 has been marked as a duplicate of this issue. ***

*** Issue 49176 has been marked as a duplicate of this issue. ***

In #i49716# it not only happens when opening up in IE but also in MS Office 
(Excel, Word) 2000.

Fixed.

Please verify the issue.
Please remember that OOo2.0 itself has no support for "https:" protocol, thus
"edit document" button will not work for "https:" URLs, since the staroffice is
not able to edit the original documen. Although the button must work for all
other supported protocols.

re-open issue and reassign to ul@openoffice.org

reassign to ul@openoffice.org

reset resolution to FIXED

ok in fwk20

One thing that is unclear to me, as I am trying to verify whether this bug is
fixed or not in the ooo-build of OOo 2.0.2, is this: If the ActiveX control is
installed, is OOo supposed to open not as a separate application, but inside the
IE browser when viewing a .doc, .sxw etc document in IE? Is there some setting
somewhere in OOo 2.0.2 that one needs to toggle for this to work? Should just
installing OOo with the ActiveX control included enable it?

Is this bug supposed to be fixed in oob680-m1 or not? I do get the "An API call
exited abnormally" when opening a .sxw document from a https: URL in IE, with
OOo built from oob680-m1. However, opening a .doc document (ditto from a https:
URL) in IE starts OOo as a separate application. Is that what is supposed to
happen, or is it supposed to open embedded in the IE browser window? Should I
file another issue about that?

It seems that the code in
setup_native/source/win32/customactions/regactivex/regactivex.cxx only calls the
DllRegisterServerNative function in so_activex.dll which registers OOo's own
("native") file types (extensions and MIME types). It doesn't call
DllRegisterServerDoc from so_activex.dll which would register the MS Office file
types. Is this on purpose? Or is DllRegisterServerDoc called from somewhere else?

Hi tml, this is on purpose.

Regards

loading via https works fine with 2.0.2

I'm sorry but I still can't get OOo documents from an https website to load
properly inside IE in OOo 2.0.2. At least our users are fine with OOo documents
opening in an external application, so I'm disabling the ActiveX control for now
in my builds.

I can verify that opening an .odt document from at least one https: website I
happen to know (the innerweb.novell.com site) through IE still doesn't work with
the Windows en-GB 2.0.2 build available from www.openoffice.org.

What happens is that soffice.exe (and soffice.bin) are started, but just a grey
page shows up in IE, and IE in fact hangs until one kills soffice.exe (and
soffice.bin)

IE first asks "this page contains both secure and nonsecure items. Do you want
to display the nonsecure items?" (I don't know why it asks this, what the
nonsecure items would be. As far as I can see the .odt document is directly
linked to as such from the HTML page from the https: website, so the .odt
document should be "secure", too, shouldn't it?)

If I click "yes", the IE page goes blank, and IE asks "Do you want to allow
software such as ActiveX controls and plug-ins to run?", and if I click "yes",
the page goes grey and IE hangs, while soffice.exe and soffice.bin start.
soffice.bin is the child of soffice.exe, but for some reason soffice.exe's
parent isn't iexplore.exe, but winlogon.exe.

No error messages are displayed at all (not the "An API call exited abnormally",
nor the "Object not accessible" one that I have seen in an own OOo build where I
have only partially disabled the ActiveX embedding of OOo).

Should I open a new issue for this, or can this issue be re-opened?

Can it be possible that the above problem is not repeatable with all https:
websites, but require some specific behaviour that innerweb.novell.com happens
to have?

I have a patch for OOo that adds a switch --disable-activex to OOo's configure
script, which then makes all (hopefully) attempts to have OOo be an ActiveX
control go away. It would be nice to have that upstreamed, as that is what we
are using in our build. I'll put that in a CWS later today.

Forgot to mention (or maybe it's implicitly obvious) that when IE hangs and just
a grey page shows, although soffice.bin is running, no OOo user interface shows
up at all (presumably it is supposed to show up embedded inside the IE page).

OK, opened a new issue then instead, 65209.

*** Issue 35727 has been marked as a duplicate of this issue. ***