Opened 9 years ago

Closed 7 years ago

#17063 closed defect (invalid)

domReady! fires before CSS applied (Chrome)

Reported by: Radim Kolář Owned by: Rawld Gill
Priority: undecided Milestone: 1.11
Component: Core Version: 1.8.3
Keywords: Cc: James Burke
Blocked By: Blocking:


<script src="//"></script>
<img src="images/novy-hlodac.png" id="hiddenlogo"/>
require(["dojo/fx", "dojo/dom", "dojo/dom-geometry", "dojo/dom-style", "dojo/domReady!"], function(fx, dom, geom, style) {
    // get target original location of flying logo
    var obrazek = geom.position(dom.byId("hiddenlogo"), true);
    var hlodacx = obrazek.x;
    var hlodacy = obrazek.y;

#hiddenlogo {
  display: block;
  margin-left: auto;
  margin-right: auto;
  width: 200px;
  height: auto;
  visibility: hidden

In firefox 20, location displayed is about 496/8. image auto margins left and right are excluded, you will get exact location of image - this is what i want.

In chrome 26, location printed is 8/23, image is still centred correctly

Attachments (1) (161.4 KB) - added by Radim Kolář 9 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 9 years ago by bill

#17064 is a duplicate of this ticket.

comment:2 Changed 9 years ago by bill

Component: CoreHTML
Owner: set to Eugene Lazutkin

I'm confused, why are you talking about the image being centered? Does that #hiddenlogo CSS center the image because of the "auto" settings for margin?

comment:3 Changed 9 years ago by Radim Kolář

Yes, it centers image because of auto margin settings. In firefox you will get coordinates of real image, while in chrome you will get coordinates of image + margins.

comment:4 Changed 9 years ago by Radim Kolář

I added JQuery script to page, just after dojo script.

    var obrazek = $("#hiddenlogo").offset();
    var hlodacx = obrazek.left;
    var hlodacy =;
    alert("jquery: "+hlodacx+"/"+hlodacy);

In firefox, both returns good results. In chrome jquery script returns wrong position and dojo returns a good one.

This means that this bug is timing dependant and chrome allows dojo/domReady! to pass before document is fully rendered. Adding jquery script with alert box gives chrome enough time to place dom elements at their final positions before user clicks on alert and then dojo returns good result like in firefox.

Conclustion: bug is in chrome and domReady.js. Please change bug title.

comment:5 Changed 9 years ago by Radim Kolář

Tested 1.9.0rc1 dojo and bug is still there. There is small chance about 1:25, that it returns in chrome good value. Chrome seems to render document on different thread then executing javascript and sometimes, its rendered fast enough before javascript execution hits dom query.

comment:6 Changed 9 years ago by bill

Component: HTMLCore
Owner: changed from Eugene Lazutkin to Radim Kolář
Status: newpending
Summary: dom-geometry position works differently in Firefox and ChromedomReady! fires before CSS applied (Chrome)

Can you attach a real test case using the attach file button? Your code snippet in the description doesn't make any sense because the CSS is not inside <style>.

The solution is probably just that you need to put that CSS in your <head> section, but let's look at your example first.

comment:7 Changed 9 years ago by Radim Kolář

Status: pendingnew

If i put CSS into HTML head, then bug is not triggered. CSS needs to be in separate file, linked from head. To make this bug reproducible, put CSS into PHP script and do 5 second delay before sending CSS to browser.

comment:8 Changed 9 years ago by bill

Status: newpending

You need to attach a real test case using the attach file button. You can attach two files if you need to.

Changed 9 years ago by Radim Kolář

Attachment: added

comment:9 Changed 9 years ago by Radim Kolář

Status: pendingnew

Attachment ( added by ticket reporter.

comment:10 Changed 9 years ago by Radim Kolář

I can not get timings required to reproduce my issue, but in attached zip you will see that animation starts playing in both FF and chrome while images are not loaded yet.

comment:11 Changed 9 years ago by bill

Cc: James Burke added
Owner: changed from Radim Kolář to Rawld Gill
Status: newassigned

I see, thanks for the test case.

Rawld, I guess this is expected behavior? It's one of the reasons why we are talking about making a dojo/css! plugin.

Also CC'ing James since domReady! is sort of a universal concept across AMD loaders (even though dojo/domReady! can do whatever it wants since it's in the dojo/ namespace).

comment:12 Changed 9 years ago by Radim Kolář

is not possible to make hook into document.onload= in some plugin?

comment:13 Changed 9 years ago by James Burke

If the question for me is "is it typical for domReady to fire before all assets are loaded", then yes, because that kind of module normally binds to DOMContentLoaded, and not window.onload.

If the original poster wanted to wait for window.onload, then best to make a separate module that does that. It could be copy/pasted from the domReady one, but just change the event listening to the load event instead of DOMContentLoaded.

comment:14 Changed 7 years ago by dylan

Milestone: tbd1.11
Resolution: invalid
Status: assignedclosed

Closing this as it evolved into #17140

Note: See TracTickets for help on using tickets.