585373 - In an infinite scheme, a new smaller frame opens once the previous one is loaded

Status: RESOLVED DUPLICATE of bug 593174

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

Description

[Scoobidiver (away)]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3) Gecko/20100805 Firefox/4.0b3
Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; rv:2.0b3) Gecko/20100805 Firefox/4.0b3

In FF 4.0b3, the click on one map location opens a frame window.
Once it is loaded, a new small one is opened inside it. And so on ....

In FF 3.6, only one frame window is opened = expected result

Reproducible: Always

Steps to Reproduce:
1. Go to ref URL
2. Click on one of the map blue square
3. Infinite russian doll like frame window display

Comment 1

[j.j.]

Mozilla/5.0 (Windows NT 5.1; rv:2.0b4pre) Gecko/20100806 Minefield/4.0b4pre

I can reproduce this on XP

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Regression range would be great.

Comment 3

[Benjamin Smedberg]

I can't reproduce, and there's no testcase. Please renominate if we can find a specific regression.

Comment 4

[Scoobidiver (away)]

Attachment: Screenshot

Comment 5

[Scoobidiver (away)]

The testcase is in comment 0.
Here is the regression range :
3.7a1 20100201 works
3.7a1 20100202 fails

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #5)
> The testcase is in comment 0.
> Here is the regression range :
> 3.7a1 20100201 works
> 3.7a1 20100202 fails

Can you please tell us the changeset id's which you can find in about:buildconfig? I can still reproduce it with a current trunk build.

Comment 7

[Scoobidiver (away)]

3.7a1 20100201 cset: http://hg.mozilla.org/mozilla-central/rev/f57b95afb57e
3.7a1 20100202 cset: http://hg.mozilla.org/mozilla-central/rev/f557921b88a7
So the regression range is :
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f57b95afb57e&tochange=f557921b88a7

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Does disabling html5 for the second build change anything for you?

Comment 9

[Scoobidiver (away)]

> 3.7a1 20100201 works
> 3.7a1 20100202 fails
> Does disabling html5 for the second build change anything for you?
html5.enable is set to false by default for these 2 builds.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #7)
> So the regression range is :
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f57b95afb57e&tochange=f557921b88a7

Roc, do you have an idea which of those patches could have been caused this regression?

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bug 500328 maybe?

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #3)
> I can't reproduce, and there's no testcase. Please renominate if we can find a
> specific regression.

It's easily to reproduce given the specified URL. Asking again for blocking.

(In reply to comment #11)
> Bug 500328 maybe?

Henri or Justin, could that bug be the reason for the regression?

Comment 13

[Justin Lebar (not reading bugmail)]

I'd be pretty surprised if bug 500328 caused this particular regression, but then again, it's caused more unlikely-seeming regressions.  I'll bisect.

Comment 14

[Justin Lebar (not reading bugmail)]

Lo and behold, it is indeed bug 500328.

Comment 15

[Justin Lebar (not reading bugmail)]

It would be nice to have a small testcase or a better idea of what's going wrong on this page.  It's pretty complex.

Comment 16

[j.j.]

I tried twice to create a local testcase without success,
even failed to reproduce the bug after saving the complete page locally (including styles and scripts).

Comment 17

[Johnny Stenback (:jst)]

Justin, can you investigate? If you won't have time in the next couple of weeks, please let me know.

Comment 18

[Justin Lebar (not reading bugmail)]

Realistically, I don't think I'll have time in the next few weeks to figure out what's going on here.

Comment 19

[Justin Lebar (not reading bugmail)]

I'm not making a lot of progress figuring this out.

The bug doesn't manifest consistently in debug builds.  Additionally, sometimes the hovertext inside the flash applet shows up as "undefined" in my debug build; when this happens, I can't load the inner window at all.

It strikes me as possible that we're tickling a race condition in the site.  But it's at least as likely that there's a real bug in FF.  I'm just not sure how to find it.

Scoobidiver, are you able to get a smaller testcase?

Comment 20

[Scoobidiver (away)]

> Scoobidiver, are you able to get a smaller testcase?
You can have a lot of testcases here:
http://www.euromediterranee.fr/carte-interactive.html#/accueil/
But there are all similar.

Comment 21

[Justin Lebar (not reading bugmail)]

(In reply to comment #20)
> > Scoobidiver, are you able to get a smaller testcase?
> You can have a lot of testcases here:
> http://www.euromediterranee.fr/carte-interactive.html#/accueil/
> But there are all similar.

Can't say that helps too much.  :)

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Hm all the testcases from this domain are now working for me with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101122 Firefox/4.0b8pre ID:20101122031042

Comment 23

[Justin Lebar (not reading bugmail)]

Well, this is strange.

Changeset f57b9, the beginning of the regression range in comment 10, now segfaults on the site.  So do the changesets right before pushstate (afffc13) and right after (5a2f46811).

I could have sworn this was working before -- it must have been, since I bisected that regression range!

I also went through in tip and commented out most of the pushState code; the bug still reproduced.  I'm going to try again, because I find this whole thing a little unbelievable.

Comment 24

[Justin Lebar (not reading bugmail)]

Well, I still don't know why the old revisions crash.  But this is fixed by my patch in bug 593174, which fixes errant behavior introduced in bug 500328 with respect to referrers.  I have a patch in that bug that's awaiting review.