Ticket #4782 (new defect)

Opened 13 months ago

Last modified 19 hours ago

[patch][ccla]IFrame relative offset problem in dojo.coords()

Reported by: guest Owned by: sjmiles
Priority: normal Milestone: future
Component: HTML Version: 0.9
Severity: normal Keywords:
Cc: amimalik@…, doughays, bill

Description (last modified by doughays) (diff)

It seems that when I want to use/draw a widget inside an IFrame Dojo (version 0.9.0) does not take into account the relative position of the IFrame in the parent page. This causes popups like Tooltips to appear outside of the IFrame. This testcase should demonstrate the behaviour: 

<html>
<head>
<script type='text/javascript'
djConfig=' isDebug: true, usePlainJson: true' src='dojo/dojo.js'></script>

<script type='text/javascript'>
dojo.addOnLoad(function init() {
  window.frames["frm"].document.write("<html><body><div id='tip0'>hover</div></body></html>");
  var id = window.frames["frm"].document.getElementById('tip0');
  var c = dojo.coords(id);
  console.log("x: " + c["x"] + "  y: " + c["y"]);
});
</script>
</head>
<body class="tundra">
  <iframe name="frm" id="frm" width="300" height="300" frameborder="0"
    scrolling="yes" style="position:absolute;left:200px;top:200px;"></iframe>
</body>
</html>

The (x,y) coordinates of the element should take into account the IFrame offset.

Thank you!

- Amir

Attachments

test4782.html (1.2 kB) - added by doughays 8 months ago.
test html file with complex margins/border/padding demonstrating patched dojo.coords function
4782.patch (2.6 kB) - added by doughays 8 months ago.
possible fix - please review for inclusion in 1.1 - added optional includeFrame parameter to dojo.coords (to prevent breaking existing users) to compute absolute coordinates relative to document root instead of just to the nearest iframe (refreshed)

Change History

Changed 13 months ago by bill

  • owner changed from anonymous to sjmiles
  • component changed from Core to HTML

Changed 12 months ago by guest

any progress on this?

Changed 11 months ago by guest

I am just curious if there is an expected fix date or release version in which this will be included? Thanks and happy new year!

Changed 10 months ago by doughays

  • keywords doughays, bill added
  • priority changed from normal to high
  • milestone set to 1.1

This is needed for an IBM product that will be using Dojo 1.1.

IBM reference # 78238.

I especially wanted to make sure that this scenario is supported by Dojo.

Changed 9 months ago by bill

  • priority changed from high to normal

Changed 9 months ago by bill

  • description modified (diff)

See #5803 which may be a pre-req to this ticket.

Changed 8 months ago by doughays

test html file with complex margins/border/padding demonstrating patched dojo.coords function

Changed 8 months ago by doughays

  • cc doughays, bill added
  • keywords doughays, bill removed

After applying the patch, I succesfully tested the test4782.html file using WinXP on the following:
FF2.0.0.12, FF3.0beta4, IE6, IE7, Opera9.26, Safari3.0.4

Changed 8 months ago by peller

  • summary changed from IFrame relative offset problem in dojo.coords() to [patch][ccla]IFrame relative offset problem in dojo.coords()

Changed 8 months ago by doughays

possible fix - please review for inclusion in 1.1 - added optional includeFrame parameter to dojo.coords (to prevent breaking existing users) to compute absolute coordinates relative to document root instead of just to the nearest iframe (refreshed)

Changed 8 months ago by bill

  • milestone changed from 1.1 to 1.2

Move all milestone 1.1 tickets to 1.2, except for reopened tickets and tickets opened after 1.1RC1 was released.

Changed 8 months ago by guest

Perhaps this patch fixes the relative offset problem, but tooltips still do not correctly appear inside the IFrame, as demonstrated here: 

<html>

<head>

<style type="text/css">

  @import "dijit/themes/tundra/tundra.css";

  @import "dojo/resources/dojo.css"

</style>

<script type='text/javascript'

djConfig='isDebug: true, usePlainJson: true' src='dojo/dojo.js'></script>



<script type='text/javascript'>

dojo.require("dijit.Tooltip");



dojo.addOnLoad(function init() {

  window.frames["frm"].document.write("<html><body><div id='tip0'>hover</div></body></html>");

  var id = window.frames["frm"].document.getElementById('tip0');

  var c = dojo.coords(id);

  console.log("x: " + c["x"] + "  y: " + c["y"]);



dojo.doc = window.frames["frm"].document; // HACK

var tip0 = new dijit.Tooltip({label:"programmatically created tooltip", connectId:["tip0"]});

dojo.doc = document; // ENDHACK



});

</script>

</head>

<body class="tundra">

  <iframe name="frm" id="frm" width="300" height="300" frameborder="0"

    scrolling="yes" style="position:absolute;left:200px;top:200px;"></iframe>

</body>

</html>

It seems like all the widgets would need to be updated to use Doug's patch? Perhaps a new bug should be opened for this...

Changed 8 months ago by doughays

  • description modified (diff)

I'm beginning to think that instead of going all the way back to the root window, the default behavior should go back until the "dojo" window is encountered by default (in case that dojo is loaded in an iframe). Instead of a optional third parameter being boolean, it could be a window reference to stop on if the default is not desired. I'll code this up to see if it behaves better and w/o changing existing uses of dojo.coords.

Changed 8 months ago by liucougar

that is basically what I implemented in dojo.html.getAbsolutePositionExt for dojo 0.4

see http://trac.dojotoolkit.org/browser/trunk/src/html/util.js#L49

Changed 2 months ago by bill

  • milestone changed from 1.2 to 1.3

move 1.2 bugs to 1.3

Changed 19 hours ago by bill

  • milestone changed from 1.3 to future
Note: See TracTickets for help on using tickets.