Opened 8 years ago

Closed 3 years ago

#1601 closed defect (fixed)

Incorrect width calculations

Reported by: ejucovy Owned by: gogo
Priority: normal Milestone:
Component: Xinha Core Version: trunk
Severity: normal Keywords:


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.

Attachments (1)

xinha-ticket-1601.png (42.3 KB) - added by ejucovy 8 years ago.

Download all attachments as: .zip

Change History (3)

Changed 8 years ago by ejucovy

comment:1 Changed 8 years ago by ejucovy

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 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 @@
-      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; = width + "px";
@@ -3054,8 +3056,9 @@ =;  =;
-  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? 

comment:2 Changed 3 years ago by gogo

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.