494874 - Content flickers into view and then disappears

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Christian Sejersen]

Attachment: Expected result

Going to this URL: http://people.mozilla.com/~csejersen/fennec/req.html causes the content to appear briefly (flickers) and then disappear again. See screen-shots for shiretoko and the expected behavior.

Comment 1

[Christian Sejersen]

Attachment: Result on shiretoko

Comment 2

[Ria Klaassen (not reading all bugmail)]

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7d9bea3fa51a&tochange=089a09bb1969

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

A smaller testcase would be great, but I'm strongly inclined to guess that this is a regression from bug 461555. Though it'd be the first that we hear of it if so.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Ria: that's a mozilla-central range; does that mean this also happens on trunk?

Jonas: yeah, I suspected the same bug from that range. Can you look at Christian's page and see if he's, perhaps, patterned his JS in a way that runs afoul? Or Christian, can you work on a minimized testcase?

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

(restoring flags while bitching about bugzilla)

Comment 6

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #4)

Yes, I tested only trunk (on Windows).

Comment 7

[Christian Sejersen]

Here is a somewhat simpler testcase: http://people.mozilla.com/~csejersen/fennec/req-simpler.html

Comment 8

[Michael Ryan]

I can reproduce this on 3.0.10 if I cut down the size of bugs-2009-05-26.js to 65536 bytes or less. Race condition?

Comment 9

[Boris Zbarsky [:bzbarsky]]

Certainly sounds like an internal race in the page's code, but we should understand whether the change in who wins the race is something that could affect web compat in cases that don't race-by-design.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Does this still need to block if it's not a regression?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Mike, see comment 9.  The race on this page is not a regression, sounds like, but we need to figure out whether we inadvertently changed script execution order in cases that didn't use to race....

We do still need a testcase, btw.  The last file here is still using this huge framework.

Comment 12

[Michael Ryan]

Attachment: Testcase

Here is a somewhat reduced testcase. exhibit-api.js still needs to be reduced. The page shows up blank in the latest 1.9.1 nightly but shows up fine in 3.0.10. There are two strange things happening in 3.0.10 though, as you will see in the source code.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Note that exhibit-api.js dynamically pulls in a few dozen other js files....

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

My gut feeling, based on comment 12 and the fact that we haven't seen any other issues from bug 461555, which just aligned us with IE behavior, is that this is a website bug.

But it'd be very nice to make sure that is the case.

But i'm fine with not blocking on this, though I'm gonna keep trying to figure out what's going wrong here.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Per comment 14, unblocking. If we start getting more dupes, we can re-evaluate.

Comment 16

[Michael Ryan]

Okay, the basic problem here is that the original webpage is using "autocreate=false" rather than "autoCreate=false". This causes create.js (http://static.simile.mit.edu/exhibit/api-2.0/scripts/create.js) to be loaded when it really shouldn't be. The script on this page resets the state of the page.

Still looking into whether everything is being loaded in the right order...

Comment 17

[Michael Ryan]

Attachment: Reduced testcase

Comment 18

[Boris Zbarsky [:bzbarsky]]

Interesting.  In Fx2, that testcase shows:

  DOMContentLoaded init

with or without the alert.  That's also the behavior I see in Safari.  In Fx3, as the testcase says, one gets "DOMContentLoaded init" with the alert and "init DOMContentLoaded" without.

On trunk, as the testcase says, one always gets "init DOMContentLoaded".

The change from Fx2 to Fx3 likely had to do with switching to firing DOMContentLoaded async, and with the fact that we processed events while the alert is up.  On trunk, I bet we delay the DOMContentLoaded while the alert is up (because we generally delay various stuff while alerts are up now), so get the output.  But sicking should know more.

Given this testcase, I think the page has an inherent race, but it'd be interesting to see what the HTML5 spec has to say about the ordering here.

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

With regards to the problem described initially in this bug (testcase in comment 0 failing), the alert thing is sort of a red herring since that testcase doesn't have an alert. Right?

Michael: I assume the alert was something you put in while debugging, right? Not something that existed in the original page.


I'm actually surprised that we in 3.5 is not firing the DOMContentLoaded event while the alert is up. I thought we were only affecting UI events as well as timers. Smaug, DOMContentLoaded should be able to fire fine while an alert() is up, right?


In any case, I'm leaning towards that this but is a WONTFIX. The page is inherently racy. Nothing says that the dynamically inserted script wouldn't run somewhere in the middle of the markup due to a packet boundary or some such.

Comment 20

[Michael Ryan]

Attachment: init.js (for testcase)

Comment 21

[Michael Ryan]

Attachment: Testcase without alert

This demonstrates something a bit closer to what the original page was like. The original page did not use an alert - it was just a handy way to replicate the delay caused by the script load.

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Oh, I just realized why DOMContentLoaded gets delayed and doesn't fire even during the alert().

With the new code I wrote to support defer, I tried to minimize the risk of exactly the type of race conditions that this testcase has. We now never fire DOMContentLoaded until until the scriptloader has run all pending scripts. So when we're done parsing the page, we unblock all deferred scripts, and then let things take run its course until the scriptloader is totally empty, then we drop the parser and fire DOMContentLoaded.

So it has nothing to do with suspend/suppress-events work that Smaug did.

So things work as designed, and according to what IMHO makes the most sense and results in the least risk of races.

Marking WONTFIX for now, we can reopen if it turns out that this completely breaks the web :)