PDA

View Full Version : [UNKNOWN][3.??] Component render bugs when browser zoom level is not default



divestoclimb
7 Jan 2010, 8:38 AM
I don't think this has been reported before... I have been collecting data on this one for some time since my company's customers have been reporting it for months. It was only recently that we were able to gather enough data to realize what was causing the issue.

Ext version tested:


Ext 3.0 rev 0
Ext 3.1 rev 0



Adapter used:


ext



css used:


only default ext-all.css





Browser versions tested against:


FF3.0, 3.5 (Firebug can be disabled or uninstalled and the problem still occurs)
IE8 (supposedly, I have not confirmed)



Operating System:


Mac OS X (not personally)
WinXP Pro



Description:


Modern browsers which change page zoom level by scaling DOM elements breaks Ext 3.0 and 3.1 component rendering. The test case below should reproduce the effect.



Test Case:



<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Firefox Creep bug in Ext JS</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<link rel="stylesheet" type="text/css" href="http://www.extjs.com/deploy/dev/resources/css/ext-all.css" />
<script type="text/javascript" src="http://www.extjs.com/deploy/dev/adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="http://www.extjs.com/deploy/dev/ext-all-debug.js"></script>

<script type="text/javascript">
Ext.onReady(function() {
var panel = new Ext.Panel({
renderTo: "buggy",
height: 300,
layout:"border",
tbar: new Ext.Toolbar({
items: [{
xtype:"tbtext",
text:"The effect has not been reproduced without this top bar on the panel."
}]
}),
items:[{
region:"west",
collapsible:true,
collapsed:true,
title:"West Panel",
html:"When I'm collapsed and Firefox page zoom is active, my collapsedEl creeps."
}, {
region:"center",
html:"Center panel"
}]
});
// This demonstrates how, even if the effect is avoided by being at
// the default zoom at render time, that you can still trigger the
// bug later by manipulating the panel after the zoom level changes.
(function() {
panel.setHeight(400);
}).defer(5000);
});
</script>
</head>
<body style="margin: 5px">
<p>The west region's collapsedEl in the below panel will grow in size
one pixel at a time in Firefox if the page zoom level is not the
default.</p>
<ul>
<li>- The panel should have rendered below. Wait five seconds
for the deferred setHeight call, then increase the zoom
level by pressing Ctrl +. The panel increases in size and
behaves as expected.</li>
<li>- While the page is still zoomed, reload. The west
collapsedEl slowly expands in width. This happens independently
of the deferred setHeight.</li>
<li>- Reset the zoom level by pressing Ctrl 0, then reload the
page. Within five seconds after the page loads, hit Ctrl +
again. The panel then behaves as expected until five seconds
after render, when the deferred setHeight call is executed and
the collapsedEl starts growing.</li>
</ul>
<div id="buggy" style="width: 700px"></div>
</body>
</html>



Steps to reproduce the problem:
See test case

The result that was expected:


Ext components render within the scaled browser window at dimensions proportional to their defaults.



The result that occurs instead:


In 3.0, the west collapsedEl slowly creeps outward by a handful of pixels at a time.
In 3.1, the component cannot render properly at all if the zoom level is non-standard at render time.
In 3.1, the component cannot resize properly if the zoom level changed to a non-standard level after render time and before the resize is attempted.



Screenshot or Video:


attached



Debugging already done:


In 3.0, this could only be reproduced when a tbar is added to the same panel with a BorderLayout.
In Firebug, I noticed that the widths of the components inside the outer Panel are assigned non-integer widths by the browser's scaling routine...



Possible fix:


In 3.0.0, I suspected the problem had to do with the fact that Firefox would report non-integer pixel width/heights of elements, and Ext was getting into an infinite feedback loop with the browser trying to get everything sized properly. In 3.1, I have no idea what's going on, I haven't played with it enough.

hendricd
7 Jan 2010, 10:18 AM
@divestoclimb -- Just ran thru your sample here (but, built with the latest 3.1 SVN 5845+), and I'm not seeing that behavior now at all.

Indeed, Firefox recently introduced fractional pixel support for inline-style. We've added supported for it (see more here (http://www.extjs.com/forum/showthread.php?p=423331#post423331)).

We'll be applying it to 3.0 as well shortly.

If you have SVN access, can you try a more recent 3.1+ build in your environment?

divestoclimb
9 Jan 2010, 8:43 AM
No, I don't have SVN access. From the thread you're referring to it sounds like a fix has been made though. I look forward to getting my hands on it!