Issue 37020 - multiple warnings about disabled Java appear when opening Macro Selector
Summary: multiple warnings about disabled Java appear when opening Macro Selector
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: scripting (show other issues)
Version: OOo 2.4.1
Hardware: All All
: P3 Trivial with 2 votes (vote)
Target Milestone: OOo 2.0
Assignee: Olaf Felka
QA Contact: issues@framework
URL:
Keywords:
: 36978 37153 41511 42604 45135 46471 46680 47528 50663 52160 (view as issue list)
Depends on:
Blocks:
 
Reported: 2004-11-11 14:51 UTC by tomaisoc
Modified: 2013-03-03 13:32 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description tomaisoc 2004-11-11 14:51:50 UTC
If you disable using Java in Tools/Options/Java and then open the
Macro Selector using Tools/Macros/Run Macro... you see the warning
dialog about Java being disabled many times. The warning probably
should not appear at all as it is assumed if the user has disabled
Java that they don't want to enable Java related macro support.
Comment 1 tomaisoc 2004-11-11 15:00:19 UTC
The warning is popped up for each call to create a ScriptProvider which
is implemented in Java. Currently the mechanism we use for getting the
list of available providers is by using the XContentEnumerationAccess interface
to get all Services which inherit from LanguageScriptProvider.

TOC->JL: Is there a way of telling from each object implementing
XSingleComponentFactory and XServiceInfo that is returned by
XContentEnumerationAccess->createContentEnumeration() whether the service
will be possible to create? Alternatively is there a way to disable the
JavaInteractionHandler from popping up the warning dialog before trying
to instantiate the services and then enabling it again afterwards? Or maybe
we should just use a checkbox saying "Do not warn me again" in the dialog?
Comment 2 joachim.lingner 2004-11-15 13:23:15 UTC
Hi,

>Is there a way of telling from each object implementing
>XSingleComponentFactory and XServiceInfo that is returned by
>XContentEnumerationAccess->createContentEnumeration() whether the service
>will be possible to create? 

No. If  a component needs Java, C- runtime, Python, is just an implementation
detail.

>Alternatively is there a way to disable the
>JavaInteractionHandler from popping up the warning dialog before trying
>to instantiate the services and then enabling it again afterwards?

Yes, one could set a new current context at your stack level which does not
provide the interaction handler. However, this should not be done since you
would rely on an implementation detail. The way Java errors are handled may
change in the future.


> Or maybe we should just use a checkbox saying "Do not warn me again"
> in the dialog?

The initial bug description states that the error messages appear although the
respective check box is not checked.  The problem which arises when no messages
are displayed  or there would be that "Do not warn me again" checkbox is that
the user would be confused about what functionality does not work because of
Java. There is no way to tell programmatically if a component is written in Java
and hence one cannot say which functionality (or menu item)  does not work if
Java is missing. Now let us assume a user triggers the script provider  and
checks  "Do not warn me again" box. Later they try to start a wizard which fails
without message. The user  does not know if this is because of Java. They could
now switch the warnings on somewhere in the options dialog and try the wizard
again. Well I think it is up to the User Experience Team to decide if this is
what we want.

jl->CJ: Do you think:
-The Java warning should be disabled when the user switches off Java.
-The warning message should have the "Do not warn me again" checkbox? Then there
must also be away to switch warnings on again.
Comment 3 joachim.lingner 2004-11-16 15:54:11 UTC
The actual problem here is this:
UNO uses components, which can be written in multiple languages. The user or
clients of these components need not care about what language was used to create
a component. Unfortunately it was once decided to allow to switch of Java, which
is the actual bug. However OpenOffice may want to keep this feature. If now Java
does not work or it is switched off then one needs to communicate this to the
user. But who shall do this? The client code of a Java component does not know
that Java is needed - hence cannot provide error handling to this regard. In
order to have that error handling nonetheless, an error handler is created when
the office starts up. Whenever someone instantiates a Java service and it failed
because Java is not working then this errorhandler is invoked. This is done by
the com.sun.star.java.JavaVirtualMachine services which creates the VM. If for
some reason this service is used multiple times then everytime the errorhandler
is invoked. At this level it is not known if the user triggered one menu item 
or  ten. This knowledge has only the code behind the menuitem. If clicking on a
menu item causes muliple Java services to be created then the error message may
come up multiple times. This could only be surpressed if the client, in this
case the code behind a menu item, handles Java related errors. But the client
does not know that Java is being used by definition!

Again, the bug is that it is possible to switch Java off. 

The proper solution would be to  modularize the office in very small components.
Every component which depends on Java must not be installed if the required Java
is not on the system. Then it would also be possible to dynamically set up the
menus, based on the installed components. For example, there are some wizards in
the file menu which need Java. If the office would be installed on a system
which does not have the proper Java, then these items would not be displayed and
the user would not get any Java related error messages. However we are far away
from that kind of modularization. Also it is questionable if we want to spend
resources on that, because we already decided that Java is a supported language
for UNO components. 

Until it is decided if we remove the check box "Use Java ..."  user may have to
put up with theses error messages if they switch Java off.

Btw. on platforms for which there is no Java, the respective OOo does not bring
up these messages.


 


Comment 4 tomaisoc 2004-11-16 16:16:10 UTC
How likely is it that users will have Java installed but have disabled it for
OOo via the Tools/Options checkbox? If this is an unlikely scenario I am happy
to live with the dialog popping up many (at least 9) times when opening the
Macro Selector

Another option might be to warn them the first time instantiating a Java
component fails for each running of soffice and assume that if they said no
the first time they don't want to be warned again for the lifetime of this
soffice?

If users who have Java installed on their system have to go into Tools/Options
to disable using Java, then it would seem that is a good place to have a
checkbox about whether to warn them every time a Java component can't be
initialised, although I guess we don't want to be adding UI at this time.
Comment 5 joachim.lingner 2004-11-18 11:49:31 UTC
*** Issue 37153 has been marked as a duplicate of this issue. ***
Comment 6 tomaisoc 2004-11-18 15:19:48 UTC
*** Issue 36978 has been marked as a duplicate of this issue. ***
Comment 7 christian.jansen 2004-11-24 13:37:53 UTC
CJ: From my perspective it is OK to display a warning that this specificic
feature does not work because Java is diabled. I don not understand from an
users perspective what this has to do with Java, bacause one for example want to
run a macro written in Basic.

However, I suggest the following:
- Leave everything for OO.o 2.0 as it is. The warning is OK and it give users
the choice to switch Java on again.

For OO.o 3.0/SO9 might the topics below an option:
- Add a notice right next to the Java option in ToolsOptions that switching of
Java causes Trouble.
- And change the implementation of the ScriptProvider to C++, dispable Java
macros, if Java has been disabled (this assures the dialog is always
accessible); explain in the dialog why Java macros can't be executed.
Comment 8 tomaisoc 2004-11-24 13:50:51 UTC
The problem is not that a warning pops up telling the user that Java is
disabled, that is fine. The problem is that the warning pops up many times,
at least 9, when the user opens the Tools/Macros/Run Macro... dialog. As
JL has pointed out, this cannot be fixed in the code for the Run Macro...
dialog, the error is popped up by a global Java error handler. There is a
usability problem with the frequency of the warning message.

From my view there are a few choices:

1. Do not display the warning at all, if the user switched off Java then
   why do they need to be warned about switching it on, it was their decision
   in the first place to switch it off

2. Each time OOo is run, the first time an attempt to create a Java component
   fails display the warning, and don't display it after that

3. Display the warning every time an attempt to create a Java component
   fails but add a checkbox which allows the user to disable the warning

4. Always display the warning

If we stick with option 4 I think we will get a lot more issues on this,
there are already 2 duplicate issues.
Comment 9 christian.jansen 2004-11-24 15:02:58 UTC
Option 4 is OK for me.
Comment 10 tomaisoc 2004-11-24 15:08:09 UTC
Closing as WONTFIX based on input from CJ
Comment 11 tomaisoc 2005-01-28 11:15:15 UTC
*** Issue 41511 has been marked as a duplicate of this issue. ***
Comment 12 ralphie 2005-01-28 12:10:43 UTC
I think the current state is inacceptible, even if "without JRE" is not a
Sun supported configuration. There is a very real chance of the user losing
data (because he thinks he is in an infinite loop, and will only get out of
the program by killing it).

IMHO the minimum should be to add a sentence to the error dialog:

"If this warning appears repeatedly, please klick OK util it disappears"

If a computer program displays the same warning repeatedly, I think
it is in a infinite loop and has crashed. The user (who can't even
access online help any more) should be made aware of the fact that 
the program has not crashed and that there is still hope to save the
document.
Comment 13 tomaisoc 2005-01-28 12:16:57 UTC
Hi Ralphie,

You will need to reopen this issue and reassign it to cj if you want it to
get further attention. I don't own the code that controls the display of the
error message.
Comment 14 ralphie 2005-02-12 09:44:46 UTC
I filed 

http://www.openoffice.org/issues/show_bug.cgi?id=42604

for the aspect of misleading dialog wording.
Comment 15 joerg.barfurth 2005-02-14 14:24:42 UTC
Some comments:

I think that it is inappropriate to install an InteractionHandler globally into
the main thread, which triggers every time, when there is an attempt to
instantiate a Java component.

[FYI: I work on the configuration component, which also supports an interaction
handler for the case when it encounters invalid configuration data. But I assume
that popping up a message box for any other error I encounter might be entirely
inappropriate for the context this is invoked from. Thus, if such a message -
and the full recovery functionality - is desired, the code that handles the user
action is responsible for activating the handler (i.e. install it into the
context). This is the opposite approach to the Java one]

Looking at the error message "%PRODUCTNAME% requires [Java] to perform this
task.", there are several mistakes due to incorrect assumptions here:

1. This message should never occur more than once for each user-initiated
action. But in fact there are actions (e.g. macro-related actions) that attempt
to instantiate several services, all of which may attempt to access Java. But
these are not separate 'tasks' from the user's point of view.

Accordingly the message assumes that it is clear from the context what
functionality is lost due to the lack of Java. But in the macro case that is not
at all clear. If the user chooses 'Macros - Run...', that means he wants to run
any of the *available* macros, often one he created or recorded himself. In that
case it is not at all true, that the desired task can't be performed. Only if a
macro he expects requires one of the failing providers he is impacted. OTOH when
working more actively with macros (or when trying to find out why one expected
macro is not available in the list of macros to run), the user needs the
information which macro providers are unavailable (whether this is caused by the
lack of Java or not). 

2. This message (and this way of handling them) assumes that each service that
is being instantiated is necessary to perform the task the user requested. This
is not necessarily true. If a certain service is missing its client might fall
back on another solution or there might be a degradation in the functionality
offered. In some cases the service that can't be instantiated may even be purely
optional. The macro functionality is a case of degradation of functionality. As
mentioned before that degradation may or may not have impact on the user. (Less
for running macros, more for authoring/configuring).

Additionally there appears to be the problem that the case where the user chose
'cancel' is not handled properly by the scripting framework. This should be
filed as another bug.

I agree that a solution that addresses all these problems is not possible in the
short run. The best solution that can be done quickly is to intercept the
JavaInteractionHandler in places where this kind of problem occurs. For the
macro case, the best solution would probably be to install a local, temporary
wrapper for the JavaInteractionHandler. That wrapper could forward the first
invocation (for a given kind of error) to the original handler and suppress any
subsequent ones. As a result the message would pop up at most once for each user
action, which solves problem 1. Producing a more informative error message is or
isn't handled by the scripting framework anyhow and can't be the task of the
Java-specific handler.

@jl: Even if this InteractionHandler is not a 'published' (i.e. stable)
interface, it is an interface. It really should be possible to use this to
address bugs. As long as the unstable status of the interface is clear, that
should not be a problem.



Comment 16 tomaisoc 2005-02-14 15:02:21 UTC
> Additionally there appears to be the problem that the case where the user chose
> 'cancel' is not handled properly by the scripting framework. This should be
> filed as another bug.

The Scripting Framework does not know what button has been clicked, so there
is no way for it to handle the Cancel button. In general the presence of both
a No and a Cancel button seems confusing to me, I don't understand the
difference.

> I agree that a solution that addresses all these problems is not possible
> in the
> short run. The best solution that can be done quickly is to intercept the
> JavaInteractionHandler in places where this kind of problem occurs. For the
> macro case, the best solution would probably be to install a local, temporary
> wrapper for the JavaInteractionHandler. That wrapper could forward the first
> invocation (for a given kind of error) to the original handler and suppress
> any subsequent ones.

I agree, this is better than having the message popup so many times. If you
or JL can provide a code snippet that shows how I should do this I can add
it to the Scripting Framework code.
Comment 17 Mathias_Bauer 2005-03-31 16:10:33 UTC
Jochen, this is something we should discuss.
Comment 18 Mathias_Bauer 2005-03-31 16:11:10 UTC
.
Comment 19 Mathias_Bauer 2005-03-31 16:29:48 UTC
.
Comment 20 jelabarre 2005-04-21 15:36:34 UTC
I saw this as well, it was 15 error messages before the macro dialogue itself
would come up (I didn't try anything past that).  My major concern had been it
was a loop tha you could never escape, but at 15 errors, someone may give up too
soon and force-quit the application (which I had done first time I encountered
this).
Comment 21 jelabarre 2005-04-21 15:38:45 UTC
Sorry, I wanted to add this was in snapshot 1.9.93
Comment 22 joachim.lingner 2005-04-26 15:52:17 UTC
JL->CJ: At any rate we need a mechanism that tells the user that some
functionality does not work because there is no Java or something may be wrong
with it. This has nothing to do with the fact that one can  switch off the use
of Java in the options dialog.  So I go back to what I stated early here: 

The warning message should have the "Do not warn me again" checkbox? Then there
must also be away to switch warnings on again.

The options dialog should offer a switch to enable that warning again. But that
should not necessarily on the Java panel. Instead it should be more visible. We
have to keep in mind that most people whould switch the dialog off,  because
they do not want to be bothered again and do not know nor care what Java is. 

CJ, could you take of this?
Comment 23 e.matthis 2005-05-02 16:48:53 UTC
*** Issue 42604 has been marked as a duplicate of this issue. ***
Comment 24 e.matthis 2005-05-02 17:14:18 UTC
EM->CJ: I had a related issue to come up with a solution based only on a string
change (now marked as duplicate of this one). I spoke with Lutz about the
situation and he is strongly against a semi-solution with a checkbox or
additional text in the error message and says the only correct solution is a
technical/code solution that prohibits the error messages from reappearing
consecutively when no further user-interaction has occurred in between. I
recommend that you NOT add more options to the UI to solve this issue (pushing
the responsibility onto the user), but that you support the technical solution. 

I spoke with JL and he says a change in the code concept is necessary and not
possible in the short term. Therefore, I'm leaving the target as Office Later,
although the sooner the better. 
Comment 25 joachim.lingner 2005-05-04 12:08:59 UTC
*** Issue 46471 has been marked as a duplicate of this issue. ***
Comment 26 joachim.lingner 2005-05-19 11:38:29 UTC
*** Issue 46680 has been marked as a duplicate of this issue. ***
Comment 27 joachim.lingner 2005-05-19 11:43:14 UTC
JL->CJ: We decided to build in some mechanism to reduce the number of error
messages.
Comment 28 joachim.lingner 2005-05-20 12:43:51 UTC
.
Comment 29 drc 2005-05-27 16:26:23 UTC
In writer without a Java RTE I inadvertently clicked the Macro tab in picture
properties.  Then I clicked Background.  I think I got to background before the
Java message arrived - but now I am stuck in what seems like an interminable
loop of repeating error messages.

The only option is to kill the job and risk losing my work...

This is not a good UI for the uninitiated.  It's OK for me - I know OOo doesn't
(usually) lose my work, it has a fantastic recovery system.

And as a bug reporter I can find this information, and try for a bit longer to
confirm that the loop is indeed finite, and after enough OKs it starts to behave
properly.

But we really should try to get this sorted out before the masses flock to see
our genuinely superb version 2.  Can't we disable the tab if it really does need
Java, and there isn't one?
Comment 30 jack.warchold 2005-05-31 17:30:21 UTC
*** Issue 47528 has been marked as a duplicate of this issue. ***
Comment 31 joachim.lingner 2005-06-10 12:05:13 UTC
.
Comment 32 joachim.lingner 2005-06-20 12:06:36 UTC
The JavaContext which provides the JavaInteractionHandler is now set in two
locations. Globally in project desktop and  in sfx2 
(source/control/unoctitm.cxx)when a user action occurred.
Comment 33 joachim.lingner 2005-06-27 09:44:51 UTC
*** Issue 50663 has been marked as a duplicate of this issue. ***
Comment 34 joachim.lingner 2005-06-30 10:42:41 UTC
Reviewed by sb.
Comment 35 joachim.lingner 2005-07-05 15:50:09 UTC
JL->OF: To test the fix you can switch off the "use of JRE" in
Tools->options->Java and then choose Tools->Macro->Run Macro. Only one warning
message box should be displayed.
Please test this also with the patch (en-US) and a m106 on all platforms.

re-open issue and reassign to of@openoffice.org
Comment 36 joachim.lingner 2005-07-05 15:50:14 UTC
reassign to of@openoffice.org
Comment 37 joachim.lingner 2005-07-05 15:50:21 UTC
reset resolution to FIXED
Comment 38 Olaf Felka 2005-07-06 15:50:09 UTC
Fix verified in cws jl22.
Comment 39 lohmaier 2005-07-20 18:08:02 UTC
*** Issue 52160 has been marked as a duplicate of this issue. ***
Comment 40 Olaf Felka 2005-07-22 11:25:03 UTC
of: Looks good for me in m120.
Comment 41 lohmaier 2005-08-05 21:43:17 UTC
*** Issue 45135 has been marked as a duplicate of this issue. ***
Comment 42 zied 2008-07-21 15:06:22 UTC
I m a Ubuntu user.
I have Ubuntu 8.04 installed and fully updated.
when I choose macro I have this loop of warning.
there is 2 description of this issue on Lauchpad, with screen shot:
https://bugs.launchpad.net/ubuntu/+source/openoffice.org2/+bug/195200
Comment 43 ccheney 2008-10-16 01:52:46 UTC
reopening issue
Comment 44 Olaf Felka 2008-10-16 07:13:21 UTC
reclosing issue
Comment 45 Olaf Felka 2008-10-16 07:14:16 UTC
Reopened without a comment?