Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | multiple warnings about disabled Java appear when opening Macro Selector | ||
---|---|---|---|
Product: | General | Reporter: | tomaisoc |
Component: | scripting | Assignee: | Olaf Felka <olaf-openoffice> |
Status: | CLOSED FIXED | QA Contact: | issues@framework <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues, joachim.lingner, luckyalfred1992, ralph |
Version: | OOo 2.4.1 | ||
Target Milestone: | OOo 2.0 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
tomaisoc
2004-11-11 14:51:50 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? 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. 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. 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. *** Issue 37153 has been marked as a duplicate of this issue. *** *** Issue 36978 has been marked as a duplicate of this issue. *** 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. 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. Option 4 is OK for me. Closing as WONTFIX based on input from CJ *** Issue 41511 has been marked as a duplicate of this issue. *** 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. 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. I filed http://www.openoffice.org/issues/show_bug.cgi?id=42604 for the aspect of misleading dialog wording. 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. > 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. Jochen, this is something we should discuss. . . 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). Sorry, I wanted to add this was in snapshot 1.9.93 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? *** Issue 42604 has been marked as a duplicate of this issue. *** 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. *** Issue 46471 has been marked as a duplicate of this issue. *** *** Issue 46680 has been marked as a duplicate of this issue. *** JL->CJ: We decided to build in some mechanism to reduce the number of error messages. . 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? *** Issue 47528 has been marked as a duplicate of this issue. *** . 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. *** Issue 50663 has been marked as a duplicate of this issue. *** Reviewed by sb. 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 reassign to of@openoffice.org reset resolution to FIXED Fix verified in cws jl22. *** Issue 52160 has been marked as a duplicate of this issue. *** of: Looks good for me in m120. *** Issue 45135 has been marked as a duplicate of this issue. *** 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 reopening issue reclosing issue Reopened without a comment? |