onLoad event fired before a CSS file loaded

RESOLVED WORKSFORME

Status

()

Core
DOM: Events
--
major
RESOLVED WORKSFORME
13 years ago
13 years ago

People

(Reporter: MAno F., Unassigned)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
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
hmm. the loadgroup should prevent that, should it not?
(Reporter)

Comment 2

13 years ago
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?
(Reporter)

Comment 4

13 years ago
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.
(Reporter)

Comment 7

13 years ago
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!).
(Reporter)

Comment 8

13 years ago
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.
(Reporter)

Comment 9

13 years ago
(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.
Is this a problem with Deer Park alpha 2?
(Reporter)

Comment 11

13 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

13 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
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.