42.28 KB, image/png
74.20 KB, image/png
hmm. the loadgroup should prevent that, should it not?
I have just tried to insert an alert() to the beginning of the onLoad event handler. It has proven my suspicion about the premature executing of onLoad event handler: The images referenced in XHTML were loaded before the alert(), which is correct, but the background images declared in the CSS file were loaded after the alert(), i.e. after running onLoad, which for sure is NOT correct.
oh, is this bug only about background images?
Not only background images, but inclusive background images (declared in separate CSS file). The real problem is that not every necessary file is downloaded before the onLoad event is fired - CSS files (and background images declared within them) are not. This really is a severe problem. onLoad event handlers may (as in my case) depend on attributes declared in CSS files. The second issue I have just discovered is that background images declared in CSS files are not saved when using Save As... | Web page, complete. And the third issue I have (as a side effect) just discovered is that XHTML (even if completely validated without any error) is saved as an invalid XHTML - <meta> tags are not closed for example. But these two are for separate bug reports (if not already reported).
(In reply to comment #4) > Not only background images, but inclusive background images (declared in > separate CSS file). There's a major difference between the two cases. background images do (as far as I can tell) intentionally not delay onload (compare the comment at http://lxr.mozilla.org/seamonkey/source/layout/style/nsCSSValue.cpp#380). But that's different in the case of CSS files. > The real problem is that not every necessary file is > downloaded before the onLoad event is fired - CSS files (and background images > declared within them) are not. This really is a severe problem. onLoad event > handlers may (as in my case) depend on attributes declared in CSS files. Yeah, but the two cases are quite distinct. > The second issue I have just discovered is that background images declared in > CSS files are not saved when using Save As... | Web page, complete. bug 115107 > And the third issue I have (as a side effect) just discovered is that XHTML > (even if completely validated without any error) is saved as an invalid XHTML - > <meta> tags are not closed for example. That probably was not an XHTML page (i.e. it was probably sent as text/html)
So... I can't reproduce this bug with the steps in comment 0. What do I need to do to reproduce the problem? As biesi said, onload will fire before background images (CSS or not) are loaded, but should be firing after the CSS itself is loaded, and does over here.
Created attachment 189941 [details] http://obec-krestanu.cz loaded with a blank browser cache After loading http://obec-krestanu.cz with a blank cache this (incorrect) screen appears. This is done only in Mozilla/Firefox using a slow connection (GPRS / dial-up / EDGE). Sometimes it can be reproduced on a broadband too, but such case is quite rare. See the next attachment or any of up-to-date MSIE/Opera/Konqueror for a correct display of this page. After clicking into "Address" input field and pressing Enter while this incorrect screen is displayed, the page is displayed correctly also in Mozilla/Firefox. So it seems to be a bug while not having the CSS file loaded - After storing it in browser cache, everything is OK. After clearing the browser cache, the problem occurs again (slow connections only!).
Created attachment 189943 [details] The correct display after Enter pressed in Address input field When the page is displayed incorrectly, clicking into "Address" input field and pressing Enter helps to get it displayed correctly.
Is this a problem with Deer Park alpha 2?
(In reply to comment #10) > Is this a problem with Deer Park alpha 2? I can't reproduce this bug with Deer Park alpha 2 anymore. At the same time, I do can reproduce this bug with Firefox 1.0.6. So it seems to be fixed in 1.1a2. When should the 1.1 release be available?
based on reporters comment --> wfm See the Firefox roadmap for future releases (it will be 1.5): http://www.mozilla.org/projects/firefox/roadmap.html
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.