Bug 57995 - [test case] window.innerWidth/Height are wrong the first time they are read when in a frame
Summary: [test case] window.innerWidth/Height are wrong the first time they are read w...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml ecma (show other bugs)
Version: 3.1.1
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-02 05:10 UTC by Steven Brown
Modified: 2012-06-18 14:10 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steven Brown 2003-05-02 05:10:58 UTC
Version:            (using KDE KDE 3.1.1a)
Installed from:    Gentoo Packages
OS:          Linux

The first time you access window.innerWidth/Height when in a frame, the numbers are wrong (I always seem to get 84x30).  Subsequent accesses work.  I've attached a testcase that will demonstrate this with alert()s.  Switch the $frame variable to see the difference.  It also shows a problem Konqueror has with adding unnecessary scrollbars in frames, but that's not nearly as important.

---

<?php

/*
 * This demonstrates several bugs in KHTML/KJS (maybe Konq too?).  The idea is
 * to get an image that fills a frame with no scrollbars.  This is done by
 * using the values of window.innerWidth and window.innerHeight.  The bugs are:
 *
 * Konqueror reports the window.innerWidth/Height properly without frames, but
 * with frames, the first time it reports them, the values are bogus (84x30).
 * The two sequential alert()s will show this bug.
 *
 * Konqueror properly doesn't show scroll bars if there are no frames, but if
 * the content is inside a frame, it gets unnecessary scrollbars.
 *
 * (Try setting $frames = true/false to observe the differences).
 */

$frames = true;

// Are we being used as an image (top frame linked image)?
if(isset($width) && isset($height)) {
  header("Content-Type: image/png");
  $i = imageCreateTrueColor($width, $height);
  imageString($i, 3, 0, 0, "There should be no scrollbars, as this is {$width}x{$height}, your frame size.", 0xffffff);
  imagePNG($i);
}

// Are we being used as a blank (lower frame)?
else if(isset($lowerFrame)) {
  print("<html><body>Blank frame</body></html>");
}

// Are we the upper frame that links to an image?  (If no frames, this is the
// document).
else if(!$frames || isset($upperFrame)) {
  ?>
  <html>
  <head>
  <STYLE TYPE="text/css">
  BODY {
    margin-top: 0px;
    margin-left: 0px;
    margin-right: 0px;
    margin-bottom: 0px;
    padding-top: 0;
    padding-left: 0;
    padding-right: 0;
    padding-bottom: 0;
    border-top: 0;
    border-left: 0;
    border-bottom: 0;
    border-right: 0;
    width: auto;
    /* Konq ignores this (Bug #44300) */
    overflow: hidden;
  }
  </style>
  </head>

  <body>
  <SCRIPT LANGUAGE="JavaScript"><!--
  alert("First width=" + window.innerWidth + " height=" + window.innerHeight);
  alert("Second (should be the same) width=" + window.innerWidth + " height=" + window.innerHeight);
  document.write("<img src=\"<?php print("$PHP_SELF"); ?>?width=" + window.innerWidth + "&height=" + window.innerHeight + "\">");
  --></script>
  </body></html>
  <?php
}

// Otherwise, we're' being used as the toplevel frameset.
else {
  ?>
  <html>
  <?php // You can use scrolling="no", but we exclude it to show the bug ?>
  <frameset rows="90%, 10%" frameborder="0" framespacing="0" border="0">
  <frame frameborder="0" framespacing="0" border="0" src="<?php print("$PHP_SELF?upperFrame=1"); ?>" noresize name="upperFrame">
  <frame frameborder="0" framespacing="0" border="0" src="<?php print("$PHP_SELF?lowerFrame=1"); ?>" noresize name="lowerFrame">
  </frameset>
  </html>
  <?php
}
?>
Comment 1 David Monniaux 2004-08-08 17:25:57 UTC
Same problem here with KDE 3.2.2, demonstrated by http://quatramaran.ens.fr/~monniaux/essais/frames.html
Comment 2 George Goldberg 2008-02-18 03:47:03 UTC
Is this bug still present in a recent KDE version, such as 3.5.9 or 4.0.1?
Comment 3 Michael Leupold 2008-04-06 04:20:13 UTC
Still present in trunk r793971. For easy access I upped the script to:
* http://test.confuego.org/57995.php?frames=1 (the version with frames computing the wrong width/height)
* http://test.confuego.org/57995.php?frames=0 (the version without frames showing the correct width/height)
Comment 4 Médéric Boquien 2008-11-23 15:52:49 UTC
Add the new email of the reporter to the CC list, he cannot access the original one anymore.
Comment 5 Stas Verberkt 2009-08-16 12:17:45 UTC
This seems to be a race condition. I modified the test to have a button which runs the script. When I click this button both innerWidth/innerHeight values are the same. This means the page is not fully loaded when the scripts are runned when they are in the body part. Which seems to be correct behaviour (the script is in the middle of the page not in an onload tag).
Comment 6 Myriam Schweingruber 2012-06-18 14:10:14 UTC
Message from the Bugsquad and Konqueror teams:
This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore.
If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report.
Thank you for your understanding.