Incorrect width calculations (Trac #1601)

[sleemanj]

Tested on Google Chrome Version 21.0.1180.89 with Ubuntu 11.04 -- I haven't yet tested any other browsers.

1. Load the examples/simple_example.html page in a browser
2. Wait for Xinha to finish loading
3. Press enter a few times, until the sample text is taller than its containing frame and a vertical scrollbar appears

The vertical scrollbar appears in the wrong place: it shows up about 10 pixels to the left of the right-hand side of the Xinha container, instead of being attached to the side of the container.

This is because Xinha's status bar is assigned a bigger width than it should get, but only after the iframe's width has been set. The status bar's width ends up being wider than both the iframe and the <table class="htmlarea">. This causes the table's width to be extended to contain the statusbar, but the iframe's width is not updated accordingly. As a result, the iframe's width ends up being 10 pixels less than the (incorrect) width of the entire Xinha container so the vertical scrollbar looks like it's floating detached from the container.

A screenshot is attached.

Reported by ejucovy, migrated from http://trac.xinha.org/ticket/1601

[sleemanj]

Attachment: xinha-ticket-1601.png

[sleemanj]

ejucovy commented:

There seem to be two problems with the status bar's width calculation:

1. Its width property is set to be equal to the width of the overall container. But in Xinha.css, the statusbar is given 4px padding-left and 4px padding-right, as well as a 1px border on each side. So when _statusBar.style.width is set to N px, its actual calculated width ends up being N+10 px.
2. Even after accounting for that, the status bar's width property is derived from the _htmlArea's offsetWidth, but the _htmlArea's offset width has an extra two pixels (from borders, I think) that shouldn't be included.

The following patch addresses the problem I'm seeing, by using _htmlArea.clientWidth instead of .offsetWidth, and by manually subtracting 10 pixels to account for the status bar's styles; probably the 10 pixels shouldn't be hardcoded, and I'm not sure if using clientWidth is really correct here.

Also, I haven't tested on any other browsers/versions/operating systems, so the patch isn't final.

Index: XinhaCore.js
===================================================================
--- XinhaCore.js  (revision 1327)
+++ XinhaCore.js  (working copy)
@@ -2230,7 +2230,9 @@
     } 
     else
     {
-      var width = size['width'];
+      var width = parseInt(size['width']);
+      // the statusbar has 4px padding on each side, plus 1px border on each side
+      width = width - 10;
       self._statusBar.style.width = width + "px";
     }
   });
@@ -3054,8 +3056,9 @@
   this._textArea.style.height = this._iframe.style.height;
   this._textArea.style.width  = this._iframe.style.width;

-  this.notifyOf('resize', {width:this._htmlArea.offsetWidth, height:this._htmlArea.offsetHeight});
-  this.firePluginEvent('onResize',this._htmlArea.offsetWidth, this._htmlArea.offsetWidth);
+  this.notifyOf('resize', {width:this._htmlArea.clientWidth, height:this._htmlArea.offsetHeight});
+  this.firePluginEvent('onResize',this._htmlArea.clientWidth, this._htmlArea.offsetWidth);
+
   this._risizing = false;
 };
 /** FIXME: Never used, what is this for? 

[sleemanj]

• @sleemanj commented:

1341 Fixed via box-sizing css and a 2px adjustment for border (or something)

• @sleemanj changed resolution to fixed
• @sleemanj changed status from new to closed