This project is archived and is in readonly mode.

#462 ✓duplicate
Dorian

Positioning through 'domready' event in WebKit

Reported by Dorian | November 7th, 2008 @ 04:57 PM | in 1.3.0 rc2 (closed)

I have some very strange and random errors occurring in webkit browsers(safari/chrome as far as I know) when viewing the site I am working on. They are all related to positioning and everything works pretty close to perfect in all other browsers(IE 6 & 7, and Mozilla). I've tried revising the script a gazillion time to do the same things, but nothing seems to fix these random miscalculations of positioning. most of the bugs are resolved when resizing because specify that it runs the methods again every resize so the positions change with the window size since I had to do it all absolutely. please see www.zachys.com in safari regarding the problem. may have to reload the page a few times before bugs show up. any suggestions on how to get around the problems would be good, if you can't fix it.

Comments and changes to this ticket

  • Alcmene

    Alcmene November 15th, 2008 @ 09:15 PM

    • Tag set to position, positioning, webkit

    GOT IT ! :D That's true, there's a problem in positioning with Webkit. It's not due to the evolutions of MooTools, but only from WebKit : I had a site using an MooTools 1.2b2 with 1.1 compatibility that worked without any problems on June. I didn't work again on it until last week. That's where I discovered that there was this problem (after having spent some time getting my classes working with MooTools Core 1.2.1/More 1.2). So well, here are my conclusions : the problem happens because Webkit fires the 'domready' event too early with complex layouts. Here is a full test set.

    I also tried images with and without alpha, full-sized image or images that were specified a size through CSS… No changes.

    Hope that helps :)

  • Alcmene

    Alcmene November 15th, 2008 @ 09:19 PM

    Dumb thing escapes too many characters… You have to unescape the tilde and the %20 in the URL, in order to get : http://www.polytech.unice.fr/_ti... , replacing everything between underscores with the correct character.

  • Alcmene

    Alcmene November 16th, 2008 @ 10:36 AM

    • Title changed from “positioning in safari/chrome/webkit” to “Positioning through 'onload' event in WebKit”
    • Tag changed from position, positioning, webkit to onload, position, positioning, webkit

    Well, after all, that may be normal… I mean, the DOM being ready doesn't mean the layout itself is actually ready for positioning calculations, does it ? Problem is, Webkit is the only one to have this behaviour…

    A workaround is, obviously, to delay the execution of positioning calculations until the 'load' event is fired, for Webkit only. From the way the domready function is written, I don't think you can do anything about it in MooTools, because the DOM is ready when document fires the "DOMContentLoaded" event. Maybe you can find a way to change the positioning calculation algorithm ?

  • Alcmene

    Alcmene November 16th, 2008 @ 10:38 AM

    • Title changed from “Positioning through 'onload' event in WebKit” to “Positioning through 'domready' event in WebKit”
    • Tag changed from onload, position, positioning, webkit to domready, position, positioning, webkit

    Sorry, I put 'onload' instead of 'ondomready' in the title & tags. Too bad one can't edit his post.

  • Dorian

    Dorian November 17th, 2008 @ 08:54 AM

    Thanks a lot, I can definitely do that. I'll try it tuesday and get back to you.

  • dc

    dc November 20th, 2008 @ 04:52 PM

    I pretty much encountered the same problem for different large projects that I have worked in. This forced me to switch "domready" to "load".

    It would be very helpful if this was ever fixed. Whether in WebKit or Mootools position calc.

  • Dorian

    Dorian November 21st, 2008 @ 04:11 PM

    Yeah I tried it, it looks like it works still a slight miscalculation here and there but you can hardly tell. thanks. how about a layoutready event? lol

  • Dorian

    Dorian December 7th, 2008 @ 05:57 PM

    I guesss those miscalculations I noticed were from another bug that I've found on the site. It has to do with the Accordion that I'm using which seems to be throwing off the calculation of width in the main navigation in firefox and safari. I guess this should be closed now and maybe open another one for this other bug.

  • Dorian

    Dorian December 7th, 2008 @ 09:42 PM

    I figured out that bug and it has to do with absence or presence of the scroll bar on the side. I thought it had to do with accordion because the navigation bar would fall out of place when opening the accordion, but it was the fact that opening a long accordion adds scrollbars to the window. It was clear when I noticed that the offset only happened when loading pages with scrollbars or no scrollbars depending on the browser. It seems like a bug, since I will have to factor the width of the scroll bar in calculating the placement of my elements (by setting the left css property of one element to the getPosition().x of another), depending on its presence, or simply make sure that it always shows to keep positioning consistent in firefox and safari. so far I have only seen this bug in calculations performed in the domready event, but I'll comment if the doing them in the load event changes it.

  • Alcmene

    Alcmene December 8th, 2008 @ 10:00 AM

    I just made a new test page. The result is that you're correct with the latest nightly build of WebKit, but not with the latest stable Safari (3.2.1) : even without scrollbars, the positioning is still defective.

  • Dorian

    Dorian December 8th, 2008 @ 10:14 PM

    ok good to know I was right about something. do you see the behavior in firefox also? I forgot to mention I was only able to see this when viewing www.zachys.com at a high resolution or small text size. BTW your link doesn't work. should I open this in another thread?

  • Alcmene

    Alcmene December 9th, 2008 @ 09:55 AM

    No, as said earlier, this behavior is seen only with WebKit. My link has to be corrected the same way as the previous ones : replace "%7E" with a tilde, and "%20" with a space, LightHouse escapes too much…

    should I open this in another thread? Well, I don't see any reason for this…

  • Dorian

    Dorian December 9th, 2008 @ 12:41 PM

    that link has %2520 in the middle of webkit and positioning, so that confused me, but i figured out i just needed to change it to %20. thanks.

  • fakedarren

    fakedarren February 8th, 2010 @ 04:42 PM

    • State changed from “new” to “hold”
    • Assigned user changed from “Valerio” to “fakedarren”
    • Milestone changed from 2.0 to 1.3.0 rc2

    Sorry for the (long) delay getting back to y'all about this. Positioning and webkit have improved significantly since the ticket was raised. Should now be resolved - will have to put test case together.

    Unless one of you can help me by making an example in mooshell - http://mootools.net/shell.

  • Alcmene

    Alcmene February 8th, 2010 @ 05:27 PM

    Here you are, I have more or less copy-pasted the code I gave as example earlier: http://mootools.net/shell/kL4G6/ .

    Sorry for this lame code, I have very tight deadlines coming to their end. Don't bother with it too much if you don't get it working straight away.

  • gonchuki

    gonchuki September 9th, 2010 @ 08:17 AM

    • Milestone order changed from “0” to “0”

    looks like a duplicate of #912 as of the description of the issue.

  • Christoph Pojer

    Christoph Pojer September 9th, 2010 @ 11:08 PM

    • State changed from “hold” to “duplicate”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins

Pages