Zac C (:zac) Reporter
	Description • 11 years ago

Page seems to be infinitely loading/reloading. It appears to get to the page load event and then start again.

STR:
1. Load nightly
2. Go: http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html
3. Sit back and observe

Replicated on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130402 Firefox/23.0 ID:20130402030843 CSet: aae004a3c5d9

(also some other colleagues replicated it on Mac/Nightly but I didn't grab their build IDs. Appears to be 23.0 only.)

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 1 • 11 years ago

I see this on Aurora 22 as well, but not Beta.

Zac, are you willing to hunt down a regression range on nightlies?

	Zac C (:zac) Reporter
	Comment 2 • 11 years ago

Sorry Boris I don't have the time or infrastructure setup to narrow the range right now.

I can confirm it still replicating today:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130421 Firefox/23.0 ID:20130421031002 CSet: 0d50cb959c46

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 3 • 11 years ago

You don't really need infrastructure.  The ftp server is just there....

Time I can understand.  ;)

	Alice0775 White
	Comment 4 • 11 years ago

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/6d587302645a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130316 Firefox/22.0 ID:20130316145831
Bad:
http://hg.mozilla.org/mozilla-central/rev/0b052daa913c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130316 Firefox/22.0 ID:20130316160554
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6d587302645a&tochange=0b052daa913c

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/22b3fa2e22c1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130314 Firefox/22.0 ID:20130314223435
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/cfa16b1c70a3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130314 Firefox/22.0 ID:20130314223935
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=22b3fa2e22c1&tochange=cfa16b1c70a3
Triggered by: Bug 850517

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 5 • 11 years ago

Alice, thanks!

I guess now we need to figure out whether the problem is the dynamic updating or the not overriding things... :(

	Zac C (:zac) Reporter
	Comment 7 • 11 years ago

Thanks for helping out Alice :)

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 8 • 11 years ago

I bet the issue is here:

			if( docLocLastNode != lastNodeOf(top.frames["content"].location) ) {	// ...but it is being loaded elsewhere

followed by some location.replace() calls.

The toplevel frameset has a <frame name="content">.

There is no "content" property on windows in the spec, but we have it on nsIDOMWindow... The getter basically returns the same thing as window.top for web pages, and the primary content shell when called from chrome.

I wonder whether we could move this member to nsIDOMChromeWindow.  Or on branches, to make things safer, hack up the "look up a named frame" getter to check for frames actually named "content" and if that fails to do the current behavior.  Bobby, what do you think?

	Bobby Holley (:bholley)
	Comment 9 • 11 years ago

(In reply to Boris Zbarsky (:bz) from comment #8)
> I wonder whether we could move this member to nsIDOMChromeWindow.  Or on
> branches, to make things safer, hack up the "look up a named frame" getter
> to check for frames actually named "content" and if that fails to do the
> current behavior.  Bobby, what do you think?

I think we should definitely hack something in first to fix the regression, and then move content to be chrome-only. Otherwise, we could find ourselves in a backout pickle on beta.

I'm a bit confused by your suggestion though. Do I understand correctly that the page wants the iframe but is getting |top|? If so, it seems like we should instead hack the |content| getter to check if there's a named frame of the same name, rather than having the named frame lookup see if the name is |content|. Or am I misunderstanding?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 10 • 11 years ago

> Do I understand correctly that the page wants the iframe but is getting |top|?

Yes.

> If so, it seems like we should instead hack the |content| getter to check if there's a
> named frame of the same name

Hmm...  Yeah, that would work too, for this use case, and somewhat more closely matches the behavior we used to have.  Let's do that.

	Bobby Holley (:bholley)
	Comment 11 • 11 years ago

I can probably get to this in the next week or two. Feel free to take it if you can get to it sooner.

	Bobby Holley (:bholley)
	Comment 13 • 11 years ago

Comment on attachment 742046 [details] [diff] [review]
Make window.content return an existing named frame with that name if there is one.

Review of attachment 742046 [details] [diff] [review]:
-----------------------------------------------------------------

r=bholley. Thanks for taking this.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 15 • 11 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/e2d475778a00

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 16 • 11 years ago

Comment on attachment 742046 [details] [diff] [review]
Make window.content return an existing named frame with that name if there is one.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 850517 
User impact if declined: Some sites are broken
Testing completed (on m-c, etc.): Passes tests, fixes the two sites that are
   broken so far.
Risk to taking this patch (and alternatives if risky): Low risk.  More or less
   restores the behavior we used to have for .content in Firefox 21 and earlier.
String or IDL/UUID changes made by this patch:  None.

	Ryan VanderMeulen [:RyanVM]
	Comment 17 • 11 years ago

https://hg.mozilla.org/mozilla-central/rev/e2d475778a00

	Mitza
	Comment 18 • 11 years ago

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:23.0) Gecko/20130428 Firefox/23.0

Verified as fixed on Firefox latest nightly (Build ID:20130428031010).

	Ryan VanderMeulen [:RyanVM]
	Comment 19 • 11 years ago

https://hg.mozilla.org/releases/mozilla-aurora/rev/010637f8c507

	Mihai Morar, (:MihaiMorar)
	Comment 20 • 11 years ago

I confirm the fix is verified on FF 22.b1:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0(20130514181517)

	alex_mayorga
	Comment 21 • 11 years ago

Confirming http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html loads and stays loaded on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130603 Firefox/24.0 ID:20130603031140 CSet: 198e38876f7e

Marking VERIFIED based on this and comment 20.

	jeff.peelman
	Comment 22 • 11 years ago

Using Nightly 25.0a1 build, I did not observe the endless loading/reloading that was reported by Zac C on 03 April 13.  Page appears to load in the expected fashion.  I was able to page forward and back using the arrow icons on the screen.
Hope this information helps.  ~ Jeff