FF3 page load

Please indicate a specific page and script with which this happens.

Replying to aranti..@gmail.com:

Please indicate a specific page and script with which this happens.

for example at www.ogame.org if you use the so called "ogame-skript" from http://ogame-skript.com/org/

i found the reason for this on my own.

this only appears if the script has to access a "html frame". if you just access the page within this frame everything is ok.

Glad you've solved your problem. What specifically do you mean by an "html frame"?

I don't solved my problem... I just figured out why it happens...

let's say you got a page called "index.htm" with the following html code

<frameset rows="*,0,0" frameborder="no" border="0" framespacing="0"> <frame name="mainframe" src="main.htm" frameborder="0" scrolling="auto" noresize> </frameset>

and the greasemonkey skript should do chances to the main.htm (which is included into a "html frame"). what now happens is:

1.) index.htm is loaded
2.) main.htm is loaded
3.) index.htm and main.htm are rendered and shown on screen
4.) greasemonkey executes the script that should change main.htm
5.) main.htm is rerendered and shows up on screen.

with ff2 greasemonkey executed the script after the main.htm was loaded and before it was rendered the first time. with ff3 the page is first shown without any chances and then the corrected version.

but try it out on your own. create a game account at http://www.ogame.org and use http://www.ogame-skript.com/data/language/ogameskriptuk.user.js and http://www.ogame-skript.com/data/org/gm/ogameskript.user.js and log into the game. you will see the page is rendered and shown twice. now right click onto "Overview" (left menu) and open the link in a new tab (at this moment you leave the html frame) and then the twice loading problem is gone.

I think you would find (if you research the issue deeply enough) that the problem you encounter is caused by optimizations in Firefox 3, making it fast enough to complete a rendering pass where Firefox 2 did not, before the DOMContentLoaded event is fired (which is what trigs Greasemonkey scripts to run).

Changing such race conditions is beyond the scope of Greasemonkey.

after some more testing with the "workaround" I can't agree with you oyasu. If this would be true, a page with less content on it would case this error, but the truth is that only pages with much content (table with more then hundred lines for example) are still showing up this error even with the "workaround". if optimizations in ff3 would be the reason for this (that it's fast enought now) I would guess the error should happen on low content pages and not on pages with much content.

I can pretty much ascertain that no GM developer will touch a testcase that is a 28 kilobyte script to be run on a web based game requiring account creation and contains who knows how much HTML, subject to change at the whim of the game's developers.

Assuming you want to make progress on the issue, I would suggest reducing the problem the minimum amount of HTML + javascript which triggers the issue and -- assuming the workaround you refer to bypasses the problem for that setup, a version with it applied.

Post URLs to both here (if you have nowhere to host it, google pages lets you upload your test cases for free), and chances are better the ticket will not just sit idle.

I second Johan. I'm not going to touch this bug with a 10 foot pole without a clean, easy test case. I'm not going to install a 300k+ script and register for an account at some site I've never heard of before.

Furthermore, as described, the "bug" doesn't make enough sense for me to believe it really exists. It's most likely a logical side effect of the difference in performance between FF2 and FF3, combined with a misunderstanding of how the various things at play work.

People, your reasoning is unbelievable. Just look at your words.

Every single userscript i use loads after the page fully load. Even though it is mostly annoying for browser games, it is annoying everywhere. There http://userscripts.org/scripts/show/29201 you need a gmail account though ;o (if anyone thinks the developers won't touch this bug because they need a gmail account, be a little helpful and find a script, which adds visible contentr to a page)

and if anyone is thinking this is just a minor issue, consider this: THERE ARE THOUSANDS OF PEOPLE PLAYING BROWSER GAMES. the main reason they use greasemonkey is because it used to load the scripts while the first rendering of the site. Now it doesn't do it anymore.

If the greasemonkey is going to have custom option for slower site loading, a bit like FF2, go for it if it bring script loading within first site rendering back again.

If among those there is even just the one with the competence, time, drive and will to get on top of this issue, they are naturally encouraged to do so. GM development, like most open source work, happens primarily out of self-interest, and comparably less so for fuzzy goals like abstracting away all changes in Firefox happening under our feet from user scripts.

Changes in Firefox happen. User scripts break. Tickets asking more of GM maintainers than they would even bother looking at will end up in WONTFIX or INVALID states. The alternative is that this ticket system overflows with tickets of maybe-problems, which nobody will ever get the time or will to follow up -- which is useless.

No amount of however passionately heartfelt grief will change this, so if you care about this issue you are encouraged to re-read above what you can do yourself to change this. The path lies open to anybody. All that I and Anthony have stated is that neither of us will tread on it out of our own self-interests. We encourage you to feel differently, and act accordingly. That does not include arguing, hoping to persuade us to feel differently about it.