Closed
Bug 298527
Opened 19 years ago
Closed 19 years ago
onLoad event fired before a CSS file loaded
Categories
(Core :: DOM: Events, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: manof, Unassigned)
References
()
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 I have a web-page (mentioned before), that uses a JavaScript with onLoad event handler. This JavaScript depends on a CSS file, that should be but is not (in FF only) loaded before this JavaScript executes. To be more specific: I use a <div> that should be as wide as browser window is (100%), and this is specified in the CSS file. The JavaScript in onLoad event handler uses the offsetWidth of this <div> to determinate width of the browser window and depending on this value sets the main layout table width to either 100% or (minimum width) 750px. Because the CSS file is not loaded before execution of this JavaScript, onLoad computes with a bad value and whole the page is displayed wrong. This happens just once - when the CSS file is not yet in cache. Then you must clear the cache to reproduce the bug. You also must have a slow connection to have the JavaScript executed before the CSS is loaded. Reproducible: Always Steps to Reproduce: 1. Use a very slow connection (dial-up fixed line (56 kbps) or GPRS. 2. Clear the browser cache. 3. Turn on JavaScript (if it is not turned on already) 4. Type http://obec-krestanu.cz/index_en.html in the address box and hit Enter. 5. To display the page correctly just click into addres box and hit Enter again. 6. To reproduce the bug, clear the cache, so the CSS file has to be loaded again. Actual Results: The content area of the web-page (white background) has minimum width (about 1 inch/3 centimetres). The area to the right of the content area is blank. Expected Results: The content area (white background) should cover whole the place between menu (on the left side) and right border of the browser window (or vertical scroll-bar). There should be no whitespace (with blue background) to the right of the content area. Windows 2000 SP4, also reproducible on Windows XP SP2 Build config: Build platform target i686-pc-cygwin Build tools Compiler Version Compiler flags $(CYGWIN_WRAPPER) cl 12.00.8804 -TC -nologo -W3 -nologo -Gy -Fd$(PDBFILE) $(CYGWIN_WRAPPER) cl 12.00.8804 -TP -nologo -W3 -nologo -Gy -Fd$(PDBFILE) Configure arguments --disable-ldap --disable-mailnews --enable-extensions=cookie,xml-rpc,xmlextras,pref,transformiix,universalchardet,webservices,inspector,gnomevfs,negotiateauth --enable-crypto --disable-composer --enable-single-profile --disable-profilesharing --enable-optimize --disable-debug --disable-tests --enable-static --disable-shared --enable-official-branding
Comment 1•19 years ago
|
||
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.
Comment 3•19 years ago
|
||
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).
Comment 5•19 years ago
|
||
(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)
Comment 6•19 years ago
|
||
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.
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!).
When the page is displayed incorrectly, clicking into "Address" input field and pressing Enter helps to get it displayed correctly.
(In reply to comment #6) > 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. See the attachments. It definitely seems to be a bug concerning loading of CSS files. I'm sure it's not about JavaScript, because problem persists also with JavaScript turned off. P.S.: sorry for the delay. I was on my vacation.
Comment 10•19 years ago
|
||
Is this a problem with Deer Park alpha 2?
Reporter | ||
Comment 11•19 years ago
|
||
(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?
Comment 12•19 years ago
|
||
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
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•