Apache OpenOffice (AOO) Bugzilla – Issue 46887
Flat review fails in dialogs
Last modified: 2013-08-07 15:31:14 UTC
1. Launch Gnopernicus 2. As a first time users, run /opt/staroffice8/program/soffice 3. Go through the various installer steps, and get to "StarOffice Registration" 4. With NumLock on, press the '.' (or 'Del') key on the NumPad. This should turn Gnopernicus flat review on. 5. Notice that the four buttons on the bottom of the dialog get redrawn, partially, but with three of them (all but "Next >>") loosing their text. Hear Gnopernicus say "flat review mode" followed by "focus tracking mode" and then "Switch to window Welcome to StarOffice 8" the selected radio button with its accompanying label is read to you. BUG(s).
Further note: pressing "Finish" at this point will hang the GUI desktop entirely. Ctrl-Alt-F1 won't work even!
Changed 'Component'.
Setting keyword "accessibility".
ES->OBR: as discussed, please evaluate if we can fix this or have to pass it to the installer developpers.
The "Registration" dialog is now part of the first start wizard, not of the installer anymore. I can reproduce the descibed behavior im m104, but it only happens with the gtk plugin enabled ! It seems that the dialog window looses the focus for a moment (regaining it a moment later) and that this focus flicker turns gnopernicus back to focus tracking mode. Here is the log from the Java-UNO-AccessBridge: [radio button] I want to register now is no longer focused [Dialog] Welcome to StarOffice 8 is no longer active [Dialog] Welcome to StarOffice 8 is now active [radio button] I want to register now is now focused
Note: i could reproduce the "freeze". But office was not running at the time, i think that one is a Gnopernicus specialty. I could also reproduce the paint problem with the buttons.
Note: the focus flickering is external, this comes directly from the gtk event loop telling us we lost focus and gain it again. Probably gnopernicus doing its stuff. Furthermore: the button texts are drawn, but somehow never appear on the screen. I have yet to find out how that can happen. This does not seem to be a clipping problem. Setting platform to "All" since this is obviously not confined to opteron/x86_64
Not sure about the focus-flicker; gnopernicus doesn't do anything that should be causing you to lose focus - unless you are reacting strangely to some poking from the a11y code. IOW it may yet be an OOo issue.
The focus stuff does not come from OOo, i set breakpoints to XSetInputFocus as well as our focus influencing methods (SalFrame::Show, SalFrame::ToTop). These were not hit, instead OOo gets a focus method (out) immediately followed by focus(in) from the gtk main loop. Anyway this should be irrelevant since even though the buttons are painted perhaps unnecessarily, they should at least be painted complete. I followed the text drawing function and the flow of operation seems normal enough, just the text doesn't appear. Changed the title according to the fact that this problem is reproducable other dialogs also (e.g. tools->options). pl->hdu: do you have an idea what could cause the not appearing pushbutton texts ?
We will not finish this in the 2.0.2 time frame -> retargetted to 2.0.3
*** Issue 54799 has been marked as a duplicate of this issue. ***
Retargeting...
target 3.0
obviously gtk-plugin issue. reassigning and retargeting
cannot reproduce
closing