MySQL Bugs: #31679: ugly layout behavior when switching between Advisor views

Bug #31679	ugly layout behavior when switching between Advisor views
Submitted:	18 Oct 2007 1:28	Modified:	28 Jul 2008 19:32
Reporter:	Sloan Childers	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Enterprise Monitor: Web	Severity:	S3 (Non-critical)
Version:	1.2.0.7879	OS:	Windows
Assigned to:	Eric Herman	CPU Architecture:	Any

Description:
expanded table views overlay the footer when switching between pages

How to repeat:
go to the "Add to Schedule" page
expand the heat chart group
go to the "Current Schedule" page
return to the "Add to Schedule" page

the schedule table is drawn over and past the footer

Windows/XP
FireFox 2.0.0.7

Suggested fix:
we are missing a paint request somewhere or the components are being laid out in the wrong order

I've seen this on other people's boxes before but am unable to repeat on mine. 

A couple things to note, there is no explicit paint request and order of elements rendered on the page cannot be controlled. 

The reason something like this happens is that the rendering engine gets confused when contents are changed in a sub-node and neglects to re-size the parent node(s). The only time I can think of this happening in a browser like firefox is some sort of race condition. I'm not sure what those circumstances would be here though since the page is loaded prior to applying the node expansion to the listbox. 

I have a few tricks for dealing with issues like this, the most brute force of which being to hide then immediately show the parent node _after_ the child node changes have been applied. This should result in a repaint after all the "races" are over. I'll need to consistently repeat the problem to work on this though.

Josh,

I've been able to consistently reproduce this bug by adding a GZIP output filter mapped to the action servlet, which must be enough to trigger the race condition. I can give you the filter in the hopes that it would help you reproduce the problem.

Was unable to reproduce with mark's instructions and mark and sloan did not have their machines that were reproducing the issue in cupertino. I won't be able to fix this for the 1.3 release. Pushing the target to 2.0

Is this still occurring? We never have found how to reproduce it reliably. Any guidance appreciated.

We near periodic reports of this, but have done a code review without finding it. Need help reproducing this...