I'm running into a strange problem.
Whenever I hit the update button in my cart, I get a quick flash of the the cart without any CSS.
It's really jarring because I've changed the cart background to black, so it flashes the screen white. I don't want to give anyone a seizure. :P
I have no idea what could be causing this, so if anyone has any idea, Id really appreciate it.
Thanks!
It's only on 0.5.1 and 0.6.0, so I have to think the jquery update is the culprit...
Error: document.body is null
Source File: ...../v/0.6.0/jquery-1.3.2.min.js
Line: 19
It might be a jQuery related issue but we've yet to pinpoint the problem. Definitely frustrating. Other research I did a while back seemed to point to a bug in FireFox where it would start to evaluate the page and run into some kind of error and reevaluate the page again. Not sure if that makes sense either. We'll be devoting some solid research time into this bug soon because it's definitely annoying.
So I have been wrong. Once
Back on topic... Yes, we're definitely aware of the issue. My current thought is that it's related to memory limits on some regular expressions we're doing, but that also seems odd. Part of the problem is that it happens so inconsistently. Does anybody have a site that this is happening on consistently? All of my test sites seem to be fine at the moment, unfortunately.
From first glance, I'm pegging it to the loading of /themes/standard/styles.css in the popup. Is it being loaded later in the file or something like that? Have you tried embeding that stylesheet inside the popup inline, instead of as a linked stylesheet?
[edit]Altering the style call from being linked to inline in the template fixed it completely for me, I've updated the test suite with two versions that work (vanilla and with overlay).
What I am definitely _not_ seeing is a flash on the cart page when it's loaded on its own, as opposed to inside a modal iframe. @bjbk are you seeing the flash outside of the *box?
To answer your other question though, I am seeing the flash on the cart page just as much as I'm seeing it inside the modal box in the vanilla versions (I've added a cart link to the test to help). It could be that my connection speed is slower than yours, and so I see the naked stuff a little longer than you do though...
Alright, so it seems that flash you were seeing where the update/checkout buttons jumped around was because their inline element styles weren't being applied as soon as the embedded styles in the head were (not sure why...). I added one of the element styles of "display:inline-block;" to their embedded styles in the head, and there is no longer a visible jump. There is still a blank page on reload, but there is no style flash anymore. Checkout those last two versions and see what you get.
@brett: something else wierd I'm experiencing on the test site is that the cart information seems to carry across from the vanilla one to the inline styles one, but it doesnt carry back. For example, if I add a product to the vanilla version, and edit it to be three, and then add a product to the inline styles version, it will be four (no matter how many I had there). If I change the inline styles version to 2, and add another product to the vanilla version, it will be four as you'd expect. If I add another product to the inline styles version, now it is five. Actually, the two inline styles versions dont add products at all. If you keep adding a product, it doesnt keep adding products to the total quantities. I think I'm missing something obvious here...
As far as the mixing of carts go: If you're sharing a naked domain (example.com) with multiple subdomained stores like you are then the sessions get weird. You can use the 3ld javascript linked to from the wiki if you need. It's an issue of where the cookie is being set.
So... you're still seeing the _unstlyed_ flash on both modal and standalone? I definitely am not, but if you are then the modal isn't likely the issue... hrmph...
Huh. I think I might have just solved this... That'd be neato. We're testing. Unfortunately it involves moving some JS around in the <head> so it's not something we can do in v060, and it's not really something we can give to you all to see (since our dev environments are private)...
@bjbk or anybody else interested: The fix (at least, it seems to me to work thusfar in my testing) is to move the <script> element that starts with function fc_PreventCheckout() from after the </title> (after the jQuery load) to before the </body>. Moving the js that manipulates the DOM to after the CSS apparently makes Firefox behave a little more gentlemanly. At least, that's what I'm seeing so far, using the Throttle Firefox plugin (which seems a little buggy) to make it more pronounced. If anybody wants to copy off the HTML and experiment with their own carts please feel free, and let us know if you see the same result (loading without the FOUC).
I'm definitely going to try moving that js around! Thanks for the heads up.
<script type="text/javascript"> <!-- to remove the unstyled flash -->
$('html').addClass('js');
$(document).ready(function(){
$('html').removeClass('js');
});
</script>
And this to my .css: .js #flash {display: none;}
But I'm still getting the flash when making changes in the modal box. Where and how do I apply #flash to an element in the content? This is the page with the checkout template:
http://www.strikemodels.com/products/cannon-test/