Issue 60519 - Abnormal Behavior with Navigator and Styles Windows
Summary: Abnormal Behavior with Navigator and Styles Windows
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.0.3
Hardware: PC Windows 2000
: P4 Trivial (vote)
Target Milestone: OOo 2.0.3
Assignee: Olaf Felka
QA Contact: issues@gsl
Keywords: oooqa
: 60338 (view as issue list)
Depends on:
Reported: 2006-01-14 18:36 UTC by untel
Modified: 2006-07-03 10:13 UTC (History)
2 users (show)

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

trail of overlapping Navigator window images (27.71 KB, image/png)
2006-01-14 19:21 UTC, untel
no flags Details
zipped vcl dll containing the fix (compatible to 680m160 build) (1.08 MB, application/octet-stream)
2006-03-24 14:58 UTC, philipp.lohmann
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description untel 2006-01-14 18:36:53 UTC
The "Styles and Formating" window (through "F11" key or menu) and the
"Navigator" window display an abnormal behavior on my OOo 2.0.1 on Windows2000
SP4, with latest Java (1.5.0_06-b05):

In Writer or Calc, in an empty document:

Dragging the "Styles and Formating" window leaves behind it a succession of
image were it has passed, thus showing a multitude of 'ghost windows' images as
an ongoing trail; only when the dragging is stopped (or releasing the window)
does this sequence of overlapping window images disappear, the client window
having decided to redraw itself I guess.

Moreover, during this dragging of the "Styles and Formating" window, the CPU is
using around 80% or more, continuously, augmenting along with the speed of the
dragging. And along with this, there is noticeable activity on the hard drive
while dragging the window, there is reading/writing activity going on, which
stops when the dragging stops.

This doesn't happen on OOo 2.0.
Comment 1 untel 2006-01-14 19:21:14 UTC
Created attachment 33216 [details]
trail of overlapping Navigator window images
Comment 2 lars 2006-01-14 21:33:50 UTC
Hi, this is a duplicate, so the problem is already known; but I can't find the 
duplicate number atm.
Comment 3 lars 2006-01-14 21:34:38 UTC
Comment 4 lars 2006-02-17 16:14:26 UTC
can't find issue to which this is duplicate, so reopening; observation from 
reporter: with systernal's FileMonitor (
Filemon.html), I've seen that OOo creates, opens, writes and reads a tremendous 
amount of times a file named: "Views.xcu_tmp" in the "\Application 
Data\OpenOffice.org2\user\registry\data\org\openoffice\Office\" folder, I guess 
for writing where the Navigator window is moved as I drag it. This is the cause 
for the hdd access which in turn leads to jerky redraw of the navigator or 
stylist when moving it.
Comment 5 lars 2006-02-17 16:14:59 UTC
confirmed with OOo 2.0.2 RC1 on WinXP Pro SP2
Comment 6 rmemmons3m 2006-02-19 13:25:07 UTC
I've seen this too.  I would like to add that on my system (windows 2000) trying
to drag the window usually freezes OO and I have to kill it and reboot.  There
is something wrong with the whole.  I've found this both in Writer and in Master

The freezing behavior is so severe it makes OO pretty much useless on my system.
 If this freezing/crashing is related I'd elevate this issue to VERY high
priority.  I alos may submit a separate issue for the freezing issue I've been
seeing -- though it may be related to this.
Comment 7 untel 2006-03-09 00:34:34 UTC
Problem subsists in final 2.0.2 build (Windows 2000 sp4).

Also, the "Views.xcu_tmp" file activity occurs even when the Navigator or Styles
windows are docked (anchored) on the side while the width of the window is modified.
Comment 8 untel 2006-03-16 03:17:04 UTC
The graphical anomaly exists even with OOo 2.0.2 for Linux, on Mandriva Linux
2006. So this isn't limited to Windows platform.
BUT the frequent hard drive reading/writing activity *doesn't* seem to be
present though on the Linux platform (i would have to get a tool similar to
FileMonitor for Linux to be certain).
Comment 9 untel 2006-03-16 22:37:20 UTC
The following acceptable (and quite simple!) solution has been given by a
OOoForum user (BMarcelly):

Simply disabling the "Show window contents while dragging" option prevents the
badly redrawing of the Navigator and Styles windows.

In Windows 2000 this is done through the "Display Properties" control panel:
Control Panel>Display Properties>Effects tab, uncheck "Show window contents
while dragging".

In Windows XP:
Control panel>System>Advanced>Performances>Visual Effects, and uncheck "Show
window contents while dragging".

It seems (in my win2000 system) that the frequent hard drive reading/writing
activity is also solved this way.

Another user indicated a similar solution in Linux.

So fixing this problem isn't much as important as I thought, P4 or P5, but I
don't know how to change the priority here.
Comment 10 Olaf Felka 2006-03-17 08:54:38 UTC
Additional information: On WindowsXP I've switched to 'Display window content
while dragging in the Display properties'. The you can the effect that the
repaint is kind of weird. As long as you drag the windows it doesn't repaint the
background. Stopping dragging and the painting is ok. I don't know if the cause
is the same: Doing this on Windows Vista and Office freezes.
Comment 11 takeda64 2006-03-17 09:20:49 UTC
Actually it also freezes on my Windows 2000 SP4, I actually reported it in issue 
Comment 12 Olaf Felka 2006-03-17 09:35:47 UTC
*** Issue 62256 has been marked as a duplicate of this issue. ***
Comment 13 takeda64 2006-03-17 10:00:33 UTC
There is another related issue, that the workaround doesn't solve.
The freeze _sometimes_ occur when you for example use formula editor in the 
writer and you're switching between formula editor and the writer.

I also remember that it happened, when I used calc inside in writer.
Comment 14 philipp.lohmann 2006-03-23 18:53:59 UTC
I can fix the trailing windows issue (which is a windows problem where windows
itself will not elapse timers during the move). Fixed in CWS vcl56

If Views.xcu is written too often, that is a framework issue and should be
addressed in another issue.

Any Vista specialties are another issue also and should accordingly be handled
in other issues.
Comment 15 philipp.lohmann 2006-03-23 18:55:47 UTC
pl->of: if you can confirm that the Views.xcu is written all the time during
moving a window, then please write an issue to framework and assign it to cd.
Comment 16 takeda64 2006-03-24 04:39:59 UTC
I actually reported the bug in different area, but somebody said is a dupe. I 
think all of those issues are related. And I bet that once the source of problem 
is fixed all of them will be fixed.
You said you fixed the trailing windows problem, in CWS vcl56.
Is there a binary version (for windows) o that branch so I could download it and 
test if the problem still presist, and eventually open new bug (since as you 
said it should be reported separately)
Comment 17 philipp.lohmann 2006-03-24 09:23:46 UTC
The continual accessing of Views.xcu can only be framework; Views.xcu is used to
store persistent window positions (so a dialog or the stylist or navigator will
show up in the same place as before e.g. on next start). If that is consistently
written to during moving the framework would have to fix that.

The trailing windows problem was due to the fact that OOo collects paint events
over a timer and only paints this collection after a timer has elapsed; the
problem was that Windows itself will dispatch timer messages with the lowest
priority of all events, so the timer never elapsed before the move basically
ended; this is what i changed. I can attach a binary version of the vcl680mi.dll
(containing the fix) to this issue; this would be binary compatible to be put
under a 680m160 version.
Comment 18 philipp.lohmann 2006-03-24 14:58:09 UTC
Created attachment 35224 [details]
zipped vcl dll containing the fix (compatible to 680m160 build)
Comment 19 philipp.lohmann 2006-03-24 15:56:31 UTC
please verify in CWS vcl56

re-open issue and reassign to
Comment 20 philipp.lohmann 2006-03-24 15:56:40 UTC
reassign to
Comment 21 philipp.lohmann 2006-03-24 15:56:46 UTC
reset resolution to FIXED
Comment 22 Olaf Felka 2006-03-31 09:50:14 UTC
of: For the permanently writing of temporary view.xcu I have to discus with
developer if we can handle it different. For the freeze on Vista I've filed
issue 63842 to have a look. This issue is fixed in cws vcl56.
Comment 23 Olaf Felka 2006-03-31 11:01:46 UTC
of: For 'views.xcu problem' I've created issue 63848. It has to be discussed if
changes are possible.
Comment 24 Olaf Felka 2006-03-31 12:05:45 UTC
Folluw up issue for linux: 63853
Comment 25 untel 2006-04-04 04:47:47 UTC
@pl concerning the vcl680mi.dll fix for 680m160:

I installed OOo 680m60, then overwrote the above vcl680mi.dll in the program
folder. The Navigator and Style windows now redraw better now, even with the
"Show window contents while dragging" enabled. I just want to note here however
that draging the windows still takes a lot of cpu power, much more than in child
windows of other apps. Perhaps this is due to the Views.xcu_tmp writing, I don't
know. I'll write about it in the 63848 issue.

Also, there seems to be a bug with your fix: when I go to the General Options,
doing Tools->Options->General, OOo crashes, closes suddenly.
It doesn't do that with the original vcl680mi.dll.
Comment 26 philipp.lohmann 2006-04-04 09:48:14 UTC
That crash is fixed already, i just didn't attach a new library to conserve
space. Thank you for noticing.
Comment 27 Olaf Felka 2006-04-10 08:52:44 UTC
*** Issue 60338 has been marked as a duplicate of this issue. ***
Comment 28 Olaf Felka 2006-05-09 11:33:56 UTC
Lokks better in m167.
Comment 29 untel 2006-07-01 21:26:07 UTC
Isn't fixed after all.

CPU used to nearly 90% while dragging.

I'll just revert to the usual solution of unchecking "Show window contents
while dragging" in the Effect tab in the "Display Properties" control panel.

Just wanted you to know this was still there. With the preceding solution,
there's no hurry.
Comment 30 ace_dent 2006-07-02 12:11:22 UTC
Tested with OOo 2.0.3 680m173 b9040.

Defect persists: Still seeing multiple trails when dragging window. However, the
remaining problem might be due to Issue 63848 ?

Comment 31 untel 2006-07-02 16:05:59 UTC
Oops! Had forgotten about that follow up.
Thanks for the reminder. Sorry.
Please re-close.
Comment 32 Olaf Felka 2006-07-03 08:27:17 UTC
Comment 33 Olaf Felka 2006-07-03 10:13:08 UTC