Opened 8 years ago
Closed 5 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: |
Description
<body> <script src="//ajax.googleapis.com/ajax/libs/dojo/1.8.3/dojo/dojo.js"></script> <img src="images/novy-hlodac.png" id="hiddenlogo"/> <script> 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; alert(hlodacx+"/"+hlodacy); </script> #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)
Change History (15)
comment:1 Changed 8 years ago by
comment:2 Changed 8 years ago by
Component: | Core → HTML |
---|---|
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 8 years ago by
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 8 years ago by
I added JQuery script to page, just after dojo script.
<script> var obrazek = $("#hiddenlogo").offset(); var hlodacx = obrazek.left; var hlodacy = obrazek.top; alert("jquery: "+hlodacx+"/"+hlodacy); </script>
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 8 years ago by
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 8 years ago by
Component: | HTML → Core |
---|---|
Owner: | changed from Eugene Lazutkin to Radim Kolář |
Status: | new → pending |
Summary: | dom-geometry position works differently in Firefox and Chrome → domReady! 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 8 years ago by
Status: | pending → new |
---|
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 8 years ago by
Status: | new → pending |
---|
You need to attach a real test case using the attach file button. You can attach two files if you need to.
Changed 8 years ago by
Attachment: | hlodac5.zip added |
---|
comment:9 Changed 8 years ago by
Status: | pending → new |
---|
Attachment (hlodac5.zip) added by ticket reporter.
comment:10 Changed 8 years ago by
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 8 years ago by
Cc: | James Burke added |
---|---|
Owner: | changed from Radim Kolář to Rawld Gill |
Status: | new → assigned |
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 8 years ago by
is not possible to make hook into document.onload= in some plugin?
comment:13 Changed 8 years ago by
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 5 years ago by
Milestone: | tbd → 1.11 |
---|---|
Resolution: | → invalid |
Status: | assigned → closed |
Closing this as it evolved into #17140
#17064 is a duplicate of this ticket.