112495 - Window contents bounce (or shake, or jiggle) [table properties]

Status: RESOLVED WORKSFORME

(Core Graveyard :: Embedding: APIs, defect)

Description

[Colin Blake]

0.9.6 code on OpenVMS. But I see the same problem with 0.9.6 on RedHat.

In composer, create a table.

Click inside a cell and right click, then select "Table Cell Properties..."

When the Table Properties window appears, its contents "bounce". If you blink
you'll miss it.

Click on the color box to the right of "Background Color" and you'll see the
contents bounce again, before the "Cell Color Background" window appears.

If you still don't see it, trying enabling "Background Color" in the "Table
Properties" windows. Bounce! Disable it. Bounce! Click "Background Color" on and
off repeatedly. Bounce, bounce, bounce.

I'm using the classic theme in case it matters.

Comment 1

[sairuh (rarely reading bugmail)]

either editor or layout mebbe? xp apps isn't the right place, afaik.

Comment 2

[Kathleen :Brade]

sounds like a xul problem for Charley...

Comment 3

[Charles Manske]

It's not very likely to be a Composer XUL problem -- most likely an 
XPFE/XUL/Themes bug.
In debug build, I'm getting asserts when I launch any dialog, so I can't see
a "bounce" if it exists (Windows 2K). Maybe those asserts cause that problem?
I suspect it's only a problem on Linux, as there's other dialog layout and 
positioning problems only on Linux.
Akkana: Do you see this?

Comment 4

[Charles Manske]

The asserts I mention above only happen during the first loading of the dialog.
With subsequent loading, I am not seeing any dialog movement in Windows.

Comment 5

[Akkana Peck]

I don't see the bounce.  This is a pretty fast machine, though, so it's possible
that it's bouncing too fast for me to see.

I do see four lines of error any time I change that background color -- don't
know whether these might be related:
XXX Damage rectangle (90,540,7621,4936) does not intersect the widget's view
(0,0,0,0)!
XXX Damage rectangle (0,0,7621,4936) does not intersect the widget's view (0,0,0,0)!
XXX Damage rectangle (90,540,7621,4936) does not intersect the widget's view
(0,0,0,0)!
XXX Damage rectangle (0,0,7621,4936) does not intersect the widget's view (0,0,0,0)!

Comment 6

[Charles Manske]

Any confimation on this? Ready to mark WORKSFORME if not.

Comment 7

[Colin Blake]

I'm building from tip right now. But builds take a long time on OpenVMS. 
Assuming nothing's busted, I should be able to test this tomorrow afternoon and 
see if it WORKSFORME yet.

Comment 8

[Colin Blake]

Tip build from yesterday and its still bouncing.

Comment 9

[Charles Manske]

I've talked to our window creation expert, danm.
Composer is doing some window re-positioning using SetWindowLocation() / 
SaveWindowLocation()in EdDialogCommon.js. Dan tells me that some C++ code will
probably make that behavior the default for dialogs (load a dialog relative to
the parent window location), so we may be able to abandon the Composer-specific
feature that is probably contributing to this problem.
Note that it also is probably important to know what Linux Window manager you are
using -- Dan suggests that Colin's might be showing the window very quickly,
but then it is relocated during the dialog "onload" handler, when 
SetWindowLocation is called.

Comment 10

[Dan M]

  I don't see any of the problems Colin mentions. It's probably window manager
dependent and maybe you need a slow machine to see the bounce. These windows
have script that runs at onload time that repositions them. onload time is when
a chrome window first becomes visible, too. Some unhappy coincidence of timing
could be making the latter happen noticeably earlier than the former on the
problem machine.
  But bug 113283 should fix this by allowing the window positioning currently
coded in composer window script to be handled in C, well before the window is
made visible. It'll need some extra effort to make it work at all on unix, though...

Comment 11

[Colin Blake]

I've just repeated this on builds from this week. The problem is still
happening. As before, the problem is much more apparent on OpenVMS, but you can
see it on Linux, although you may have to go through several cycles of clicking
on the "background color" box and canceling the color box before you'll see it.
And on Linux not all the box jiggles, just some of the contents in the middle area.

I'm running GNOME on RH 7.0, on a 500MHz Pentium.

Comment 12

[Akkana Peck]

Many linux window managers have a plethora of settings to control how much
attention the window manager pays to program-specified window and dialog
placement.  But if composer is specifying dialog position, and then dialogs are
being repositioned to somewhere else, that would explain it -- obviously that's
something we should fix.  Anyone who's running with "ignore program-specified
window positions for toplevel windows" (which seems to be the default in most
modern distros?) won't see the effect (our dialogs show up as top-level windows,
not as dialogs, at least when I tested some sawfish settings last week; that
should probably be considered a bug, but a minor one, and it's not what's
causing the problems in this bug).

Comment 13

[Colin Blake]

Bug 113283 has been closed, but this problem seems worse than ever on M0.9.7.

Comment 14

[Dan M]

Bug 113283 was closed on the trunk just yesterday; you certainly wouldn't notice
that in the the 0.97 milestone build. And 113283 merely paved the way for fixing
this bug. Or so we imagine, since I haven't actually seen it happen.

We're guessing that perhaps the editor windows' unique positioning script is
causing this shake; moving the window at an inopportune time. 113283 provided
C-level support for the same effect the editor windows' positioning script
produces. With that checked in, maybe it's a matter of removing the positioning
script and hooking up the C-level support for each of the 23 editor dialogs that
use this mechanism.

Comment 15

[Dan M]

Attachment: fix (?) table properties dialog

In the Table Properties dialog, replace the script window positioning code with
standard window positioning mechanism. Charles, can we check this one in so
that people who can see this bug can tell us whether it fixes it? (And you'll
want to check that it still behaves the way you wanted). If this is it,
*some*body is going to have to do the same thing to the other 22 editor dialogs
similarly treated. I feel a reassignment coming on...

Comment 16

[piers]

Just confirming that this still happens on Solaris/SPARC/KDE (2002021722).

Also, the window contents sometimes doesn't "jiggle" if you click "Advanced
Edit" or the background color selecter straight away after opening the window,
if that 
helps.

Comment 17

[Kathleen :Brade]

Did anyone ever try Dan's patch?
Charley?

Comment 18

[Charles Manske]

I can't repro the bug, but I know it's ok to apply this patch (i.e., Dan fixed
the window positioning so we don't need the Composer code to do this.)
So I guess we could just check it in and hope it fixes the "jiggle" problem?

Comment 19

[Mike Shimony]

I'm running Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5)
Gecko/20031007.  When viewing some webpages the window contents bounce up and
down constantly. This only happens on some pages, and on some of the pages where
it happens, it only happens some of the time.

When I click "Help|About Mozilla" it always happens.  The first time I looked at
this bug report my window was bouncing around, but it's not bouncing around
right now.  

Also, once the window starts bouncing it doesn't stop.  The first time I noticed
the problem was just after installing Mozilla.  When starting the browser it
autmaticly went to a Mozilla webpage.  After a few minutes (4 or 5) with Mozilla
running partially hidden behind some other windows, I noticed the window start
bouncing.

Comment 20

[Mike Shimony]

I also notice this behavior on the about:blank window on startup.  The boarder
line that divides the status line at the bottom of the browser from the main
window will disapear and come back rapidly.

Comment 21

[Dan M]

The opening comment on this bug states that the complaint was a single, small,
automatic repositioning of certain editor windows, just after they were opened.
On a handful of machines and builds we could never reproduce it. But, shot in
the dark time, we thought the patch attached to this bug might solve the
problem. It was a relatively easy patch to apply, being xul and js, but no one
ever got back to us on whether it helped. So here the bug sits. We need a bug
resolution "no one really cared." But since this bug is now attracting reports
of different bugs,  I'm giving it the closest resolution, "works for me."

Mike, the bug you're describing wants to be in a new bug. You're running a
Windows build and you're seeing a constant bounce. Very different. In fact,
comments 19 and 20 are two very different things, so you'll want to file two new
bugs. Please don't pile up multiple complaints in a single bug report. It adds
to the confusion and forces the bug owner to pick one and ignore the other.
Which is why I'm closing this bug: I'm choosing to go with the original complaint.

When you file those new bugs, try to find some way to reproduce it. They sound
very annoying. You know if they were happening with any frequency it'd be a
major issue. I suspect you're the only person seeing this problem, so it's going
to be very important to pin it down more reliably. A more detailed description
might help. Help->About Mozilla always bounces? In which direction? How far? How
quickly? Does it bounce between two locations or several? Does it stop if you
reposition it yourself? If you resize it? Does the original location of the
freshly opened window matter? Do you have an unusual monitor setup? If you're up
for it, is it perhaps dependent on some of the persistent attributes in
localstore.rdf in your profile directory?

On the statusbar bug, screenshots would be helpful if you can manage them. Take
a single screenshot and then fake the other state in an image editing program if
you have to. Does the statusbar change in size? Do the window contents shift to
accommodate it? What skin are you using? Does it stop if you switch? There was a
somewhat similar sounding problem hacked away in bug 201379 (the bug even has a
flash movie attached! now that's big fun.) Does that sound related? Do you have
any parts of your chrome hidden? Empty? (See bug 221503.) Do either of your bugs
happen to be bug 215446 (which, yes, has been closed WFM).